Linux：记一次排查内存和SWAP耗尽的原因的过程

排查内存和SWAP耗尽的思路：

场景一：对于常规生产服务器，都会设置SWAP（虚拟内存）。当物理内存使用达到一定百分比时，使用SWAP

---------------------  分割线 ------------------------------

命令： cat /proc/sys/vm/swappiness  查看物理内存使用达到百分之多少时使用SWAP

截图的60代表物理内存在使用60%的时候才会使用swap

swappiness=0的时候表示最大限度使用物理内存，然后才是 swap空间，

swappiness＝100的时候表示积极的使用swap分区，并且把内存上的数据及时的搬运到swap空间里面。

通常情况下：

swap分区设置建议是内存的两倍 （内存小于等于4G时），如果内存大于4G，swap只要比内存大就行。另外尽量的将swappiness调低，这样系统的性能会更好。

---------------------  分割线 ------------------------------

回到正文！！！

一般对于这种问题排查思路就是：

1、通过top命令或者查看内存占用最多的几个进程；

2、然后kill掉进程，在看SWAP释放情况（但是有时候实际问题不是kill掉就ok，还得具体问题具体分析）

下面是本座碰到的问题的排查过程：

步骤1：执行top命令，发现一堆postdrop的进行

步骤2：ps aux | grep postdrop 很尴尬的被刷屏了

步骤3 postdrop 说明发邮件异常导致一直发postdrop，然后没准内存就耗尽了

到这里，我的想法就是去看看我的定时任务里面发邮件这里是不是有问题，然后执行了crontab -e，然后提示了 只读文件系统。。。。emmmmm。。。。。。很匪夷所思了

步骤4  验证是不是这个服务器变成了只读文件系统，所以导致postfix发给root写磁盘失败，一直发postdrop，导致内存耗尽

cd /tmp  进入临时目录

执行 touch test

所以到这里就是系统这里不知道为啥出现问题变成只读文件系统了，处理建议就是

• 服务器文件很重要，则备份服务器文件
• 确认可以登录上机器的控制台，重启服务器过程中出现异常可以查看；
• 重启机器修复文件系统问题；
• crontab -e上顶部加上一条MAILTO=""和修改/etc/crontab将MAILTO=root替换成MAILTO=""，可以重启一下postfix

最后，复盘我这句话：“我的想法就是去看看我的定时任务里面发邮件这里是不是有问题”

这个想法我理解应该是不大对的，我这次是瞎猫撞上死耗子。到步骤3时，应该想到的是postfix（有些使用sandmail）的发送机制，如果服务器系统没有问题，那么最终的问题目测就是由 postfix关闭了不正常工作导致的，然后处理办法就是：

crontab -e上顶部加上一条MAILTO=""和修改/etc/crontab将MAILTO=root替换成MAILTO=""  或 重启一下postfix

场景一分析结束---------------------------------

场景二：有些服务器没有配置SWAP，但是一些中间件会使用导致报错

思路就是没事可以默默查看一下 free -m 看一下内存，看SWAP的配置情况，如果是0，就默默配置上