记一次服务器故障排查

一同事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分钟。

你可能感兴趣的:(记一次服务器故障排查)