On 10/6/10 5:22 PM, Timo Sirainen wrote:
Is the load CPU load or disk I/O load? If I/O load, what NFS operations are peaking there, or all of them? Pretty graphs of nfsstat output would be nice.
If I'm reading the output of our monitoring system correctly, the CPU is spending quite a bit of time in WAIT status, so I asuume that means it is IO bound?
After 19 minutes of uptime, nfsstat looks like (I'm not monitoring this [yet], so I don't have pretty graphs :/ ):
Client nfs v3:
null getattr setattr lookup access readlink
0 0% 20389 15% 7615 5% 42198 31% 26896 20%
58 0%
read write create mkdir symlink mknod
6923 5% 5825 4% 4178 3% 29 0% 0 0%
0 0%
remove rmdir rename link readdir
readdirplus
2771 2% 0 0% 2500 1% 77 0% 7238 5%
1428 1%
fsstat fsinfo pathconf commit
3 0% 4 0% 2 0% 5690 4%
login_processes_count: 20 Probably could use less then 20.
login_max_connections: 64 And this could be higher. In general you should have maybe 1-2x the number of login processes than CPU cores. Since this is in a virtual environment, I went ahead and ramped up the number of CPUs to 4, since I have the processors to spare. mail_nfs_storage: yes You said you have only one server accessing mails. So set this to "no". Done. mail_location: maildir:~/Maildir:INDEX=/var/indexes/%u .. namespace: type: shared separator: / prefix: shared/%%u/ location: maildir:%%h/Maildir:INDEX=~/Maildir/shared/%%u The INDEX path here is wrong now. Fixed - luckily most of our users don't share so this shouldn't have had a huge impact. Also you could try if maildir_very_dirty_syncs=yes is helpful. Done.
Will report back tomorrow on how much these fixes help. Really appreciate the effort.
-- Chris Hobbs Director, Technology New Haven Unified School District
-- This message was scanned by ESVA and is believed to be clean.