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。 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。
或者放到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。