Hi Gerard! The question is not that easy to answer. Let be give some background first: Linux holds all user space related data in the page cahce. Basically you have two different types of pages in the cache:
- anonymous pages These are simple. When your program does malloc(), anonymous memory will be added to the page cache and refered by the page table of the user process. When under memory pressure, anonymous pages are put on the swap device. - non anonymous pages These correspond with a file on disk. Application binaries and libraries are loaded into the page cache and refered by the page table(s) of the user process(es) that run the application. In addition, when a process accesses a file for reading, the file contents are loaded into the page cache and from there copied to the given user buffer. On writing, the corresponding page cache pages are marked "dirty", and they will be written back to disk (then become clean again). When under memory pressure, non-anonymous pages can be discarded when they are clean because their content can be loaded from a file anyway. *These pages will never go to the swap device*. When you start up your system, your page cache will be empty (reported as free memory). Now your system starts doing some of the above activities which fill the page cache. The page cache will fill up quite quickly because only anonymous pages get discarded when the corresponding programs have ended running. Non-anonymous pages will remain in the page cache. Later on, your page cache will get full (only a little rest of free memory is reported). Now the kernel will always discard the least recently used pages from the cache. In case non-anonymous (&clean) pages are least recently used, they will just be discarded. In case of anonymous memory they will go to the swap device. The result of above strategy is that your page cache will grow full soon after system startup and will always be about full all the time from then on. Therefore, the free memory reported has no indication on whether the system is under memory pressure or not. In order to figure out if your system is under memory pressure, you need to keep an eye on the swap rates of your system. In case the page cache is too small to cover the working set of your applications, the kernel will have to move frequently accessed pages to the swap device. The next access to the page will force the kernel to fetch the page back from the swap device. This behavior is called "trashing". The kernel does do trashing when your swap device data rates are resonably high all the time. Therefore, the swap rate is the real indication to see if Linux is under memory pressure. For your concrete problem, the next thing you need to do is watch the swap rates for a while and look if you see them growing higher after a while and if this corresponds with the slowdown you see. If this is the case, the machine needs more memory. In case you do not see the swap rate increase significantly but you still see the slowdown, another idea is to look at VM to see if it is memory constrained. If this is the case, you need to _decrease_ the size of this and other virtual machines in order to fix the problem. This is a balancing issue. with kind regards Carsten Otte -- I saw screens of green, red messages too, then came blue, shubidu And i think to myself, what a wonderful world ---------------------------------------------------------------------- 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
