服务器内存报警排查
一、事件背景
周六的早晨收到服务器内存告警邮件，赶紧爬起来查看，通过初步检查发现，/app 目录使用率高达98%，总分配大小为197G，已经使用了187G，情况极度危险。
二、查找报警内存
1. 查出报警的内存目录
命令：df -h
查询结果：
/dev/sda2 197G 187G 0G 98% /app
2. 继续深入查询
进入/app目录，查看各文件或文件夹大小：ls -lh
发现是/app/logs_back 目录文件非常大，而且还在飞速增长！
三、分析报警原因
此文件夹/app/logs_back 是服务器对系统应用的日志文件做备份的，进一步查看该文件夹发现，里边的备份文件每分钟都会生成新的，点开每个备份的文件夹发现都是一样的日志，都是近一个礼拜的日志文件，这样原因就很清晰了，是服务器的备份策略出现了问题，本应每隔七天备份这七天的日志，现在是每分钟都在备份这七天的日志，很明显是备份的定时任务cron语法使用错误。
查看服务器备份定时脚本：crontab -e
SHELL=/bin/bash
PATH=/sbin:/bin:/usr/sbin:/usr/bin
MAILTO=root
* */6 * * /bin/sh /app/logs_back.sh
问题很明显了，定时语法有误，前面两位是 * ，意味着每隔6天后的每时每分都会执行，严重的语法错误，问了下项目组是一位年长的小哥搞错了。
四、问题解决
1. 删除大文件
赶快删除这个文件夹/app/logs_back，不让文件继续暴涨。
2. 修改定时语法，重新执行定时任务
正确的语法应该是：
0 0 * * 6 /bin/sh /app/logs_back.sh
即每礼拜六的00:00执行。
五、补充
1. Linux定时任务相关指令
crontab -l：查看定时程序脚本执行列表
crontab -e：编辑定时程序脚本执行列表（进入VI编辑模式）
crontab -u：设定某个用户的cron服务，一般root用户在执行这个命令的时候需要此参数
crontab -r：删除某个用户的cron服务
2. 服务器定时语法
它和我们在spring使用的cron语法是一样的，spring比这个还更好一点：多了个秒，其实在定时的文件也有语法介绍【有的系统可能没有，比如我的阿里云】，这里搬来大家共勉：
For details see man 4 crontabs
Example of job definition:
.—————minute (0 59)
| .————hour (0 23)
| | .———day of month (1 31)
| | | .——month (1 12) OR jan,feb,mar,apr …
| | | | .—day of week (0 6) (Sunday=0 or 7) OR sun,mon,tue,wed,thu,fri,sat
| | | | |
* * * * * user-name command to be executed
另:
“*” ：代表取值范围内的数字,
“/” ：代表”每”,
“-” ：代表从某个数字到某个数字,
“,” ：分开几个离散的数字
六、相关问题与解答
问题1：如何释放Slab占用的cache内存空间？
答：可以通过修改/proc/sys/vm/drop_caches来释放Slab占用的cache内存空间，具体操作如下：
首先运行sync命令确保所有缓存的对象都被释放。
然后根据需要释放不同类型的缓存：
释放pagecache：echo 1 > /proc/sys/vm/drop_caches
释放dentries和inodes：echo 2 > /proc/sys/vm/drop_caches
同时释放pagecache、dentries和inodes：echo 3 > /proc/sys/vm/drop_caches
如果需要恢复drop_caches设置，可以运行echo 0 > /proc/sys/vm/drop_caches。
问题2：如何排查指定服务器中的指定内存条是否损坏？
答：可以通过以下步骤排查内存是否出现损坏：
1、使用grep "[0-9]" /sys/devices/system/edac/mc/mc/csrow/ch*_ce_count命令查看每个内存的错误计数，如果count不为0，表示有错误，其中mc代表第几个CPU，csrow代表内存通道，ch代表第几个内存。
2、使用dmidecode -t memory命令查看每个DIMM（Dual Inline Memory Module）的详细信息，进一步确认哪些内存出了问题。
以上就是关于“服务器内存报警排查”的问题，朋友们可以点击主页了解更多内容，希望可以够帮助大家!
