记一次GP集群服务器100多个僵尸进程的故障分析

导读

今天分享一个故障分析的案例。

一次寻常的GP集群服务器测试，却引发了100多个僵尸进程！

别慌，掌数工程师带你追根溯源，深度解读整个故障分析全过程。

01

悲剧出现，发生了什么？

2020年7月中旬某日晚间：

某大型银行核心审计系统GP数据库集群（以下称：某集群）的所有服务器（含新扩容的服务器）均告警提示发现100多个僵尸进程！

而此时，正处于某集群停机做数据字典检查的期间。

僵尸进程的出现，是在数据库停止后，进行IO和网络性能测试操作之时。

发现僵尸进程告警之后，登录所有服务器检查，所有僵尸进程消失。

02

剧情重现！问题是如何产生的？

由于发现僵尸进程告警时，正在对某集群的所有服务器（含需要扩容的12台新服务器）进行IO和网络的性能测试。

因此，原因分析过程就从IO和网络性能测试开始分析。

IO和网络性能测试是使用gpcheckperf工具。

在2020年7月下旬晚上某集群正式扩容前抽出时间进行gpcheckperf测试验证，并且实时监控僵尸进程的情况。

开始测试前，首先设置设备维护期。

使用gpcheckperf进行IO读写性能测试，并没有监控到僵尸进程，测试命令：gpcheckperf -f all_segs -r ds -D -d /data1 -d /data2

使用gpcheckperf进行矩阵式网络性能测试，监控到僵尸进程，并且僵尸进程数量与7月20日当晚告警内容相符。

测试命令：gpcheckperf -f all_hosts -r M--duartion=3m -d /tmp

矩阵式网络性能测试约持续3分钟，当各台服务器的启动top监控zombie数量时发现：从测试中间开始，各台服务器逐渐开始出现僵尸进程，segment服务器僵尸进程最高时达到144，master服务器僵尸进程最高时超过1000。gpcheckperf测试完成后所有僵尸进程消失。

ps 命令监控<defunct>进程的情况，segment服务器上的僵尸进程名为gpnetbenchServe：3177632026 [gpnetbenchServe] <defunct> 19:08:23 00:00:00；master服务器上除了gpnetbenchServe以外，还有大量的ssh僵尸进程：6733 6526 [ssh] <defunct>19:07:05 00:00:00

综上，可以确定僵尸进程是由于gpcheckperf工具做矩阵式网络测试时产生，网络测试完成后消失。

03

追根溯源，根本原因究竟是什么？

1. 矩阵式网络测试的原理

所测试的每一台服务器都作为TCPServer，每一台服务器同时作为Client，向所有其他服务器发包。最终形成一个收发测试网络，从而达到整个网络高压测试的目的。随着所测试的服务器越多，其网络测试压力越大，所产生的网络连接越多。

本次测试的服务器规模很大，同时测试12台，是较多僵尸进程的原因之一。

如果小规模的测试，僵尸进程的数量不一定能达到告警的规模。

2. gpcheckperf工具的原理

测试发起方也就是master服务器（执行命令的服务器），其首先需要通过ssh向各个服务器发起启动网络测试的Server和Client。

由于本次测试涉及12台服务器的矩阵式测试，master会发起12*12=144个ssh命令。

启动矩阵式的网络测试之后，每台服务器上都应该有12个client进程，以及1个Server进程。

矩阵式网络发包会持续3分钟。而各对C/S的发包进程启动和结束时间是不同的。因此有些进程会较早结束，有些进程会较晚结束。而由于gpcheckperf对于较早结束的子进程并没有进行及时回收，就会出现子进程自己结束和主进程退出之前处于defunct状态。

master服务器上之所以僵尸进程会更多，是因为master是命令发起者，需要通过ssh进程去启动各个服务器的子进程。其某个子进程的网络发包测试结束后，ssh的操作进程本身也会短时间处于defunct状态。

04

值得借鉴！总结2条靠谱的实施经验

gpcheckperf做服务器的硬件性能测试，是常规的测试工具。在新系统部署，新设备安装部署期间都会经常使用该工具进行测试。

1. 对于已投产的设备，如果对其硬件状况产生怀疑的情况下，也需要用该工具进行测试验证。

2. 对于已投产纳管的服务器，以后在需要做gpcheckperf测试之前，建议都先把系统置为维护期。必须在维护期中方可进行测试。