Attachment: nginx.conf Description: Binary data
大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) wgm.china 内存很小，CPU压完后都降下来了。 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 15:08 主题：Re: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 压测一会儿以后 nginx 的内存和 cpu 占用情况呢？ 话说应该也要等 ab 所在机器 ( d ) 的 timewait 降低些为好吧。 不过，既然你有那么多机器，为啥要把 redis 和 ab 放一个机器上跑，好像有些奇怪。 2013/3/7 wgm.china <wgm....@gmail.com> ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) -- sp;--- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 kindy61 靠现有信息，我看不出来发生什么问题了。要不你等等春哥，要不就把 lua 文件整理下发出来吧。2013/3/7 wgm.china <wgm....@gmail.com> 内存很小，CPU压完后都降下来了。 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 15:08 主题：Re: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 压测一会儿以后 nginx 的内存和 cpu 占用情况呢？ 话说应该也要等 ab 所在机器 ( d ) 的 timewait 降低些为好吧。 不过，既然你有那么多机器，为啥要把 redis 和 ab 放一个机器上跑，好像有些奇怪。 2013/3/7 wgm.china <wgm....@gmail.com> ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) agentzh Hello! 2013/3/6 wgm.china: > 我用openresty > 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 > 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD > 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; > 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 https://github.com/agentzh/lua-resty-redis#set_keepalive 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 同时应开启 error_log 并使用 error 日志过滤级别，即 error_log logs/error.log error; 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 同时，提供 ab 输出的报告也可能会有帮助。 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt 可以在压测过程中对 nginx 进程进行采样。 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 Best regards, -agentzh agentzh Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh wgm.china 谢谢kindy和春哥的热心帮助，我下午准备一个详细看代码文档。 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 wgm.china 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 azure1st package.path配置在nginx的配置文件中。 是不是每次调用都变长了。 在 2013-3-8 下午6:33，"wgm.china" <wgm....@gmail.com>写道： 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为 --- https://groups.google.com/groups/opt_out。 azure1st 或者放到init_by_lua里 kindy61 同意 Azure 的建议。放到 init_by_lua 或者 nginx 配置里。话说，你的这个写法应该挺耗内存的吧。这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) wgm.china 谢谢Azure、kindy和春哥的热心帮助，我晚上测试了一下，问题正如Azure和kindy 说的一样，package.path 越来越大，内存占用越来越大，我修改了一下代码： 在nginx中配置：lua_package_path ""，问题立马解决。 再次感谢大家的热心帮助，有了大家的热心，我想openresty一定会越来越好，有了春哥的努力贡献，我认为用openresty做生产业务的人家会越来越多。 另外很期待春哥在openresty中增加websocket，那样可以用openresty开发很多很酷的应用。 2013-03-08 wgm.china 发件人：kindy 发送时间：2013-03-08 18:59 主题：Re: 回复: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 同意 Azure 的建议。 放到 init_by_lua 或者 nginx 配置里。 话说， 你的这个写法应该挺耗内存的吧。 这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) -- sp;--- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) -- sp;--- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
内存很小，CPU压完后都降下来了。 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 15:08 主题：Re: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 压测一会儿以后 nginx 的内存和 cpu 占用情况呢？ 话说应该也要等 ab 所在机器 ( d ) 的 timewait 降低些为好吧。 不过，既然你有那么多机器，为啥要把 redis 和 ab 放一个机器上跑，好像有些奇怪。 2013/3/7 wgm.china <wgm....@gmail.com> ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) agentzh Hello! 2013/3/6 wgm.china: > 我用openresty > 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 > 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD > 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; > 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 https://github.com/agentzh/lua-resty-redis#set_keepalive 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 同时应开启 error_log 并使用 error 日志过滤级别，即 error_log logs/error.log error; 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 同时，提供 ab 输出的报告也可能会有帮助。 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt 可以在压测过程中对 nginx 进程进行采样。 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 Best regards, -agentzh agentzh Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh wgm.china 谢谢kindy和春哥的热心帮助，我下午准备一个详细看代码文档。 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 wgm.china 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 azure1st package.path配置在nginx的配置文件中。 是不是每次调用都变长了。 在 2013-3-8 下午6:33，"wgm.china" <wgm....@gmail.com>写道： 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为 --- https://groups.google.com/groups/opt_out。 azure1st 或者放到init_by_lua里 kindy61 同意 Azure 的建议。放到 init_by_lua 或者 nginx 配置里。话说，你的这个写法应该挺耗内存的吧。这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) wgm.china 谢谢Azure、kindy和春哥的热心帮助，我晚上测试了一下，问题正如Azure和kindy 说的一样，package.path 越来越大，内存占用越来越大，我修改了一下代码： 在nginx中配置：lua_package_path ""，问题立马解决。 再次感谢大家的热心帮助，有了大家的热心，我想openresty一定会越来越好，有了春哥的努力贡献，我认为用openresty做生产业务的人家会越来越多。 另外很期待春哥在openresty中增加websocket，那样可以用openresty开发很多很酷的应用。 2013-03-08 wgm.china 发件人：kindy 发送时间：2013-03-08 18:59 主题：Re: 回复: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 同意 Azure 的建议。 放到 init_by_lua 或者 nginx 配置里。 话说， 你的这个写法应该挺耗内存的吧。 这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) -- sp;--- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
ab 运行在d 这台机器上，redis的请求都使用了连接池，timewait 为0 是指被测试机（a,b,c） 2013-03-07 wgm.china 发件人：kindy 发送时间：2013-03-07 14:32 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 话说 ab 运行在哪里？nginx 又运行在哪里？ 看出来好像 redis 是运行在 d 上的。 对 redis 的请求是由 lua 发起的吗？有设置连接池么？ ”等timewait 为0“ 是哪台机器？ 2013/3/7 wgm.china <wgm....@gmail.com> 大家好！ 我用openresty 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 重新压第二台，第二台都是一个现象，重启redis也没有效果。只有重启nginx才恢复，但压力一次以后，性能又开始下降。 其间也试着关闭了error_log和access.log，每次测试间隙也看了端口情况，都是等timewait 为0 才开始第二次压力测试。 因重启nginx马上恢复，所以基本考虑在代码或者是nginx的配置上出现问题，因lua代码太乱了，现把nginx的主要配置做为附件发上来，请大家帮我出出主意，谢谢。 2013-03-07 wgm.china -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) agentzh Hello! 2013/3/6 wgm.china: > 我用openresty > 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 > 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD > 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; > 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 https://github.com/agentzh/lua-resty-redis#set_keepalive 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 同时应开启 error_log 并使用 error 日志过滤级别，即 error_log logs/error.log error; 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 同时，提供 ab 输出的报告也可能会有帮助。 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt 可以在压测过程中对 nginx 进程进行采样。 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 Best regards, -agentzh agentzh Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh wgm.china 谢谢kindy和春哥的热心帮助，我下午准备一个详细看代码文档。 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 wgm.china 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh -- -- 邮件自: 列表“openresty”,专用于技术讨论! 发言: 请发邮件到 openresty@googlegroups.com 退订: 请发邮件至 openresty+unsubscribe@googlegroups.com 详情: http://groups.google.com/group/openresty 官网: http://openresty.org/ 仓库: https://github.com/agentzh/ngx_openresty 建议: 提问的智慧 http://wiki.woodpecker.org.cn/moin/AskForHelp 教程: http://agentzh.org/misc/nginx/agentzh-nginx-tutorials-zhcn.html --- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。 要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。 要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 azure1st package.path配置在nginx的配置文件中。 是不是每次调用都变长了。 在 2013-3-8 下午6:33，"wgm.china" <wgm....@gmail.com>写道： 非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为 --- https://groups.google.com/groups/opt_out。 azure1st 或者放到init_by_lua里 kindy61 同意 Azure 的建议。放到 init_by_lua 或者 nginx 配置里。话说，你的这个写法应该挺耗内存的吧。这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) wgm.china 谢谢Azure、kindy和春哥的热心帮助，我晚上测试了一下，问题正如Azure和kindy 说的一样，package.path 越来越大，内存占用越来越大，我修改了一下代码： 在nginx中配置：lua_package_path ""，问题立马解决。 再次感谢大家的热心帮助，有了大家的热心，我想openresty一定会越来越好，有了春哥的努力贡献，我认为用openresty做生产业务的人家会越来越多。 另外很期待春哥在openresty中增加websocket，那样可以用openresty开发很多很酷的应用。 2013-03-08 wgm.china 发件人：kindy 发送时间：2013-03-08 18:59 主题：Re: 回复: Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： 同意 Azure 的建议。 放到 init_by_lua 或者 nginx 配置里。 话说， 你的这个写法应该挺耗内存的吧。 这么每次都拼串 (package.path )，有越来越多的内存 copy 要做。所以会越来越慢。。。 On Fri, Mar 8, 2013 at 6:47 PM, azure wang <azu...@gmail.com> wrote: 或者放到init_by_lua里 -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。 -- - - - - - - - - - - - -林青(Kindy Lin) -- sp;--- 您收到此邮件是因为您订阅了 Google 网上论坛的“openresty”论坛。要退订此论坛并停止接收此论坛的电子邮件，请发送电子邮件到 openresty+unsubscribe@googlegroups.com。要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
Hello! 2013/3/6 wgm.china: > 我用openresty > 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 > 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD > 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; > 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 https://github.com/agentzh/lua-resty-redis#set_keepalive 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 同时应开启 error_log 并使用 error 日志过滤级别，即 error_log logs/error.log error; 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 同时，提供 ab 输出的报告也可能会有帮助。 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt 可以在压测过程中对 nginx 进程进行采样。 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 Best regards, -agentzh
Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/"; >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为邮件附件或者放到 github gist 等公网可见的地方）。 > 还有，为方便隔离网络上的潜在问题，你可以首先尝试 ab、nginx 和 redis 都运行在同一台机器上的情形。"Test the simplest thing that could possibly work." Best regards, -agentzh
package.path配置在nginx的配置文件中。 是不是每次调用都变长了。
非常感谢春哥和kindy的建议，我下午准备把代码简化一下时，发现问题代码了，我做了一个代码可以重现错误了。 test.lua package.path = package.path ..";/usr/local/gcsfun/?.lua;"local fun = require "gcs1_3.fun1"local cjson = require "cjson"local config_table = ngx.shared.gcs_config --声明ngx.shared.gcs_configlocal gcs_upload_path = config_table:set("test","wang") ngx.say("test:".. config_table:get("test"))local wang = "wang"ngx.say("test:"..wang) usr/local/gcsfun/gcs1_3/fun1.lua 是我们的一些公共函数 这一次测试场景：1台机器（cpu i3 ,mem 16G,disk 128 mstatSSD）,ab 测试。 做压力测试发现一个特别奇怪的现象就是第一次测试，19000+ [#/sec]，第二次压，8000+，第三次5000+，直到300+。 我找到问题代码： package.path = package.path ..";/usr/local/gcsfun/?.lua;"我把这段注释后，把函数复掉到lualib的目录下测试就稳定在19000+ [#/sec]左右。 春哥和kindy能不能告诉我一下，这段代码的问题出在哪里？ 2013-03-08 wgm.china 发件人：agentzh 发送时间：2013-03-08 03:47 主题：Re: [openresty] 用ab -k 压resty，越来越慢 收件人："openresty"<openresty@googlegroups.com> 抄送： Hello! 2013/3/7 agentzh <age...@gmail.com>: > 2013/3/6 wgm.china: >> 我用openresty >> 1.2.6.3做了一个访问接口，架设了三台设备（a,b,c）和1台测试机（d，redis），四台设备用一个千兆交换机连接，三台设备都连接d上的redis。 >> 测试设备的基本情况：cpu i3 双核 ，16G 内存，128G mstat SSD >> 用ab -k -c10 -n50000 "http://192.168.1.101/file?method=list&path=/" >> 做压力测试发现一个特别奇怪的现象就是第一次测试，5000+ [#/sec]，第二次压，2000+，第三次1000+，直到800+。 > > 从现象上看起来像是你的临时端口用尽了，毕竟一次要发 5 万个请求。 > > 你的 lua-resty-redis 的连接池很可能没有正确配置，否则压再多请求也不会用尽临时端口。请确保你在你的 Lua 代码中实际检查 > red:set_keepalive 方法的返回值。毕竟不少用户容易使用错误。 > > https://github.com/agentzh/lua-resty-redis#set_keepalive > > 当你的 redis 连接池实际生效时，是不应看到大量的 TIME_WAIT 状态的连接的。 > > 同时应开启 error_log 并使用 error 日志过滤级别，即 > > error_log logs/error.log error; > > 否则大量出错时，你看不到错误消息，无法诊断问题。在做压力测试时，应时刻关注 nginx 错误日志里的输出。 > > 重启 nginx 才生效，看起来像是 nginx 一直在忙于输出错误日志（即使你指向了 /dev/null）。 > > 另外，请首先尝试 lua-resty-redis 文档中的最小化示例，以确保官方示例是可以工作的。 > > 同时，提供 ab 输出的报告也可能会有帮助。 > > 压力测试下，nginx worker 进程和 redis 进程的 CPU 使用率细节是怎样的？us, sy, id, wa 这些 CPU 指标是怎样的？ > > 使用 C 级别的火焰图工具可以有助于分析你的 nginx 进程究竟在忙着做什么： > > https://github.com/agentzh/nginx-systemtap-toolkit#ngx-sample-bt > > 可以在压测过程中对 nginx 进程进行采样。 > > 最后，建议将你的 Lua 代码最小化之后公布出来（作为 --- https://groups.google.com/groups/opt_out。
或者放到init_by_lua里
或者放到init_by_lua里 -- #xA0要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
或者放到init_by_lua里 -- sp要查看更多选项，请访问 https://groups.google.com/groups/opt_out。
