You'll Never Walk Alone!
1 | 0 1 2 3 |
前一阵加了一个活跃连接数的监控，顺手发现了服务里一个协程泄露的坑，后面看了commit记录这个bug从这个项目开始就一直存在了。。。
最近在ddsserver上加入了客户端活跃连接数的监控。这个服务是一个使用openresty开发的项目，连接数监控有现成的nginx c module，加入参数 –with-http_stub_status_module 重新编译openresty后在nginx.conf加入1
stub_status on
在lua代码中直接可以访问这个内置变量 ngx.var.connections_active 来获取当前的连接数，将这个变量集成进prometheus监控里1
monitor_logger:set("metric_connections", ngx.var.connections_active, {"active"})
在本地测试没有问题后就美滋滋地更新到线上了。
最近在配合研究部门重构ezmt，顺手把热词服务训练相关的模块进行了重构（其实接手这个服务捋清了逻辑后早就想重构了，这次正好趁机搞一下）。在联调结束后，用wrk压了一下性能，结果大跌眼镜，开了6个worker, 但是提高压测的线程数和连接数，QPS始终不见上涨， 几轮压下来QPS只有16-17左右，随着压力的上升，timeout现象非常严重。
于是单独对上游的ezmt热词训练服务压了一下，QPS在29左右1
2
3
4
5
6
7
8
9
10
11
12
13
14[[email protected] /home/aidu35/work/third/wrk]$ ./wrk -t 2 -c 10 -d 30s --latency -s scripts/hotword.lua http://10.12.8.19:8001
Running 30s test @ http://10.12.8.19:8001
2 threads and 10 connections
Thread Stats Avg Stdev Max +/- Stdev
Latency 341.88ms 46.86ms 520.05ms 69.14%
Req/Sec 15.19 6.48 40.00 89.67%
Latency Distribution
50% 341.40ms
75% 373.19ms
90% 403.02ms
99% 451.30ms
875 requests in 30.06s, 0.92MB read
Requests/sec: 29.10
Transfer/sec: 31.17KB
难道是重构后性能下降明显？于是我们将版本回退为重构前的版本又压测了一遍QPS还不到10
进入容器查看了一下压测时的情况，实际cpu和内存的占用都非常低，这种情况，怀疑有很大可能是网络进程中出现了阻塞调用，于是准备抓取网络进程的off-cpu火焰图。