1. 程式人生 > 實用技巧 >container偶爾宕掉問題的解決記錄

container偶爾宕掉問題的解決記錄

目錄

問題出現

同事說訪問nginx服務時常出現502錯誤,但是由於我是第一天入職,對於公司架構不瞭解,所以根據現象,去檢視nginx服務日誌
日誌內容如下:

2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111"
2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111"
2020/09/07 14:04:02 [error] 2334#0: *16623399 connect() failed (111: Connection refused) while connecting to upstream, client: 112.17.165.197, server: testapi.sdhwl.vip, request: "GET /tmsUcenter/members/accountInfo HTTP/1.1", upstream: "http://172.21.0.8:7122//tmsUcenter/members/accountInfo", host: "192.144.168.25:21111

定位問題

根據日誌資訊,去檢視nginx的配置檔案,發現公司的nginx服務中有一個nginx是單獨用於轉發請求給docker容器的,檢視伺服器中執行的docker容器。
定位到問題出現在某個container掛掉,無法處理nginx轉發過來的請求,導致訪問時出現502現象

問題困擾

既然定位到是container的問題,將container重啟就可以恢復。
重啟container出現了關鍵原因
docker stop 指定的容器 後 docker ps -a 發現仍然up
通過檢視linux系統的message日誌

日誌內容如下:

Sep  7 15:32:13 db-41 dockerd: time="2020-09-07T15:32:13.605724773+08:00" level=info msg="Container 5f3f92db000faa32beef775b6fe4c41d5041a85eb88ece1318c83b5a0b709a61 failed to exit within 10 seconds of signal 15 - using the force"
Sep  7 15:32:13 db-41 dockerd: time="2020-09-07T15:32:13.607162887+08:00" level=warning msg="container kill failed because of 'container not found' or 'no such process': Cannot kill container 5f3f92db000faa32beef775b6fe4c41d5041a85eb88ece1318c83b5a0b709a61: rpc error: code = 2 desc = containerd: container not found"
Sep  7 15:32:23 db-41 dockerd: time="2020-09-07T15:32:23.607430044+08:00" level=info msg="Container 5f3f92db000f failed to exit within 10 seconds of kill - trying direct SIGKILL"

未能在訊號15發出後10秒內退出
既然停不掉,索性就up狀態吧
我進入容器確認一下是否因為某個程序的不存在導致了無法處理請求。
docker exec -it 指定容器 /bin/bash
rpc error: code = 2 desc = containerd: container not found
沒有發現這個容器
messages中顯示container沒有執行退出命令
報錯資訊顯示 container容器已經不存在了

因為之前遇到過程序僵死的情況
首先懷疑的記憶體OOM機制的原因,導致了container(本質上也是一個程序)僵死。
free -h
記憶體確實十分嚴重,32G的記憶體 15G的swap已經所剩無幾。
更加懷疑是引發了Linux的OOM機制(OMM機制會根據佔用記憶體的大小進行kill,記憶體佔用越大,被kill的機率越大)

既然正常的方式無法刪除container,則拿出殺手鐗docker rm -f container

在docker rm -f container 之前確保能啟動一個一樣的container

收集資訊

1、重新執行container所需要的資訊
docker inspect資訊

container port 資訊

nginx轉發資訊

container network資訊

container volume資訊
看到是null後便認為是container中設定好的目錄資訊,沒有涉及到linux系統本地目錄mount(因忽略此目錄對映導致 被困擾了一段時間)

2、同事反饋
過一段時間便會出現此現象,每次都是和上屆運維進行口頭通知,也不知道他是怎麼修復的,一會兒就好,但是隔一段時間還是會出現。

問題進展

一、先解決問題

 docker commit -a "liushiya" -m "backup" 4746760911cc(ID) 命名
 docker  run -d  -p  -it  /bin/bash
 docker rm -f docker_name
docker run   -it  -p 7122:7122  --name="sdh-tms-ucenter"   sdh-tms-ucenter_backup:latest   sh -c 'java -Dspring.config.location=/data/sdh_micro_service/sdh-tms-ucenter/1.0/application.yml -Dloader.path=/data/sdh_micro_service/libs -jar /data/sdh_micro_service/sdh-tms-ucenter/1.0/sdh-tms-ucenter-1.0.jar --server.port=7122 >> /data/sdh_micro_service/log/sdh-tms-ucenter-1.0.jar.log 2>&1'

run -d -it 夯不住
-it 報錯沒有此目錄
通過大佬提醒,第二天回到公司檢視確實是映射了本地目錄,正常啟動container,暫時解決502問題,測試同事繼續正常工作。
二、分析出現問題的原因
①程序佔用記憶體的大小資訊

cat /proc/程序號/status 
VmRSS //程序當前使用的實體記憶體的大小
VmData //程序佔用的資料段大小
VmSize //程序當前使用的虛擬記憶體的大小

②核心日誌資訊

dmesg|grep memory

(詳細解釋dmesg命令參照玉樹臨風的部落格

③殺死程序的日誌

egrep -i -r 'killed process' /var/log/messages

在週五 container又一次死掉了。查詢日誌, 還真在日誌中發現了被殺死的container程序號,更加確信是因為引發了OOM機制問題而導致時常擋掉的想法。(有部分部落格說是docker的版本bug問題,公司docker版本為舊版本,所以當時這個觀點我也要考慮)

治標不治本

container重新拉起來 可以暫時解決問題,我也寫了定時任務crontab 每隔一小時重啟container(省的老是叫我手動重啟 ~O(∩_∩)O~)

困惑

今天週一檢視時 container又死掉了 並且在日誌中沒有發現被OOM殺死的container程序的資訊
如果說我之前堅持引發OOM的觀點,則此時的我困惑了 嗚嗚嗚~

柳暗花明