There's a better way to measure this stuff - on Linux, strace will give you
information about how long system calls are taking. A '-c' flag will add them
up, you can use '-p' to attach to an existing process - leave it running for,
like, 30 seconds or so, then <ctrl>-c it, it'll detach and spit out times
for the main system calls. Very useful.
And I agree, by the way, if you're not using async-io, your open calls will
be killing you.
KevinL
(On Solaris, the appropriate tool is 'truss', btw)
>>> Gideon Glass wrote
>
> Hmm. Thanks for your words. The target filesystem in this case is EXT2,
> and there are six cache-disks. The entire disk-subsystem (including
> cache) never exceeds 400-600 blocks of throughput per second (about half
> in, and half out, at peak)...Physically, the disks spend most of their
> operational time each second idle.
>
> 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're not using async I/O, try this for kicks. Put gettimeofday()
> calls around open/close/read/write/unlink calls on disk objects and
> record the latencies of these calls. I suspect you'll find that open
> dominates the others.
>
>
> gid
Received on Tue Jul 29 2003 - 13:15:57 MDT
This archive was generated by hypermail pre-2.1.9 : Tue Dec 09 2003 - 16:12:06 MST