Docker 容器下安装 openresty-systemtap-toolkit

yazhou6543

最近遇到一个棘手的问题，部署在 docker 中的应用内存最近出现上升的情况，以至于需要不断重启应用来降低内存，容器内存变化如下图所示。

内存变化图图.png

当容器内存升高时，Nginx 进程占用的内存确实是上升了。通过top命令查看的结果如下：

[admin@b64ba8a2-653a-4308-8da5-a355841d7f12 ~]$ top -d 20
top - 17:47:54 up 219 days, 14:38, 0 users, load average: 7.41, 4.89, 4.54
Tasks: 21 total, 1 running, 20 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 2.2 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 26386179+total, 11119760+free, 63156648 used, 89507552 buff/cache
KiB Swap: 16777212 total, 15732328 free, 1044884 used. 17263196+avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
106165 admin 20 0 87572 32280 2416 S 46.7 0.0 91:08.78 nginx
106158 admin 20 0 55720 1548 344 S 0.0 0.0 0:00.00 nginx
106159 admin 20 0 86948 32680 2416 S 0.0 0.0 108:34.85 nginx
106160 admin 20 0 90740 32668 2416 S 0.0 0.0 88:54.68 nginx
106161 admin 20 0 1810920 1.671g 2420 S 0.0 0.7 98:25.20 nginx
106162 admin 20 0 86548 32280 2416 S 0.0 0.0 102:32.22 nginx
106163 admin 20 0 1696468 1.560g 2420 S 0.0 0.6 100:02.93 nginx
106164 admin 20 0 86932 32696 2416 S 0.0 0.0 97:14.18 nginx
106166 admin 20 0 1463116 1.339g 2412 S 0.0 0.5 131:19.57 nginx

通过 collectgarbage("count") 查看 Lua GC 分配空间大小结果如下：

Worker 106161: GC size: 140.646 KB

现在打算使用 openresty-systemtap-toolkit 工具对 nginx 进程的内存进行分析。

首先是安装 systemtap ，在执行 stap-prep 后的结果如下：

[admin@3a5356b9-0237-4cb7-96e1-67faa400d750 ~]$ stap-prep
Need to install the following packages:
kernel-3.10.0-693.5.2.el7.x86_64
kernel-devel-3.10.0-693.5.2.el7.x86_64
kernel-debuginfo-3.10.0-693.5.2.el7.x86_64

不知道该如何往下进行了。

请问大家有在 docker 下安装 openresty-systemtap-toolkit 或者分析 Nginx 进程内存的经验吗？

期待你的分享！

谢谢！

moonbingbing

你可以在物理机上安装 systemtap 工具集，采集 docker 内的 nginx 进程信息。这个方法是可行的。

yazhou <yazh...@gmail.com> 于2019年2月19日周二下午3:45写道：

最近遇到一个棘手的问题，部署在 docker 中的应用内存最近出现上升的情况，以至于需要不断重启应用来降低内存，容器内存变化如下图所示。

当容器内存升高时，Nginx 进程占用的内存确实是上升了。通过top命令查看的结果如下：
[admin@b64ba8a2-653a-4308-8da5-a355841d7f12 ~]$ top -d 20
top - 17:47:54 up 219 days, 14:38, 0 users, load average: 7.41, 4.89, 4.54
Tasks: 21 total, 1 running, 20 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 2.2 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 26386179+total, 11119760+free, 63156648 used, 89507552 buff/cache
KiB Swap: 16777212 total, 15732328 free, 1044884 used. 17263196+avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
106165 admin 20 0 87572 32280 2416 S 46.7 0.0 91:08.78 nginx
106158 admin 20 0 55720 1548 344 S 0.0 0.0 0:00.00 nginx
106159 admin 20 0 86948 32680 2416 S 0.0 0.0 108:34.85 nginx
106160 admin 20 0 90740 32668 2416 S 0.0 0.0 88:54.68 nginx
106161 admin 20 0 1810920 1.671g 2420 S 0.0 0.7 98:25.20 nginx
106162 admin 20 0 86548 32280 2416 S 0.0 0.0 102:32.22 nginx
106163 admin 20 0 1696468 1.560g 2420 S 0.0 0.6 100:02.93 nginx
106164 admin 20 0 86932 32696 2416 S 0.0 0.0 97:14.18 nginx
106166 admin 20 0 1463116 1.339g 2412 S 0.0 0.5 131:19.57 nginx

通过 collectgarbage("count") 查看 Lua GC 分配空间大小结果如下：
Worker 106161: GC size: 140.646 KB

现在打算使用 openresty-systemtap-toolkit 工具对 nginx 进程的内存进行分析。
首先是安装 systemtap ，在执行 stap-prep 后的结果如下：
[admin@3a5356b9-0237-4cb7-96e1-67faa400d750 ~]$ stap-prep
Need to install the following packages:
kernel-3.10.0-693.5.2.el7.x86_64
kernel-devel-3.10.0-693.5.2.el7.x86_64
kernel-debuginfo-3.10.0-693.5.2.el7.x86_64
不知道该如何往下进行了。

请问大家有在 docker 下安装 openresty-systemtap-toolkit 或者分析 Nginx 进程内存的经验吗？

期待你的分享！
谢谢！

--

yazhou6543

多谢指导！

另外，openresty-systemtap-toolkit 和 stap++ 也都需要装在物理机上吗？还是装在容器中就可以？（因为要跟运维进行沟通，所以我们需要了解一下）

谢谢！

在 2019年2月19日星期二 UTC+8下午4:43:52，WenMing写道：

你可以在物理机上安装 systemtap 工具集，采集 docker 内的 nginx 进程信息。这个方法是可行的。

yazhou <yazho...@gmail.com> 于2019年2月19日周二下午3:45写道：

最近遇到一个棘手的问题，部署在 docker 中的应用内存最近出现上升的情况，以至于需要不断重启应用来降低内存，容器内存变化如下图所示。

当容器内存升高时，Nginx 进程占用的内存确实是上升了。通过top命令查看的结果如下：
[admin@b64ba8a2-653a-4308-8da5-a355841d7f12 ~]$ top -d 20
top - 17:47:54 up 219 days, 14:38, 0 users, load average: 7.41, 4.89, 4.54
Tasks: 21 total, 1 running, 20 sleeping, 0 stopped, 0 zombie
%Cpu(s): 1.6 us, 2.2 sy, 0.0 ni, 96.0 id, 0.0 wa, 0.0 hi, 0.1 si, 0.0 st
KiB Mem : 26386179+total, 11119760+free, 63156648 used, 89507552 buff/cache
KiB Swap: 16777212 total, 15732328 free, 1044884 used. 17263196+avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
106165 admin 20 0 87572 32280 2416 S 46.7 0.0 91:08.78 nginx
106158 admin 20 0 55720 1548 344 S 0.0 0.0 0:00.00 nginx
106159 admin 20 0 86948 32680 2416 S 0.0 0.0 108:34.85 nginx
106160 admin 20 0 90740 32668 2416 S 0.0 0.0 88:54.68 nginx
106161 admin 20 0 1810920 1.671g 2420 S 0.0 0.7 98:25.20 nginx
106162 admin 20 0 86548 32280 2416 S 0.0 0.0 102:32.22 nginx
106163 admin 20 0 1696468 1.560g 2420 S 0.0 0.6 100:02.93 nginx
106164 admin 20 0 86932 32696 2416 S 0.0 0.0 97:14.18 nginx
106166 admin 20 0 1463116 1.339g 2412 S 0.0 0.5 131:19.57 nginx

通过 collectgarbage("count") 查看 Lua GC 分配空间大小结果如下：
Worker 106161: GC size: 140.646 KB

现在打算使用 openresty-systemtap-toolkit 工具对 nginx 进程的内存进行分析。
首先是安装 systemtap ，在执行 stap-prep 后的结果如下：
[admin@3a5356b9-0237-4cb7-96e1-67faa400d750 ~]$ stap-prep
Need to install the following packages:
kernel-3.10.0-693.5.2.el7.x86_64
kernel-devel-3.10.0-693.5.2.el7.x86_64
kernel-debuginfo-3.10.0-693.5.2.el7.x86_64
不知道该如何往下进行了。

请问大家有在 docker 下安装 openresty-systemtap-toolkit 或者分析 Nginx 进程内存的经验吗？

期待你的分享！
谢谢！

--

zchao1995

Hello!

实际上只要内核满足条件，装在容器里也是可以使用的（需要特权启动方式），当然主要的工具链都要装齐。

yazhou6543

好的，多谢你的建议，后续我们要在这方面进行探索、实践。

在 2019年2月19日星期二 UTC+8下午5:46:19，tokers写道：

Hello!

实际上只要内核满足条件，装在容器里也是可以使用的（需要特权启动方式），当然主要的工具链都要装齐。

xutimon

容器里面不太可取,因为这个东西和内核强相关

镜像对内核要求宽

即使镜像打包成功也不能通用...

温铭说的物理机安装,然后获取容器nginx进程id来抓,可能还更通用实际.

zchao1995

Hello!

很多时候生产环境工具链并不那么齐全，可能基础的编译器等环境都不具备，这个时候物理机上就无法使用 systemtap 了，除非自己交叉编译。

On Wednesday, February 20, 2019 at 5:49:46 PM UTC+8, xut...@gmail.com wrote:

容器里面不太可取,因为这个东西和内核强相关

镜像对内核要求宽
即使镜像打包成功也不能通用...

温铭说的物理机安装,然后获取容器nginx进程id来抓,可能还更通用实际.

yazhou6543

摘这篇文章《又拍云 OpenResty / Nginx 服务优化实践》的部分内容：

性能分析、Tips
我们经常会在线上或本地开发机器上执行 top、pidstat 等命令，这些命令会报告一些系统和进程的资源使用情况，这就是资源分析。资源分析主要聚焦于资源利用率、饱和度以及错误数，这就是经典的 USE 分析方法。这个分析方法由 Brendan Gregg 大神提出，非常有用。通过资源分析可以非常直观的看到业务应用在线上跑着，会吃掉多少的内存，占用多少的 CPU，产生多少磁盘吞吐等。

第二个是针对应用程序本身所展开的工作负载分析，工具也比较多，包括 perf，systemtap，bcc/ebpf 等工具。通过 systemtap、bcc/ebpf 可以将数据进行汇总，利用工具画出火焰图。负载分析主要是针对应用程序自身的表现，比如 OpenResty，在作为一个反向代理服务器或者网关存在时，大家比较关心它的指标就是请求延时和状态码，像 501、502、504 状态码的比例。

当我们需要展开分析时，会发现线上环境，工具等条件不足，甚至连基本的编译工具都没有，这时候像 systemtap 这样的工具就没法用了。又拍云也遇到了这样的问题，因此我们采用了容器化，把所有的工具全部扔到了容器里，包括一些基本的编译器，链接器，常用的 perf、systemtap、gdb、mozilla rr 等工具。大家可能会觉得容器的权限会不会有问题，当然首先这个容器必须是以特权模式去运行，另外还需要把宿主机的内核头文件进行映射，并且必须使用宿主机的 pid namespace，否则在容器里面没有办法去追踪宿主机上的进程。

根据他们的经验，把这些分析工具放在容器里是可行的。

在 2019年2月20日星期三 UTC+8下午5:49:46，xut...@gmail.com写道：

容器里面不太可取,因为这个东西和内核强相关

镜像对内核要求宽
即使镜像打包成功也不能通用...

温铭说的物理机安装,然后获取容器nginx进程id来抓,可能还更通用实际.