Rob is 100% right with his explanation. I just want to add some
explanation/detail for those interrested:
Linux does use all its available memory in "the most reasonable way" (tm).
Uhm... yea, it tries to. The mechanism
used for this is implemented in its memory management.
All pages that are not kernel-internal data structures or kernel code
itself, are kept in a thing called "page cache".
There are two kinds of pages in the cache: those that are anonymous and
non-anonymous. The difference between those
is that anonymous pages are nowhere to be found on any disk, while there
is a disk block assigned to store the data of the
non-anonymous ones.
When an application runs then the application itself (the code) is loaded
from disk and stored as non-anonymous pages. Same
is true for pages that are loaded because an application wants to read its
contents (data files).
Applications that allocate memory do get anonymous pages for this. As soon
as the page is to be swapped out to swap disk
for the first time, the anonymous page gets a swap slot assigned so that
it becomes non-anonymous.
For all those pages there is a least-recently used algorithm. After every
page was filled with some data for the first time after
reboot (the page cache is filled quickly on busy systems), pages are
re-used. Whenever there is memory demand, the page
that is "clean", which means that it's contents have been synchronized
with the disk-content, and has not been used for a long time
is reused for another purpose.
This algorithm ensures that Linux has the most-frequently used stuff in
memory and does not need to do too much IO. This seems
to be the best way to deal with things on a standalone system.
In a virtual environment however, things become more complicated. Two
memory managers (the one in VM and the other one in
Linux) compete in doing the very same job. There are a couple of
situations where this works very well. For example when one guest
is idle, VM will choose to page it out and use the memory to serve the
workload on other guests. In some situations however, things
become more difficult.
The soloution you propose (to flush the cache) does not help here, because
although Linux would report more free memory this info
does not get to VM. It would even be counterproductive: Linux would need
to do more IO and need to shuffle around with its memory
even more. This makes it "more aggressive" to VM, and things would get
worse.
Soloutions that can help to keep the Linux memory footprint low, and to
improve the communication between both memory managers are:
- keep the memory available to Linux as small as possible, while keeping
the paging rate (reported by vmstat) at a reasonably low level
- use a very fast virtual swap device for Linux and let VM do paging to
physical disk (vdisk is good, dcss swap is even better)
- use xip2fs to share data between guests to minimize memory consumtion in
case you are running a large amount of similar servers
- use collaborative memory management to synchronize the memory managers
In effect, above soloutions help to keep your Linux+VM happy (and
therefore keep your application performance up) even when memory
pressure in Linux or VM gets high.
with kind regards
Carsten Otte
--
omnis enim res, quae dando non deficit, dum habetur et non datur, nondum
habetur, quomodo habenda est
Rob van der Heij <[EMAIL PROTECTED]>
Sent by: Linux on 390 Port <[EMAIL PROTECTED]>
09/11/2004 05:41 PM
Please respond to Rob van der Heij
To: [EMAIL PROTECTED]
cc:
Subject: Re: Flushing the linux buffers periodically - pitfalls?
On Fri, 5 Nov 2004 09:36:34 -0600, James Melin
<[EMAIL PROTECTED]> wrote:
> There is a program in SLES8 (was also in SLES7) called flushb that
appears
> to be useful for flushing the memory buffers on a per disk device basis.
The --help suggests this is a copy of the blockdev program. I am not
sure why you would want to do this. As far as I understand the
discussions, the thing you're flushing is directories etc. You are not
planning to change the contents of a R/O disk are you?
The best approach imho is to look at Collaborative Memory Management
(since May 2004 in SuSE SLES 8). This way you can tell Linux to drop
some of the cached data according to the LRU statistics it kept. If
you push hard enough, it causes Linux to also drop shared libraries
and binaries that you need afterwards. When you hold the binaries in a
DCSS using xip2fs that is mostly overcome.
Rob
--
Rob van der Heij rvdheij @ gmail.com
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or
visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
----------------------------------------------------------------------
For LINUX-390 subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: INFO LINUX-390 or visit
http://www.marist.edu/htbin/wlvindex?LINUX-390
