poor performance on big machine

Matthew Dillon dillon at apollo.backplane.com
Mon Jul 30 07:54:25 PDT 2007


:hey,
:
:I just continued building and noticed that we seem to have a horribe hdd performance:
:
:Disks   ad4   ad6  acd0   cd0 pass0   md0
:KB/t   0.00 44.27  0.00  0.00  0.00  0.00
:tps       0   186     0     0     0     0
:MB/s   0.00  8.03  0.00  0.00  0.00  0.00 
:% busy    0   100     0     0     0     0  
:             ^^^^^
:              100%?
:
:A lot of processes are in states getblk, wdrain, biowr, biord.  Not stuck, but real slow.  Everybody is pounding on ad6.

     This usually means the disk is seeking around a lot.  There are several
     reasons this might be happening.  The primary culprit is usually that
     the machine is being forced to page or swap due to insufficient memory
     for the process load.  Certain types of less cachable loads can also
     result in a great deal of disk seeking.

     Hard drives are only 'fast' when doing linear reads and writes.  A
     seek on a hard drive usually takes 3-8 mS depending on the drive.  Most
     seeks are hidden or absorbed by either the hard drive's on-board track
     cache or by the operating system's buffer cache but certain types of
     loads can defeat both.

:For some reason "test" was also several times in "biowr".  First, I don't understand why test is used and not the builtin, but whatever.  What's the business of test reading something?  Might that be urandom and stackprotector?  When else would test read a block?
:
:cheers
:  simon

    Is the machine swapping?  Look at the SWAP PAGER stats with systat -vm 1.
    If it is swapping heavily for long periods of time this is usually an
    indication of not having enough memory for the process load.  DragonFly
    is pretty good at keeping things running even during periods of heavy
    paging loads but something still has to give and it usually winds up
    being the disk efficiency.

					-Matt
					Matthew Dillon 
					<dillon at backplane.com>





More information about the Kernel mailing list