Docker 容器下安装 openresty-systemtap-toolkit

[yazhou]

最近遇到一个棘手的问题，部署在 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 进程内存的经验吗？

期待你的分享！

谢谢！

[Ming]

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

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

--
--
邮件来自列表“openresty”,专用于技术讨论!
订阅: 请发空白邮件到 openresty...@googlegroups.com
发言: 请发邮件到 open...@googlegroups.com
退订: 请发邮件至 openresty+...@googlegroups.com
归档: http://groups.google.com/group/openresty
官网: http://openresty.org/
仓库: https://github.com/agentzh/ngx_openresty
教程: http://openresty.org/download/agentzh-nginx-tutorials-zhcn.html

[yazhou]

多谢指导！

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

谢谢！

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

[tokers]

Hello!

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

[yazhou]

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

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

[xut...@gmail.com]

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

镜像对内核要求宽 

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

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

[tokers]

Hello!

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

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

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

镜像对内核要求宽 

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

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

[yazhou]

摘这篇文章《又拍云 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来抓,可能还更通用实际.