記一次線程爆滿導(dǎo)致服務(wù)器崩潰的問題排查及解決

第記一次線程爆滿導(dǎo)致服務(wù)器崩潰的問題排查及解決目錄問題介紹1.重啟服務(wù)器2.修改最大線程數(shù)3.查找線程最大的java程序4.導(dǎo)出問題程序的線程日志5.找到問題代碼6.解決方案

問題介紹

測試服務(wù)器突然無法連接，ssh登錄不上。只有重啟才能解決。重啟一天后，又連接不上了。

于是有了下面的排查過程，最終發(fā)現(xiàn)是有個java程序一直在創(chuàng)建線程，導(dǎo)致線程達到服務(wù)器最大數(shù)量，服務(wù)器崩潰。

1.重啟服務(wù)器

重啟后，ssh連接發(fā)現(xiàn)下面問題

forkfaild:Cannotallocatememory

以為是內(nèi)存滿了

于是，free-h,查看內(nèi)存情況，還有，觀察一段時間后，內(nèi)存沒多大變化

2.修改最大線程數(shù)

經(jīng)過各種百度，都說可以通過修改服務(wù)器的最大線程數(shù)來解決，于是我也這么干了。當(dāng)時做的時候沒有截圖，所以下面截圖是網(wǎng)上找的，湊合看看。

查看最大進程數(shù)sysctlkernel.pid_max

ps-eLf|wc-l查看進程數(shù)

修改最大進程數(shù)后系統(tǒng)恢復(fù)

echo1000000/proc/sys/kernel/pid_max

永久生效

echo"kernel.pid_max=1000000"/etc/sysctl.conf

sysctl-p

3.查找線程最大的java程序

上一步擴大了線程數(shù)量后，感覺有點不對，因為之前沒有這么配置都可以正常運行，為什么突然服務(wù)器掛了呢？肯定是有程序在作怪。

于是決定找出占用線程最多的程序。回顧最近幾天，服務(wù)器中只部署了幾個springboot程序。問題一定出在它們之中。

查看線程數(shù)量前20的java程序

ps-Lef|awk‘{sum[$2]++}END{for(pidinsum)printpid,sum[pid]}'|sort-nr-k2|head-n20

[root@se-test-lky01~]#ps-Lef|awk'{sum[$2]++}END{for(pidinsum)printpid,sum[pid]}'|sort-nr-k2|head-n20

160743100

313861226

201201072

19548985

9697829

3005796

641344

19016324

16924315

17870300

6417293

8351171

7332168

18259167

19821161

16311157

18433151

18048136

14347104

2559100

觀察一段時間后，發(fā)現(xiàn)進程id為16074的java程序的線程數(shù)不斷增長。

4.導(dǎo)出問題程序的線程日志

[root@se-test-lky01~]#jstack16074thread_dump.log

分析日志，發(fā)現(xiàn)下面情況，線程數(shù)量不斷增加，代碼位置在FtpMonitorProcess.java:85

"Thread-4655"#4774prio=5os_prio=0tid=0x00007f84aa2fe000nid=0xd408bwaitingformonitorentry[0x00007f802b704000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atcn.cloudwalk.bat.util.http.FtpUtil.connect(FtpUtil.java:246)

-waitingtolock0x00000006c09c1888(ajava.lang.Classforcn.cloudwalk.bat.util.http.FtpUtil)

atcess.FtpMonitorProcess$1.run(FtpMonitorProcess.java:85)

atjava.lang.Thread.run(Thread.java:748)

"Thread-4654"#4773prio=5os_prio=0tid=0x00007f84aa2fc000nid=0xd408awaitingformonitorentry[0x00007f802b805000]

java.lang.Thread.State:BLOCKED(onobjectmonitor)

atcn.cloudwalk.bat.util.http.FtpUtil.connect(FtpUtil.java:246)

-waitingtolock0x00000006c09c1888(ajava.lang.Classforcn.cloudwalk.bat.util.http.FtpUtil)

atcess.FtpMonitorProcess$2.run(FtpMonitorProcess.java:114)

atjava.lang.Thread.run(Thread.java:748)

5.找到問題代碼

發(fā)現(xiàn)這個方法每次被調(diào)用就會創(chuàng)建一個新的線程。而這個方法是被定時任務(wù)調(diào)用的，每10秒調(diào)用一次。

問題就出在ftp沒有配置，所以線程內(nèi)執(zhí)行ftp操作時，線程阻塞，沒能釋放。若ftp可用，則不會出現(xiàn)線程阻塞問題。

這就是問題根源。

privatevoidlistDeviceFiles(){

newThread(newRunnable(){

@Override

publicvoidrun(){

logger.debug("開始獲取[ftp-設(shè)備]文件...");

try{

StringworkDir=ftpConfig.getWorkdir();

//連接

FTPClientftpClient=FtpUtil.connect(ftpConfig);

ftpClient.changeWorkingDirectory(workDir);

ftpClient.changeWorkingDirectory(SubscribeDataTypeEnum.DEVICE_INFO.getKey().toString());

FTPFile[]files=ftpClient.listFiles();

for(FTPFilefile:files){

decomposeFile(file,ftpClient);

ftpClient.logout();

}catch