内存cache过高导致进程hang住，linux-fincore工具使用

https://www.cnblogs.com/yinzhengjie/p/9994207.html

https://cloud.tencent.com/developer/article/1684541

最近产品在个别用户环境下经常发生hang住的行为，通过atop的纪录发现在系统中有持续的内存swap转换，高IO的现象。推测和这两个参数有关，准备进行进一步的实验。

但是cache和free 和swap却均保持一个比较平稳的状态，所以有可能是这个参数的不合适导致经常的IO读写。
=========================================================
这两天在调优数据库性能的过程中需要降低操作系统文件Cache对数据库性能的影响，故调研了一些降低文件系统缓存大小的方法，其中一种是通过修改/proc/sys/vm/dirty_background_ration以及/proc/sys/vm/dirty_ratio两个参数的大小来实现。看了不少相关博文的介绍，不过一直弄不清楚这两个参数的区别在哪里，后来看了下面的一篇英文博客才大致了解了它们的不同。
vm.dirty_background_ratio:这个参数指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如5%）就会触发pdflush/flush/kdmflush等后台回写进程运行，将一定缓存的脏页异步地刷入外存；

vm.dirty_ratio:而这个参数则指定了当文件系统缓存脏页数量达到系统内存百分之多少时（如10%），系统不得不开始处理缓存脏页（因为此时脏页数量已经比较多，为了避免数据丢失需要将一定脏页刷入外存）；在此过程中很多应用进程可能会因为系统转而处理文件IO而阻塞。

之前一直错误的一位dirty_ratio的触发条件不可能达到，因为每次肯定会先达到vm.dirty_background_ratio的条件，后来才知道自己理解错了。确实是先达到vm.dirty_background_ratio的条件然后触发flush进程进行异步的回写操作，但是这一过程中应用进程仍然可以进行写操作，如果多个应用进程写入的量大于flush进程刷出的量那自然会达到vm.dirty_ratio这个参数所设定的坎，此时操作系统会转入同步地处理脏页的过程，阻塞应用进程。 
===========================================================
[    0.344762] pci 0000:00:15.3: BAR 13: no space for [io  size 0x1000]
[    0.344764] pci 0000:00:15.3: BAR 13: failed to assign [io  size 0x1000]
===========================================================

1. 执行aclocal，产生aclocal.m4文件
2. 执行autoconf，生成configure文件
3. 执行automake命令，产生Makefile.in： automake --add-missing
4. 执行configure命令，生成Makefile文件
5. 重新执行make 和 make install,一切顺利. 

https://blog.csdn.net/icycode/article/details/80200437
https://blog.csdn.net/rapheler/article/details/52528577