> cpu > us sy wt id > 1 2 0 97 cpu statistic looks ok, that doesn't look like the kernel doing PIO mode disk transfers.
> extended device statistics > r/s w/s kr/s kw/s wait actv wsvc_t asvc_t %w %b device > 0.5 320.3 0.8 722.4 1350.3 2.0 4209.3 6.2 100 100 c1d0 Interesting. There are 1350 I/O requests queued for the c1d0 device, and each request has to wait for 4.2093 seconds before the hardware starts working on the request. It doesn't surprise me that audio stops when ogg123 tries to read the next chunk of compressed audio from the HDD and has to wait for 4.2 seconds until a few more bits from the audio file are delivered by the kernel. The huge wait time might also explain the bad interactive desktop performance; it's probably not the mouse that freezes, it's X11/GNOME/KDE applications waiting to be paged into memory when they get the input focus. Question is: who's resposible for the huge amount of queued I/O write requests? A dtrace script can probably answer that question. My first idea was "the kernel is flushing the ufs transaction log", but that doesn't appear to be correct, because I do notice such a huge I/O queue both when the target filesystem for the unpacked mozilla sources is mounted with option "logging" or with option "nologging" (on S10 x86 GA, running "bunzip2 < mozilla-1.7-src.tar.bz2 | tar xf -" ). This message posted from opensolaris.org _______________________________________________ opensolaris-discuss mailing list [email protected]
