### 歡迎訪問我的GitHub
> 這裡分類和彙總了欣宸的全部原創(含配套原始碼)：[https://github.com/zq2599/blog_demos](https://github.com/zq2599/blog_demos)

### 本篇概覽
- 在執行**docker exec**命令時，報錯資訊為：**rpc error: code = 2 desc = containerd: container not found**

### 先丟擲結果
- 如果您是透過搜尋錯誤資訊看到了此文，直接參考以下三點即可：
- 在執行**docker exec**命令時報錯，報錯資訊為：rpc error: code = 2 desc = containerd: container not found
- 以上錯誤是因為系統記憶體不足，導致OOM Killer殺掉elasticsearch程式，該程式就是上一步中**docker exec**命令想作用到的容器；
- 請檢查您的系統記憶體情況，建議使用**egrep -i -r 'killed process' /var/log**和**dmesg|grep memory**命令檢視OOM Killer日誌，確認是否存在程式被殺的情況；

- 接下來的內容，是我對整個問題過程的覆盤；

### 問題覆盤
- 收到同事反饋，說後臺服務出現異常，定位後發現是應用連線elasticsearch server失敗，於是用eshead去連線，還是失敗；

- 我們的elasticsearch是執行在docker環境中的，用**docker ps**檢視，看起來沒什麼問題，資訊如下：

```shell
[admin@dev ~]$ docker ps
CONTAINER ID        IMAGE                                                 COMMAND                  CREATED             STATUS              PORTS                     NAMES
fbbcd0d7d57c        eshead                                                "/bin/sh -c 'cd ~/..."   10 hours ago        Up 10 hours         0.0.0.0:10300->9100/tcp   es-head
ef23574c0afe        docker.elastic.co/elasticsearch/elasticsearch:6.1.1   "/usr/local/bin/do..."   10 hours ago        Up 10 hours                                   elasticsearch
```

- 用命令**docker logs -f elasticsearch**，沒有發現什麼異常，只是最後一條日誌是17:35列印的，而此時已經22:00了，也就是說四個小時es沒有輸出日誌到控制檯了；

- 此時打算去容器內部看看有沒有什麼錯誤資訊，執行命令**docker exec -it elasticsearch /bin/bash**，控制檯顯示如下錯誤資訊：

```shell
[admin@dev ~]$ docker exec -it ef23574c0afe /bin/bash
rpc error: code = 2 desc = containerd: container not found
```

- 提示資訊的大意是**找不到容器**，當時並沒有什麼好思路，由於使用了資料卷，容器掛了不怕資料丟失，就想刪除容器再建立一個試試；
- 用**docker rm -f elasticsearch**刪除容器，提示刪除成功；
- 用**docker run --name elasticsearch**重建一個容器，此時控制檯提示"名為elasticsearch的容器已經存在"(不好意思忘了把當時的錯誤資訊存下來了，大致是這個意思吧)
- 此時沒轍了，就用命令**systemctl restart docker**重啟了docker服務；
- 再用**docker run --name elasticsearch**命令，建立es容器成功；
- 開啟eshead，連線es成功；
- 測試業務，操作成功，連線es正常；
- 此時是23:00左右；

- 至此，覺得問題已經解決了，在群裡給大家說了下就回家了；

### 大寫的尷尬
- 剛剛坐上回家的車，收到同事訊息說問題又出現了，es再次連線不上，狀況和之前一樣，這就尷尬了...
- 帶著鬱悶回到家，在夢中問題再次解決，還是那熟悉的**systemctl restart docker**命令。。。

- 以上就是問題的出現和第一輪處理的過程；

### 定位
- 第二天再次面對此問題；
- 去google搜尋的**rpc error: code = 2 desc = containerd: container not found**，發現有不少人遇到了類似問題；
- 搜到的結果中，有的說重啟docker解決，有的說升級docker，也有不少是丟擲問題沒有解決的；
- 這個文章提供了有價值的資訊，如下圖，地址是：https://forums.docker.com/t/container-not-found-error/32303/4

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190326170448791.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)

- 看來可能是記憶體系統記憶體不足，導致OOM Killer將elasticsearch程式殺掉，但是docker服務沒有同步到這個資訊，因此儘管程式不在了，但是**docker ps**可以看到，不過**docker exec**不會起作用，因為程式已經沒了；

- 執行命令**egrep -i -r 'killed process' /var/log**看看OOM Killer日誌，有新發現，兩次OOM導致程式被系統殺掉，時間上和es問題也吻合：

```shell
[admin@dev ~]$ sudo egrep -i -r 'killed process' /var/log
/var/log/messages:Mar 25 17:08:42 dev kernel: Killed process 12385 (controller) total-vm:72068kB, anon-rss:644kB, file-rss:0kB
/var/log/messages:Mar 25 17:08:42 dev kernel: Killed process 11887 (java) total-vm:44440740kB, anon-rss:10786220kB, file-rss:0kB
/var/log/messages:Mar 25 23:13:05 dev kernel: Killed process 43011 (controller) total-vm:72068kB, anon-rss:640kB, file-rss:0kB
/var/log/messages:Mar 25 23:13:12 dev kernel: Killed process 36316 (java) total-vm:44448156kB, anon-rss:11088004kB, file-rss:0kB
/var/log/secure:Mar 26 08:48:49 dev sudo:   admin : TTY=pts/9 ; PWD=/home/admin ; USER=root ; COMMAND=/bin/egrep -i -r killed process /var/log
```

- 執行命令**dmesg|grep memory**看也有記錄，程式ID和egrep查到的是同一個，如下：

```shell
[   17.644157] Freeing initrd memory: 19872k freed
[   17.749669] Non-volatile memory driver v1.3
[   17.749834] crash memory driver: version 1.1
[   18.833237] Freeing unused kernel memory: 1620k freed
[   19.279518] [TTM] Zone  kernel: Available graphics memory: 65870004 kiB
[   19.279520] [TTM] Zone   dma32: Available graphics memory: 2097152 kiB
[245831.555024]  [<ffffffff8116d616>] out_of_memory+0x4b6/0x4f0
[245831.555827] Out of memory: Kill process 11887 (java) score 99 or sacrifice child
[245831.560069]  [<ffffffff8116d616>] out_of_memory+0x4b6/0x4f0
[245831.560791] Out of memory: Kill process 20406 (java) score 99 or sacrifice child
[267649.159340]  [<ffffffff8116d616>] out_of_memory+0x4b6/0x4f0
[267649.160478] Out of memory: Kill process 36316 (java) score 97 or sacrifice child
[267651.140770]  [<ffffffff8116d616>] out_of_memory+0x4b6/0x4f0
[267651.142104] Out of memory: Kill process 36316 (java) score 97 or sacrifice child
```

- 所以可以基本確定是記憶體不足導致OOM Killer殺掉了elasticsearch程式，用top看看當前記憶體情況，發現128G記憶體幾乎已經耗盡：

```shell
[admin@dev ~]$ top
top - 09:24:40 up 3 days, 12:30,  6 users,  load average: 2.02, 1.83, 1.79
Tasks: 814 total,   1 running, 812 sleeping,   0 stopped,   1 zombie
%Cpu(s):  1.0 us,  0.7 sy,  0.0 ni, 98.2 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 13174000+total, 13239316 free, 11658065+used,  1920036 buff/cache
KiB Swap:  4194300 total,  2515328 free,  1678972 used. 14449396 avail Mem

PID USER      PR  NI    VIRT    RES    SHR S  %CPU %MEM     TIME+ COMMAND
19816 admin     20   0 41.774g 0.012t   6396 S   1.0  9.5 159:22.23 java
19389 admin     20   0 40.963g 0.010t   6360 S   1.0  8.6  96:36.80 java
18464 admin     20   0 41.804g 8.216g   6460 S   0.7  6.5 157:01.02 java
18751 admin     20   0 41.829g 7.692g   6364 S   1.3  6.1  98:26.24 java
24233 admin     20   0 37.290g 7.543g   6616 S   0.7  6.0  22:41.94 java
19671 admin     20   0 32.509g 7.314g   6392 S   0.7  5.8  58:14.12 java
9466 admin     20   0 32.105g 7.300g   6628 S   1.0  5.8  18:41.46 java
```

- 接下來的事情就簡單了，根據程式ID檢查耗記憶體大的程式的身份，最終確定有5個java程式的啟動引數配置不當，都是10G，一下子用掉了50G記憶體，導致系統記憶體不足，於是調整它們的啟動記憶體再依次重啟，然後重啟docker，重建es容器，執行了一天時間，一切正常；

- 至此，問題已經修復，為什麼系統記憶體耗盡後OOM Killer殺掉的是elasticsearch程式（連續兩次都是）,可以參考核心的原始碼linux/mm/oom_kill.c，裡面的oom_badness方法，方法註釋中說了，調出最耗記憶體的程式殺掉，如下圖，我們的機器上elasticsearch佔用了32G記憶體，就是最耗記憶體的那個，所以次次都是它了：

![在這裡插入圖片描述](https://img-blog.csdnimg.cn/20190326170550413.jpg?x-oss-process=image/watermark,type_ZmFuZ3poZW5naGVpdGk,shadow_10,text_aHR0cHM6Ly94aW5jaGVuLmJsb2cuY3Nkbi5uZXQ=,size_16,color_FFFFFF,t_70)

- 以上就是整個問題的覆盤過程，如果您也遇到類似問題，希望本文能給您提供一些參考；

### 歡迎關注ITpub：程式設計師欣宸
> [學習路上，你不孤單，欣宸原創一路相伴...](http://blog.itpub.net/70017844/)</ffffffff8116d616></ffffffff8116d616></ffffffff8116d616></ffffffff8116d616>

Docker殺掉了容器？問題分析與解決過程全面覆盤

相關文章