前一段时间开始，经常收到服务器的告警通知短信，提示CPU负荷过高。由于大部分情况，服务器会自动恢复，所以也就没有过多关注。

最近则存在服务器卡死的情况，只能进入后台手动重启，虽然每次重启之后问题都能解决，但是一直手动重启也不是长久之计，因此，我尝试排查下原因。由于服务器卡死，无法远程连接，没法查询到进程情况，而且服务器已经把高负载的进程强制kill掉，无法在第一时间回溯案发时的情况。所以，没办法，只能先尝试联系云服务商，那边给出的答复是确实存在高负载导致服务器夯住的情况，建议安装监控工具，等待后续再次出现问题时再做分析。ps.在此之前我从来没想过会出现性能问题，虽然这个博客系统所在的服务器配置比较基础，只有2c2g，不过跑这个博客服务应该是绰绰有余了。按照答复，我先安装了atop工具，等待下一次问题出现。

atop是一款Linux系统中的高级性能监控工具，能够实时跟踪CPU、内存、磁盘I/O和网络负载等关键资源的使用情况，并记录历史数据以便后续分析），并设置好指标数据的持久化频次，具体使用方式可以参考这篇文章：安装、配置并使用atop监控工具

前几天接收到告警信息后，立马打开服务器后台，此时服务器已经卡死，于是手动重启服务器后，使用atop -r -b 15:00命令，查询15点之后的服务器指标数据，发现只有服务器重启之后和15点之前的指标数据，也就是说服务卡死前数据没有记录下来，猜想原因估计是因为记录的频次是60s，在这个区间内直接卡死导致没及时记录下来，那就调整下频次间隔等待下次出现问题再排查吧。

正巧今天下午正在激情工(mo)作(yu)的时候，又收到了短信告警，赶紧开始排查。和之前不一样的是，这次服务器没有卡死，后台显示高负载是从14点左右开始的，于是远程连接到服务器，输入atop -r -b 14:00命令，然后按下“m”按照内存指标倒序排列，此时指标一切正常，内存占用最大的为博客主服务

然后按下“t”前进30s开始逐个查询，跳转到14:05时，出现了一个dnf进程。

再往后翻，时间来到15:00时，dnf进程消失了，原因是这个进程被系统kill掉了。这个时间范围和后台监控指标的时间范围是保持一致的

其实分析到现在并不能确定这个dnf进程就是之前导致服务器卡死的原因，但是至少可以确定它是服务器负载变高的原因。查了下dnf的作用：

全称Dandified Yum，是Linux系统中一款基于RPM的软件包管理工具(https://baike.baidu.com/item/DNF/19320742)。

然后又检索了下关键词：dnf、linux、高负载、OOM，由此关联出来的资料，有用的不多，但是有提到这个dnf是可以禁用掉的，索性就先把这个玩意禁掉吧。于是在服务器输入以下命令，先把dnf定时器禁用掉，等后续再观察下告警情况。

# 查看系统定时任务
systemctl list-timers | grep dnf
# 停止并禁用dnf定时器
sudo systemctl stop dnf-makecache.timer
sudo systemctl disable dnf-makecache.timer