一同事M因127服務(wù)器上Jenkins無法構(gòu)建成功來找我，說：構(gòu)建卡住了。
訪問127的Jenkins取消同事M的構(gòu)建進(jìn)程，重構(gòu)建一次，發(fā)現(xiàn)確實(shí)是卡住的，查看Jenkins日志無異常。
想起群里上周有人說127服務(wù)器cpu和io不高，負(fù)載超高，無法ps，找不到原因，尋求幫助，當(dāng)時(shí)因在處理其他事情沒回復(fù)。
使用top發(fā)現(xiàn)，負(fù)載90多-比上周高了，sar看到的信息正常，df -lh查看磁盤空間-沒有看到使用100%的。
唯一可疑的就是Jenkins所在目錄/var已使用97%，只有4.5G的可用空間，理論上排除空間不足而上下文切換頻繁產(chǎn)生的負(fù)載高，但/var目錄總空間為197G，一般情況下這個(gè)目錄不會(huì)有這么大的使用量，所以還不能排除嫌疑。
于是對(duì)/var目錄進(jìn)行排查，查看哪個(gè)目錄有大文件，發(fā)現(xiàn)是confluence（一個(gè)文檔管理應(yīng)用）目錄使用了80多G，一層層目錄(du -sh /var/*)查進(jìn)去看到是/var/atlassian/confluence/application-data/confluence/backups 使用了60G左右，是一個(gè)備份目錄，單個(gè)備份文件大小12G，日志是每日凌晨2點(diǎn)多生成，可以確定是一個(gè)每日備份的目錄。
假設(shè)：/var空間可用80G，備份文件一個(gè)12G，每日生成一個(gè)，也就是到第7天的時(shí)候 就會(huì)因?yàn)榭臻g不足而無法備份，進(jìn)程就會(huì)卡住，在第8天定時(shí)任務(wù)又會(huì)運(yùn)行備份，然后進(jìn)程又卡住了，負(fù)載就會(huì)越來越高。
到這里就可以確定，找到問題的原因了，處理起來就非常容易，因無法ps 看不到cron的進(jìn)程，第一反應(yīng)重啟服務(wù)器（重啟服務(wù)器過程卡住了-耽擱10分鐘，手動(dòng)進(jìn)行了重啟。）
第一步：停掉confluence
第二步：刪除掉老的備份，只留了最新的一個(gè)
第三步：更改備份目錄的配置，目錄改到/opt為數(shù)據(jù)盤空大。
/var/atlassian/confluence/application-data/confluence/backups
改成/opt/atlassian/confluence/application-data/confluence/backups
第四步：移動(dòng)/var/atlassian/confluence/application-data 到/opt/atlassian/confluence 目錄下
第五步：?jiǎn)?dòng)confluence
第六步：將confluence每日備份 改成每月1日2點(diǎn)備份（管理界面更改cron）==需要根據(jù)使用頻率來決定備份的周期，當(dāng)前confluence主要查文檔，上傳/修改文檔較少，可以不用每日備份。
第七步：寫一個(gè)腳本，每日0點(diǎn)檢查backups的目錄，保留最新的2個(gè)備份文件即可，其他的刪除。
#!/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
因?yàn)?var空間足夠了，重新對(duì)Jenkins上的項(xiàng)目進(jìn)行構(gòu)建也不卡了。
沒有使用復(fù)雜的技術(shù)，Jenkins恢復(fù)到可用-花費(fèi)40分鐘，confluence處理好-花費(fèi)50分鐘。
