This subject is like fighting wraiths whilst standing on quicksand, but we can try to help ...
Quote:
Originally Posted by Leakeybill
What we see from time to time is that i/o performance slow down significantly and that the users on the machine complain about responce.
|
Evidence ?
User perceptions of response time(s) are notoriously "iffy". However even the kernel devs have realised they were ignoring this for too long, and changes have been creeping into the kernel of late. What distro, and what kernel level are you running ?.
Try latencytop to see if it agrees with your users perceptions.
Quote:
|
The machine is never fully utilized.
|
Meaning memory ? Let's see some evidence ("free -m" or somesuch would do)
Quote:
|
We find if we manually flush the disk caches the system becomes more responsive to the users.
|
What do you write into the sysctl ... 3 ? ... 2 ? ... 1 ?
Have you tried them all separately to see which (if any) has the most effect ?.
Quote:
|
It appears that with a terrabyte of physical memory that the concept of unlimited disk caches may not work, or that disk cache sizes should be limited. Is it possible that a disk cache could become so large that checking the cache to see if your data is in cache could pose a large overhead in terms of disk i/o.
|
Again, this would need hard data to verify - but is not inconceivable that chasing the (allocation) queues would be expensive. The system tries to avoid it when it can.
Quote:
|
What would be the recommended largest disk cache that you would want to have associated with a file system that is 10 terrabytes in size?
|
No idea
Quote:
|
Does each file system have its own unique system cache space?
|
Not that I'm aware of unless doing direct_io - in which case it bypasses it altogether.
Quote:
|
How should this be configured or managed or does the kernal handle it all.
|
The kernel handles it, although requests for the ability to control/limit the page cache allocation is a constant theme. So far rebutted by the kernel devs (last I looked).
However, as you have already found, there are a bunch of sysctls under /proc/sys/vm/ that allow some input to the decision making - swappiness and the dirty_* along with overcommit_* might help, but need research and individual (i.e. one at a time) adjustment to see any benefit. Site-specific and time consuming.
Cgroups give you some control over memory utilisation, but you would need to be able to separate your users, and decide who gets how much. Can lead into office politics.
Quote:
|
Perhaps someone could direct me to a site with more information regarding disk cache configuration of Linux systems.
|
A comprehensive explanation would indeed be good - I've yet to find one. And that includes looking at (some of) the mm source.
