open3000服务器排查项目,记一次服务器故障排查

一同事M因127服务器上Jenkins无法构建成功来找我，说：构建卡住了。

访问127的Jenkins取消同事M的构建进程，重构建一次，发现确实是卡住的，查看Jenkins日志无异常。

想起群里上周有人说127服务器cpu和io不高，负载超高，无法ps，找不到原因，寻求帮助，当时因在处理其他事情没回复。

image.png

使用top发现，负载90多-比上周高了，sar看到的信息正常，df -lh查看磁盘空间-没有看到使用100%的。

唯一可疑的就是Jenkins所在目录/var已使用97%，只有4.5G的可用空间，理论上排除空间不足而上下文切换频繁产生的负载高，但/var目录总空间为197G，一般情况下这个目录不会有这么大的使用量，所以还不能排除嫌疑。

于是对/var目录进行排查，查看哪个目录有大文件，发现是confluence(一个文档管理应用)目录使用了80多G，一层层目录(du -sh /var/*)查进去看到是/var/atlassian/confluence/application-data/confluence/backups 使用了60G左右，是一个备份目录，单个备份文件大小12G，日志是每日凌晨2点多生成，可以确定是一个每日备份的目录。

假设：/var空间可用80G，备份文件一个12G，每日生成一个，也就是到第7天的时候 就会因为空间不足而无法备份，进程就会卡住，在第8天定时任务又会运行备份，然后进程又卡住了，负载就会越来越高。

到这里就可以确定，找到问题的原因了，处理起来就非常容易，因无法ps 看不到cron的进程，第一反应重启服务器(重启服务器过程卡住了-耽搁10分钟，手动进行了重启。)

第一步：停掉confluence

第二步：删除掉老的备份，只留了最新的一个

第三步：更改备份目录的配置，目录改到/opt为数据盘空大。

/var/atlassian/confluence/application-data/confluence/backups

改成/opt/atlassian/confluence/application-data/confluence/backups

第四步：移动/var/atlassian/confluence/application-data 到/opt/atlassian/confluence 目录下

第五步：启动confluence

第六步：将confluence每日备份 改成每月1日2点备份(管理界面更改cron)==需要根据使用频率来决定备份的周期，当前confluence主要查文档，上传/修改文档较少，可以不用每日备份。

第七步：写一个脚本，每日0点检查backups的目录，保留最新的2个备份文件即可，其他的删除。

#!/bin/bash -l

DATADIR=/opt/atlassian/confluence/application-data/confluence/backups/

cd ${DATADIR}

declare -i filesum=`ls backup-*.zip | wc -l`

declare -i delnum=$filesum-2

if [ "${delnum}" -ge 1 ];then

rm -rf `ls -tr backup-*.zip* | sort | head -${delnum}`

fi

因为/var空间足够了，重新对Jenkins上的项目进行构建也不卡了。

没有使用复杂的技术，Jenkins恢复到可用-花费40分钟，confluence处理好-花费50分钟。