Dancer wrote:
> Whatever is causing the problem is throttling us to the tune of maybe 40
> requests/second (or more). Despite not being (apparently) disk bound,
> I'm tempted to try async-io and see what happens.
If you are running with an empty (not yet filled) cache and disks seems
to be mostly idle then I strongly suspects that your problem is
elsewhere. Perhaps running out of (kernel) inodes or other stupidities
(monitor /proc/sys/fs/inode-max - /prox/sys/fs/inode-nr)
Linux EXT2 is very fast at creating new files and data (does rarely block
at all unless disk is saturated). Truncating (truncate/unlink) of existing
files is comparably much slower than one would expect in my filesystem
tests, and so is also writing to truncated files (actually slower than
creating new files).
Results of some simple saturation measurements on Linux 2.2.6ac1:
Operation Time taken
unlink empty files 3
create empty files 9
create files with data 40
overwrite truncated 50
unlink files with data 65
truncate to 0 size 70
overwrite files 145 (O_TRUNC used)
Worth noticing is that while there is free memory available
(non-dirty buffers or free pages) writing
including file creation does not normally block. The above times are
when saturating the disk with that operation (except for "create" and
"unlink empty files" which was CPU bound). On lower loads the difference
is even greater (truncate/unlink data seems to block always).
The results for "truncate to 0 size" is probably not very fair. The
test program used open(O_TRUNC) to truncate the files and not truncate().
The bad results for writing to existing files with O_TRUNC was
a pure suprise, and I didn't expect writing to new files would be faster
than writing to truncated files either.
/Henrik
Received on Tue Jul 29 2003 - 13:15:58 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:07 MST