从1.7.2.1 升级到 1.11.2.2 性能变差了

xfwangcheers · 2017-04-18T22:05:00+00:00

管用，多谢啦在 2017年4月18日星期二 UTC+8下午2:20:41，WenMing&...

从1.7.2.1 升级到 1.11.2.2 性能变差了

xfwangcheers

大家好，

今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了，同样的并发下，TPS 从 38K 降到了 31K，降了将近 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？

xfwangcheers

另外，压测的机器是 CPU 32 核, 256G RAM， 22 个 nginx 工作进程，8 个 redis 实例，通过 redis2-nginx-module 基于 unix socket 访问本机 redis

On Tuesday, April 18, 2017 at 10:05:00 PM UTC+8, xfwang...@gmail.com wrote:

大家好，

今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了，同样的并发下，TPS 从 38K 降到了 31K，降了将近 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？

xfwangcheers

今天又压了一下：

* 挑了 1.9.7.2 和 1.9.15.1，相对于我们生产环境中的 1.7.2.1 看起来 QPS 没有下降，RT 和 CPU 使用率基本维持不变；

* 再压了 1.11.2.1 以及 1.11.2.3rc1，现象同 1.11.2.2，QPS 下降 15%，CPU 使用率维持不变，RT 略微降低，TP99 变得更平稳，所以这也太诡异了，理论上响应越快，吞吐量不应该越高吗？

感觉应该是 nginx 的问题，而不是 lua 模块的问题，虽然看起来很不一样，但还是没看懂 :) 请大家帮忙分析下，

1.7.2.1 的 C 级火焰图 https://drive.google.com/open?id=0B6BhdPcYDd4cWEpDakY4ZW5reUU

1.11.2. 1 的 C 级火焰图 https://drive.google.com/open?id=0B6BhdPcYDd4cR2hiQVZ6U3NsdDQ

On Tuesday, April 18, 2017 at 10:05:00 PM UTC+8, xfwang...@gmail.com wrote:

大家好，

今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了，同样的并发下，TPS 从 38K 降到了 31K，降了将近 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？

agentzh

Hello!

请只使用单个 nginx worker 进程，然后把这个进程的 CPU 压到 100%，然后比较吞吐量。然后在满载时，同时作出 on-CPU
火焰图和 off-CPU 火焰图。

另外，确保你前后都启用了连接池。通过检查 TIME WAIT 状态的连接可以确认。

nginx 核心如果有 15% 的性能下降，社区早炸了，我们也早注意到了。我觉得是你的性能压测方式或测量误差的问题。

Regards,
Yichun


2017-04-20 6:50 GMT-07:00  <xfwan...@gmail.com>:
> 今天又压了一下：
> * 挑了 1.9.7.2 和 1.9.15.1，相对于我们生产环境中的 1.7.2.1 看起来 QPS 没有下降，RT 和 CPU 使用率基本维持不变；
> * 再压了 1.11.2.1 以及 1.11.2.3rc1，现象同 1.11.2.2，QPS 下降 15%，CPU 使用率维持不变，RT
> 略微降低，TP99 变得更平稳，所以这也太诡异了，理论上响应越快，吞吐量不应该越高吗？
>
> 感觉应该是 nginx 的问题，而不是 lua 模块的问题，虽然看起来很不一样，但还是没看懂 :)  请大家帮忙分析下，
>
> 1.7.2.1 的 C 级火焰图
> https://drive.google.com/open?id=0B6BhdPcYDd4cWEpDakY4ZW5reUU
>
> 1.11.2. 1 的 C 级火焰图
> https://drive.google.com/open?id=0B6BhdPcYDd4cR2hiQVZ6U3NsdDQ
>
>
> On Tuesday, April 18, 2017 at 10:05:00 PM UTC+8, xfwang...@gmail.com wrote:
>>
>> 大家好，
>>
>> 今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了， 同样的并发下，TPS 从 38K 降到了 31K，降了将近
>> 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，
>> 应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？
>>
>>
> --
>

agentzh

Hello!

另外，值得一提的是，accept_mutex 这条配置在新版的 nginx 上默认是
off。你可以试验这个配置。有许这会导致你自己压测的区别（但对于真实流量，应置为 off，可以让流量在不同 worker
之间的分摊更均匀）。

如果你不把 nginx 各个 worker 进程的 CPU 都压到 100%，比较绝对性能是不太靠谱的。

Regards,
-agentzh

2017-04-20 10:34 GMT-07:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 请只使用单个 nginx worker 进程，然后把这个进程的 CPU 压到 100%，然后比较吞吐量。然后在满载时，同时作出 on-CPU
> 火焰图和 off-CPU 火焰图。
>
> 另外，确保你前后都启用了连接池。通过检查 TIME WAIT 状态的连接可以确认。
>
> nginx 核心如果有 15% 的性能下降，社区早炸了，我们也早注意到了。我觉得是你的性能压测方式或测量误差的问题。
>
> Regards,
> Yichun
>
>
> 2017-04-20 6:50 GMT-07:00  <xfwan...@gmail.com>:
>> 今天又压了一下：
>> * 挑了 1.9.7.2 和 1.9.15.1，相对于我们生产环境中的 1.7.2.1 看起来 QPS 没有下降，RT 和 CPU 使用率基本维持不变；
>> * 再压了 1.11.2.1 以及 1.11.2.3rc1，现象同 1.11.2.2，QPS 下降 15%，CPU 使用率维持不变，RT
>> 略微降低，TP99 变得更平稳，所以这也太诡异了，理论上响应越快，吞吐量不应该越高吗？
>>
>> 感觉应该是 nginx 的问题，而不是 lua 模块的问题，虽然看起来很不一样，但还是没看懂 :)  请大家帮忙分析下，
>>
>> 1.7.2.1 的 C 级火焰图
>> https://drive.google.com/open?id=0B6BhdPcYDd4cWEpDakY4ZW5reUU
>>
>> 1.11.2. 1 的 C 级火焰图
>> https://drive.google.com/open?id=0B6BhdPcYDd4cR2hiQVZ6U3NsdDQ
>>
>>
>> On Tuesday, April 18, 2017 at 10:05:00 PM UTC+8, xfwang...@gmail.com wrote:
>>>
>>> 大家好，
>>>
>>> 今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了， 同样的并发下，TPS 从 38K 降到了 31K，降了将近
>>> 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，
>>> 应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？
>>>
>>>
>> --
>>

xfwangcheers

对于 accept_mutex 这个变化之前也注意到了，我昨天也专门切换过观察，性能没有什么变化，其实，仔细对比版本会发现刚好不在这个案例内，根据发布说明 accept_mutex 是从 1.11.3 开始默认为 off，之前版本（即含我们这里的 1.11.2）默认都是 on 的，我们一直用的是 on，accept_mutex_delay 配置为 50ms —— 无论如何，这个两个压测场景此配置项一样

对于连接池，前端请求没有启用 keepalive，upstream 都是 keepalive —— 无论如何，这个两个压测场景此配置项一样

对于系统负载，300 个并发 CPU Usage 80%，Load 26 左右（共32核），分别再加 100 并发到 400 和 500 时，系统负载无明显变化，即 CPU 使用率再也上不去了，吞吐量基本不提升，也不下降，但延迟会增大 —— 单个版本，持续加压的过程，性能表现是一样的

稍候我会再试一下单一进程的情况，另外， off-CPU 数据我抓不到，直接报错：

./openresty-systemtap-toolkit-master/sample-bt-off-cpu -p 15596 -t 10 -u > /tmp/stap/c-off.bt
semantic error: while resolving probe point: identifier 'scheduler' at <input>:28:7
        source: probe scheduler.cpu_on {
                      ^

semantic error: no match

Pass 2: analysis failed.  [man error::pass2]

关于两个版本的压测，我想说的是，我们在同一台服务器上、nginx完全一样配置、lua 代码完全一样，压测样本数据完全一样，唯一变化的就是 nginx/lua-module 的版本而已，如果 nginx/lua-module 新版本本身性能没有问题，那么只能说明我们原有的配置或者代码与新版本有冲突，需要调校，可惜我翻了最近几个 release notes 没有找到任何有用的信息

补充说明的是，1.9.x 版，并没有发现吞吐量降低的现象， 1.11.x 是吞吐量降低，但延迟也降低，且 TP99 会更平稳（1.7/1.9 在同样的压力下，TP99 比 1.11 延迟大，且抖动更厉害），难道 1.11.x 修改了某个默认选项导致了倾向于用低吞吐量换取低延迟？对于大多数应用场景，在延迟不大的情况下，应该倾向于更高的吞吐量

On Friday, April 21, 2017 at 1:38:03 AM UTC+8, agentzh wrote:

Hello!

另外，值得一提的是，accept_mutex 这条配置在新版的 nginx 上默认是
off。你可以试验这个配置。有许这会导致你自己压测的区别（但对于真实流量，应置为 off，可以让流量在不同 worker
之间的分摊更均匀）。

如果你不把 nginx 各个 worker 进程的 CPU 都压到 100%，比较绝对性能是不太靠谱的。

Regards,
-agentzh

2017-04-20 10:34 GMT-07:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 请只使用单个 nginx worker 进程，然后把这个进程的 CPU 压到 100%，然后比较吞吐量。然后在满载时，同时作出 on-CPU
> 火焰图和 off-CPU 火焰图。
>
> 另外，确保你前后都启用了连接池。通过检查 TIME WAIT 状态的连接可以确认。
>
> nginx 核心如果有 15% 的性能下降，社区早炸了，我们也早注意到了。我觉得是你的性能压测方式或测量误差的问题。
>
> Regards,
> Yichun
>
>
> 2017-04-20 6:50 GMT-07:00 <xfwang...@gmail.com>:
>> 今天又压了一下：
>> * 挑了 1.9.7.2 和 1.9.15.1，相对于我们生产环境中的 1.7.2.1 看起来 QPS 没有下降，RT 和 CPU 使用率基本维持不变；
>> * 再压了 1.11.2.1 以及 1.11.2.3rc1，现象同 1.11.2.2，QPS 下降 15%，CPU 使用率维持不变，RT
>> 略微降低，TP99 变得更平稳，所以这也太诡异了，理论上响应越快，吞吐量不应该越高吗？
>>
>> 感觉应该是 nginx 的问题，而不是 lua 模块的问题，虽然看起来很不一样，但还是没看懂 :) 请大家帮忙分析下，
>>
>> 1.7.2.1 的 C 级火焰图
>> https://drive.google.com/open?id=0B6BhdPcYDd4cWEpDakY4ZW5reUU
>>
>> 1.11.2. 1 的 C 级火焰图
>> https://drive.google.com/open?id=0B6BhdPcYDd4cR2hiQVZ6U3NsdDQ
>>
>>
>> On Tuesday, April 18, 2017 at 10:05:00 PM UTC+8, xfwang...@gmail.com wrote:
>>>
>>> 大家好，
>>>
>>> 今天从 1.7.2.1 升级到 1.11.2.2，经过压测发现性能竟然变差了，同样的并发下，TPS 从 38K 降到了 31K，降了将近
>>> 20%，不过响应时间新版本稍微好一点点，TP99 能从 25ms 降低到 20ms 左右，新老版本 CPU 使用率差不多，都是 80% 左右，
>>> 应用代码一行都没有变化，都是从源码编译，编译选项完全一样，不知大家有什么建议？
>>>
>>>
>> --
>>

agentzh

Hello!

2017-04-20 19:58 GMT-07:00  xfwangcheers:
> 对于系统负载，300 个并发 CPU Usage  80%，Load 26 左右（共32核），分别再加 100 并发到 400 和 500
> 时，系统负载无明显变化，即 CPU 使用率再也上不去了，吞吐量基本不提升，也不下降，但延迟会增大 —— 单个版本，持续加压的过程，性能表现是一样的
>

nginx 进程的 CPU 使用率压不上去，说明有东西阻塞， 或者其他东西成为瓶颈（比如你的 redis 后端）。此时你更应该作出
off-CPU 火焰图来看了，说不定把阻塞的东西去掉，你的 openresty 的吞吐量可以大大提升。nginx 进程一般是可以压满 CPU
的，压不满通常是因为有阻塞 IO 或者后端成为瓶颈。

> 稍候我会再试一下单一进程的情况， 另外， off-CPU 数据我抓不到，直接报错：
>  ./openresty-systemtap-toolkit-master/sample-bt-off-cpu -p 15596 -t 10 -u >
> /tmp/stap/c-off.bt
> semantic error: while resolving probe point: identifier 'scheduler' at
> <input>:28:7
>         source: probe scheduler.cpu_on {
>                       ^
>

明显这是因为你没有安装对应版本的内核调试符号包。可以参考下面这篇 systemtap 安装文档：

https://www.sourceware.org/systemtap/SystemTap_Beginners_Guide/using-systemtap.html

你如果 google 这个错误消息，应该可以看到一堆类似的讨论过的贴子。应该养成平时 google 错误的好习惯。

Regards,
Yichun

agentzh

Hello!

另外，值得一提的是，自己压测，尽量使用客户端keepalive，否则一来很容易把临时端口耗尽，二来也没必要关心连接创建和释放本身的开销（即
TCP/IP 协议栈的开销），从而提高性能测试结果的可靠性。

Regards,
Yichun

2017-04-21 16:03 GMT-07:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 2017-04-20 19:58 GMT-07:00  xfwangcheers:
>> 对于系统负载，300 个并发 CPU Usage  80%，Load 26 左右（共32核），分别再加 100 并发到 400 和 500
>> 时，系统负载无明显变化，即 CPU 使用率再也上不去了，吞吐量基本不提升，也不下降，但延迟会增大 —— 单个版本，持续加压的过程，性能表现是一样的
>>
>
> nginx 进程的 CPU 使用率压不上去，说明有东西阻塞， 或者其他东西成为瓶颈（比如你的 redis 后端）。此时你更应该作出
> off-CPU 火焰图来看了，说不定把阻塞的东西去掉，你的 openresty 的吞吐量可以大大提升。nginx 进程一般是可以压满 CPU
> 的，压不满通常是因为有阻塞 IO 或者后端成为瓶颈。
>
>> 稍候我会再试一下单一进程的情况， 另外， off-CPU 数据我抓不到，直接报错：
>>  ./openresty-systemtap-toolkit-master/sample-bt-off-cpu -p 15596 -t 10 -u >
>> /tmp/stap/c-off.bt
>> semantic error: while resolving probe point: identifier 'scheduler' at
>> <input>:28:7
>>         source: probe scheduler.cpu_on {
>>                       ^
>>
>
> 明显这是因为你没有安装对应版本的内核调试符号包。可以参考下面这篇 systemtap 安装文档：
>
> https://www.sourceware.org/systemtap/SystemTap_Beginners_Guide/using-systemtap.html
>
> 你如果 google 这个错误消息，应该可以看到一堆类似的讨论过的贴子。应该养成平时 google 错误的好习惯。
>
> Regards,
> Yichun

xfwangcheers

keepalive 试过开启，使用配置 keepalive_timeout 10 keepalive_requests 1000 但是效果不明显，即使 keepalive_timeout 0，TIME_WAIT 也很少，可能跟我们的压测工具有关系

off-cpu 那个问题解决了，搞了个乌龙，需要装的是 kernel-debuginfo 安装成了 kernel-debug-debuginfo

把现有的 accept_mutex 从 on 改成了 off（允许惊群），并把 multi_accept 关了，吞吐量提升了近 20%，单 worker CPU 能达到 100%，多进程能达到 95% 以上了

之前 cpu 在 80% 以后上不去，主要应该被 multi_accept on 和 accept_mutex_delay 50ms 阻塞了，导致单 worker 负载过大，并且不均衡

但是在同样的配置下，即 accept_mutex off 和 multi_accept off，1.11.2.x 吞吐量还是不如 1.7.x 和 1.9.x，具体火焰图稍晚再出跟大家分享，暂且决定只升级到 1.9.15 了

谢谢

On Saturday, April 22, 2017 at 7:06:16 AM UTC+8, agentzh wrote:

Hello!

另外，值得一提的是，自己压测，尽量使用客户端keepalive，否则一来很容易把临时端口耗尽，二来也没必要关心连接创建和释放本身的开销（即
TCP/IP 协议栈的开销），从而提高性能测试结果的可靠性。

Regards,
Yichun

2017-04-21 16:03 GMT-07:00 Yichun Zhang (agentzh) <age...@gmail.com>:
> Hello!
>
> 2017-04-20 19:58 GMT-07:00 xfwangcheers:
>> 对于系统负载，300 个并发 CPU Usage 80%，Load 26 左右（共32核），分别再加 100 并发到 400 和 500
>> 时，系统负载无明显变化，即 CPU 使用率再也上不去了，吞吐量基本不提升，也不下降，但延迟会增大 —— 单个版本，持续加压的过程，性能表现是一样的
>>
>
> nginx 进程的 CPU 使用率压不上去，说明有东西阻塞，或者其他东西成为瓶颈（比如你的 redis 后端）。此时你更应该作出
> off-CPU 火焰图来看了，说不定把阻塞的东西去掉，你的 openresty 的吞吐量可以大大提升。nginx 进程一般是可以压满 CPU
> 的，压不满通常是因为有阻塞 IO 或者后端成为瓶颈。
>
>> 稍候我会再试一下单一进程的情况，另外， off-CPU 数据我抓不到，直接报错：
>> ./openresty-systemtap-toolkit-master/sample-bt-off-cpu -p 15596 -t 10 -u >
>> /tmp/stap/c-off.bt
>> semantic error: while resolving probe point: identifier 'scheduler' at
>> <input>:28:7
>> source: probe scheduler.cpu_on {
>> ^
>>
>
> 明显这是因为你没有安装对应版本的内核调试符号包。可以参考下面这篇 systemtap 安装文档：
>
> https://www.sourceware.org/systemtap/SystemTap_Beginners_Guide/using-systemtap.html
>
> 你如果 google 这个错误消息，应该可以看到一堆类似的讨论过的贴子。应该养成平时 google 错误的好习惯。
>
> Regards,
> Yichun