Re: memory usage

From: Mladen Gogala <gogala.mladen_at_gmail.com>
Date: Fri, 2 Mar 2012 05:10:16 +0000 (UTC)
Message-ID: <pan.2012.03.02.05.10.15_at_gmail.com>



On Thu, 01 Mar 2012 09:07:00 -0800, rvaede wrote:

> Response is slow.
> The server has 16GB of RAM and its using over 15.5 GB of RAM. Cache is
> high.

What does it mean "cache is high"? What kind of cache? Page cache? DB cache? IO cache? ACME cache? What is kept in the cache that is high? IO buffers? VM pages? DB buffers? Weapons of mass destruction? Once you answer the question what is kept in the cache that "is high", you will stand a good chance of fixing the perceived problem. On the other hand, I am not sure that the "cache is high" is an accurate description of your problem. This question sounds about the same as the one that some novice users usually ask me, tricked by the more experienced colleagues: "why is the database slow today?". Database is a place, it cannot be slow. The question makes approximately the same amount of sense as the question why is the Statue of Liberty slow today. So, let's go back to the "cache is high" phrase. A possible solution is for the cache to stop smoking pot. If the cache being "high" contains pages, we are talking about page cache. There is a way to reduce page tables on Linux: huge pages. There is an ample documentation on MOS, no need to delve into the nitty gritty details.
If the cache being high is the IO cache (system buffers) then don't use the buffered I/O. Direct I/O will usually decrease the cache use instantly. Direct IO, also fairly well documented on MOS. For a brief explanation, you can also take a look here:

http://mgogala.byethost5.com/Linux_VM.pdf

This paper is rather old and it would be about time to update it and make a new revision which would mention huge pages, iotop, perf, out of memory killer some additional parameters and the brand new features in kernel 3.0, like de-duplication: http://lwn.net/Articles/386090/ http://www.linuxplanet.com/linuxplanet/reports/6919/2

A lot has happened since that article was written, but the basic advice is still sound: turn on the direct I/O, utilize huge pages, and configure your OS memory properly. Unfortunately, I am undergoing a very tumultuous period of my life and chances that this paper will be revised before the end of this year are very slim. Of course, finding someone to fund the new revision would also help and increase chances exponentially. I need my cash to be high, too.

-- 
http://mgogala.byethost5.com
Received on Thu Mar 01 2012 - 23:10:16 CST

Original text of this message