记一次 Redis 服务频繁宕机(CPU 100%)的解决
问题
最近一段时间,阿里云中有一台安装有 Redis 服务的 ECS 主机频繁宕机。之前也遇到过类似的情况,主要是由于系统磁盘空间已满造成的。
但是使用df -h
命令查看,占用只有40%左右。
此时,再看连接该 Redis 的一些服务日志一直在报错,错误内容为:
MISCONF Redis is configured to save RDB snapshots, but it is currently not able to persist on disk. Commands that may modify the data set are disabled, because this instance is configured to report errors during writes if RDB snapshotting fails (stop-writes-on-bgsave-error option). Please check the Redis logs for details about the RDB error.
解决问题
通过错误信息来看,问题已经很明显了,就是磁盘空间不足造成的,最终通过命令df -i
可以看到磁盘占用确实已经到达100%了。
通过````命令,一层一层的查找最终发现/var/spool/postfix/maildrop/
目录体积特别特别大,经过确认该目录中的文件并无大用,于是进入到 maildrop 目录中,使用rm -rf *
删除全部文件,可是事情并没有那么顺利,卡了好久终端命令提示-bash: /bin/rm: Argument list too long
应该是目录中文件太多导致无法删除。
再找方法,使用awk删除,命令为:ls -l| awk '{ print "rm -f ",$9}'|sh
进行删除效果奇佳。看着可用磁盘空间一点点变大心里痛快多了。
说明
第一个要说明的是,通过df -h
命令明明空间只是用了40%左右,但为什么还是报磁盘空间已满?通过文章《linux命令df中df -h和df -i的区别》可以看出大概的原因。主要是文件大小和文件占用磁盘空间大小的区别,磁盘中有太多小体积文件,文件不大,但必须占用满一个单位。
第二个需要说明,maildrop
文件是干什么的?
由于 Linux 在执行 cron 时,会将 cron 执行脚本中的 output 和 warning 信息,都会以邮件的形式发送 cron 所有者, 而由于客户环境中的 sendmail 和 postfix 没有正常运行,导致邮件发送不成功,全部小文件堆积在了 maildrop 目录下面,而且没有自动清理转换的机制,所以长达一年的时间,此目录已堆积了大量的文件。查看 man cron 的信息,可以知道会发送给 cron owner.
参考
Linux下通过rm -f删除大量文件时提示"-bash: /bin/rm: Argument list too long"的解决方法
Linux下通过rm -f删除大量文件时提示"-bash: /bin/rm: Argument list too long"的解决方法...
linux命令df中df -h和df -i的区别
Linux 中 /var/spool/postfix/maildrop 占用空间很大问题
- 0
- 0
-
分享