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.
