難受，nginx worker 進(jìn)程內(nèi)存持續(xù)飄升！
作者：WiburXu
來源：SegmentFault 思否社區(qū)
背景
前兩篇文章講了云主機(jī)上lua openresty項目容器化的歷程，在測試環(huán)境經(jīng)過一段時間的驗證，一切都比較順利，就在線上開始灰度。
但是，好景不長?；叶葲]多久，使用top pod查看時，發(fā)現(xiàn)內(nèi)存滿了，最開始懷疑k8s的resources limit memory(2024Mi)分配小了，放大后(4096Mi)，重啟pod，沒多久又滿了。
緊接著，懷疑是放量較大，負(fù)載高了引起的，擴(kuò)大hpa，再重啟，好家伙，不到兩炷香時間，又滿了。
到此，就把目光投向了pod內(nèi)部的程序了，估摸著又是哪里出現(xiàn)內(nèi)存泄漏了。
坑在哪里
每過一段時間，內(nèi)存忽上忽下，并且nginx worker（子進(jìn)程）id號不斷增加，是誰殺的進(jìn)程？ 云主機(jī)沒有出現(xiàn)這樣的問題，難道是k8s引起的？ pod的resources limit memory增加和hpa增加都沒有解決問題。nginx -s reload可以釋放內(nèi)存，但是沒多久后又滿了。
解決辦法
誰殺的進(jìn)程？
命令：ps aux
USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND
root 1 0.0 0.0 252672 5844 ? Ss Jun11 0:00 nginx: master process /data/openresty/bin/openresty -g daemon off;
nobody 865 10.1 0.3 864328 590744 ? S 14:56 7:14 nginx: worker process
nobody 866 13.0 0.3 860164 586748 ? S 15:13 7:02 nginx: worker process
nobody 931 15.6 0.2 759944 486408 ? R 15:31 5:37 nginx: worker process
nobody 938 13.3 0.1 507784 234384 ? R 15:49 2:23 nginx: worker process
發(fā)現(xiàn)woker進(jìn)程號已經(jīng)接近1000了，那么肯定不斷的被kill，然后再調(diào)起，那究竟是誰干的呢？通過 dmesg命令：
[36812300.604948] dljgo invoked oom-killer: gfp_mask=0xd0, order=0, oom_score_adj=999
[36812300.648057] Task in /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pode4ad18fa_3b8f_4600_a557_a2bc853e80d9.slice/docker-c888fefbafc14b39e42db5ad204b2e5fa7cbfdf20cbd621ecf15fdebcb692a61.scope killed as a result of limit of /kubepods.slice/kubepods-burstable.slice/kubepods-burstable-pode4ad18fa_3b8f_4600_a557_a2bc853e80d9.slice/docker-c888fefbafc14b39e42db5ad204b2e5fa7cbfdf20cbd621ecf15fdebcb692a61.scope
[36812300.655582] memory: usage 500000kB, limit 500000kB, failcnt 132
[36812300.657244] memory+swap: usage 500000kB, limit 500000kB, failcnt 0
[36812300.658931] kmem: usage 0kB, limit 9007199254740988kB, failcnt 0
……
[36675871.040485] Memory cgroup out of memory: Kill process 16492 (openresty) score 1286 or sacrifice child
發(fā)現(xiàn)當(dāng)cgroup內(nèi)存不足時，Linux內(nèi)核會觸發(fā)cgroup OOM來選擇一些進(jìn)程kill掉，以便能回收一些內(nèi)存，盡量繼續(xù)保持系統(tǒng)繼續(xù)運(yùn)行。
雖然kill掉了nginx worker進(jìn)程后釋放了內(nèi)存，短暫性的解決了問題，但根本性問題還沒解決。
為啥云主機(jī)沒問題？
將云主機(jī)的lua代碼拷貝到本地進(jìn)行對比，發(fā)現(xiàn)代碼本身并沒有什么問題。
那只能是其他方面的問題引起了。
如何是好？
以上兩個點，都沒能很好的定位問題問題，看來只能通過通過 top、pmap、gdb等命令去排查問題了。
1. top內(nèi)存泄露的進(jìn)程
通過top 查看哪個進(jìn)程占用內(nèi)存高
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
942 nobody 20 0 618.9m 351.7m 4.2m S 18.0 0.2 4:05.72 openresty
943 nobody 20 0 413.8m 146.7m 4.2m S 11.7 0.1 1:18.93 openresty
940 nobody 20 0 792.0m 524.9m 4.2m S 7.0 0.3 6:25.81 openresty
938 nobody 20 0 847.4m 580.2m 4.2m S 3.7 0.3 7:15.97 openresty
1 root 20 0 246.8m 5.7m 3.9m S 0.0 0.0 0:00.24 openresty
2. pmap查看進(jìn)程的內(nèi)存分配
通過 pmap -x pid 找出該進(jìn)程的內(nèi)存分配，發(fā)現(xiàn)0000000000af7000存在大內(nèi)存的分配。
Address Kbytes RSS Dirty Mode Mapping
0000000000400000 1572 912 0 r-x-- nginx
0000000000788000 4 4 4 r---- nginx
0000000000789000 148 128 116 rw--- nginx
00000000007ae000 140 28 28 rw--- [ anon ]
0000000000a15000 904 900 900 rw--- [ anon ]
0000000000af7000 531080 530980 530980 rw--- [ anon ]
0000000040048000 128 124 124 rw--- [ anon ]
……
3. /proc/pid/smaps 定位內(nèi)存泄露的地址范圍
獲得大內(nèi)存的內(nèi)存地址后，通過 cat /proc/pid/smaps命令，查看內(nèi)存段的具體起始位置：
00af7000-21412000 rw-p 00000000 00:00 0 [heap]
Size: 533612 kB
Rss: 533596 kB
Pss: 533596 kB
Shared_Clean: 0 kB
Shared_Dirty: 0 kB
Private_Clean: 0 kB
Private_Dirty: 533596 kB
Referenced: 533596 kB
Anonymous: 533596 kB
AnonHugePages: 0 kB
Swap: 0 kB
KernelPageSize: 4 kB
MMUPageSize: 4 kB
Locked: 0 kB
VmFlags: rd wr mr mw me ac sd
4. gcore 轉(zhuǎn)存進(jìn)程映像及內(nèi)存上下文
gcore pid
得到 "core.pid"文件。
5.gdb 加載內(nèi)存信息
gdb core.pid
sh-4.2$ gdb core.942
GNU gdb (GDB) Red Hat Enterprise Linux 7.*
Copyright (C) 2013 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>...
[New LWP pid]
Core was generated by `nginx: worker process'.
#0 0x00007ff9435e1463 in ?? ()
"/tmp/core.942" is a core file.
Please specify an executable to debug.
(gdb)
進(jìn)入以上命令窗口
6. dump binary 導(dǎo)出泄露內(nèi)存的內(nèi)容
第3點的時候已經(jīng)得到了內(nèi)存起始地址了，這時候我們內(nèi)存地址導(dǎo)出：
dump binary memory worker-pid.bin 0x00af7000 0x21412000
查看導(dǎo)出的文件大小
sh-4.2$ du -sh worker-pid.bin
511M worker-pid.bin
7. 二進(jìn)制文件分析
用hex工具打開二進(jìn)制文件，發(fā)現(xiàn)里面大量的json對象，通過分析json對象，發(fā)現(xiàn)pod上的so加密庫為舊的（git上并沒有跟新），而云主機(jī)依賴的是新的。
替換so庫，重啟pod，問題解決！～。
總結(jié)
生產(chǎn)環(huán)境上的內(nèi)存泄漏是一個比較頭疼的問題，不妨通過以上的方式去分析，也是一個不錯的思路。
