正确理解Linux内存占用过高的问题

最近老有人问为何开机后，还没有其他服务，mem就被用完了？是不是内存泄露？是否要重启服务？只能说不要看现象，要看本质才能找到问题的根源。
往往给出这样的结果，怀疑内存用了90%：
Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

这样怀疑很普遍，因为很多人用惯了Windows。Windows下，可以使用任务管理器查看当前进程对于内存的消耗情况。在我看来，Windows物理内存总是留下一定的空间，就算此时物理内存有空闲时，也会让某些程序去使用虚拟内存，目的是在Windows下启动新程序时，直接分配空闲的物理内存，这样子新程序启动速度就较快，而Linux则不然。

而在Linux下，使用top命令看到内存占用情况：

Mem: 4146788k total, 3825536k used, 321252k free, 213488k buffers
Swap: 2650684k total, 80k used, 2650604k free, 3006404k cached

这里的结果显示使用了3.8G的used，占用率达到90%。看看free的结果你还可以对比一下：
$ free -m
total used free shared buffers cached
Mem: 4049 3784 265 0 208 2939
-/+ buffers/cache: 636 3413
Swap: 2588 0 2588

虽然MEM显示了3.7G左右的used，但是（-/+ buffers/cache）减去buffers和cache的结果可以看到，当前进程实际占用内存是636M，而可用空闲（free）内存为3.4G。

可以这么理解：在linux的内存分配机制中，优先使用物理内存，当物理内存还有空闲时（还够用），不会释放其占用内存，就算占用内存的程序已经被关闭了，该程序所占用的内存用来做缓存使用，对于开启过的程序、或是读取刚存取过得数据会比较快。

如上面的例子：使用了4G的内存，3.7G被占用，但是buuffer和cached部分作为缓存，可以使用命中率的方式提高使用效率，而且这部分缓存是根据指令随时可以释放的，我们可以认为这部分内存没有实际被使用，也可以认为它是空闲的。

因此查看目前进程正在实际被使用的内存，是used-(buffers+cache)，也可以认为如果swap没有大量使用，mem还是够用的，只有mem被当前进程实际占用完（没有了buffers和cache），才会使用到swap的。

附一段E文，将如何查看linux下程序占用内存量的：

First, repeat this mantra for a little while: "unused memory is wasted memory". The Linux kernel keeps around huge amounts of file metadata and files that were requested, until something that looks more important pushes that data out. It's why you can run:

find /home -type f -name '*.mp3'
find /home -type f -name '*.aac'

and have the second find instance run at ridiculous speed.

Linux only leaves a little bit of memory 'free' to handle spikes in memory usage without too much effort.

Second, you want to find the processes that are eating all your memory; in top use the M command to sort by memory use. Feel free to ignore the VIRT column, that just tells you how much virtual memory has been allocated, not how much memory the process is using. RES reports how much memory is resident, or currently in ram (as opposed to swapped to disk or never actually allocated in the first place, despite being requested).

But, since RES will count e.g. /lib/libc.so.6 memory once for nearly every process, it isn't exactly an awesome measure of how much memory a process is using. The SHR column reports how much memory is shared with other processes, but there is no guarantee that another process is actually sharing -- it could be sharable, just no one else wants to share.

The smem tool is designed to help users better gage just how much memory should really be blamed on each individual process. It does some clever work to figure out what is really unique, what is shared, and proportionally tallies the shared memory to the processes sharing it. smem may help you understand where your memory is going better than top will, but top is an excellent first tool.