记录一次压测问题

压测出的问题

同一套程序，之前放在服务器上使用，公司内部压测和发布给客户使用，均未出现问题。后由于客户业务需求，将其移植到嵌入式平台。公司内部压测过程中，出现三种异常。

问题1：

大并发压测，服务进程被killed掉。

问题2：

大并发压测，服务挂掉，最后的打印为底层的错误日志。

问题3：

大并发压测，服务挂掉，打印另外的底层错误日志。

分析：

对于问题1，开始怀疑是内存泄漏，编译选项中添加-o0 -fsanitize=address -fno-omit-frame-pointer -fsanitize=leak进行内存检测，未发现异常。但是随着压测的时间推移，服务占用内存还是在缓慢增长。后怀疑是没有限制请求队列大小，当消费者速度跟不上生产者速度时，生产队列堆积变大，使得内存增长。服务器上未出现，是因为服务器硬件资源远大于嵌入式板，短期的压测不至于使服务被系统killed。
降低压测并发数，内存增长导致被killed掉的现象未再出现。

问题2的打印大量日志中，出现了Too many open files，说明是配置的文件描述符不足。
有两种可能，一种是句柄泄露，同样的代码在服务器上未出现，在嵌入式板上出现了，句柄泄露的可能性不大。通过cat /proc/$id/limits查看到嵌入式板默认配置的fd数量为1024，而服务器上被配置为655350。为了验证问题，加大并发请求线程数到1024，问题2立马复现，修改fd配置问题得到解决。

问题3未能复现，原因可能同问题2，是fd不足，导致底层接口异常。

总结：

1、服务端压测，要根据需求配置请求并发数，做好负载均衡。
2、作为服务端需要关注fd的配置，系统默认的1024往往不能满足并发需求。
3、同样的程序，在服务器上没问题，在硬件资源紧张的嵌入式硬件上很容易出现问题。资源紧张的平台是检验代码纰漏的很好环境。