At 05:29 PM 12/15/2008, Paul MacKenzie wrote:
The next thing I am doing is going to be removing the QUOTA feature
to see if this has any bearing
on this problem. It does not appear to be even writing at a heavy
load as you can see (almost
nothing) but the processes are mostly in UFS when it spirals out of control.
Whats strange is that the output from gstat shows the disks hardly
active at all.... Yet why is the syncer at 100% ? Do you have write
caching disabled on the array ? What does the raw throughput look
like to the disks ? e.g. if you try a simple dd if=/dev/zero
of=/var/tmp bs=1024k count=1000 ?
I moved the processing of amavisd-new into a memory drive to at
least take that off the IO and this
seems to have helped a bit. There is not a lot of mail going through
the system but every little bit
helps. I suspect this is one other reason that is bringing the
problem to the forefront as
amavisd-new can use the disks a bit to process each e-mail.
Is the high load average simply a function of processes blocking on
network io ? On our av/spam scanners for example show a high load avg
because there are many processes waiting on network io to complete
(e.g. talking to RBL lists, waiting for DCC servers to complete etc)
Also, is it really related to the arcmsr driver ? i.e. if you did the
same tasks on a single IDE drive, is the performance profile going to
be the same ?
---Mike
_______________________________________________
freebsd-stable@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"