关于resty-upload的问题

wgm.china

春哥：
	你好！
	在我生产系统中使用opresty 1.2.8.5,客户端用c + libcurl开发的客户端post文件上来。客户端的代码直接用libcurl的样例（http://curl.haxx.se/libcurl/c/multi-post.html）;

	error.log中一直报：
	2013/10/26 23:06:39 [alert] 30562#0: *86 send() returned zero (11: Resource temporarily unavailable), client: 173.13.4.73, server: , request: "POST /vss/gdga_1.3/upload_net?path=/hik&data=1%253B1303%253B44060655A002%253B20131023182237160%253B1%253B%25E6%259C%25AA%25E8%25AF%2586%25E5%2588%25AB%25E7%2589%258C%253B4%253B0%253B91%253B0%253B0%253B5%253B HTTP/1.1", host: "173.13.4.222"

	不知道是什么原因？

agentzh

Hello!

2013/10/26 wgm:
>         在我生产系统中使用opresty 1.2.8.5,客户端用c + libcurl开发的客户端post文件上来。客户端的代码直接用libcurl的样例（http://curl.haxx.se/libcurl/c/multi-post.html）;
>
>         error.log中一直报：
>         2013/10/26 23:06:39 [alert] 30562#0: *86 send() returned zero (11: Resource temporarily unavailable),

这个 alert 消息的问题最早是在 ngx_openresty 1.4.1.1 中修复的。建议升级到最新的主线版 1.4.2.9
或者最新的稳定版 1.4.2.8.

Best regards,
-agentzh

wgm.china

谢谢春哥，我已经升级了，这个问题已经解决了。
谢谢。





在 2013-10-27，上午1:48，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：

> Hello!
> 
> 2013/10/26 wgm:
>>        在我生产系统中使用opresty 1.2.8.5,客户端用c + libcurl开发的客户端post文件上来。客户端的代码直接用libcurl的样例（http://curl.haxx.se/libcurl/c/multi-post.html）;
>> 
>>        error.log中一直报：
>>        2013/10/26 23:06:39 [alert] 30562#0: *86 send() returned zero (11: Resource temporarily unavailable),
> 
> 这个 alert 消息的问题最早是在 ngx_openresty 1.4.1.1 中修复的。建议升级到最新的主线版 1.4.2.9
> 或者最新的稳定版 1.4.2.8.
> 
> Best regards,
> -agentzh
> 
> -- 
>

wgm.china

春哥：
	你好！
	我现在又发现一个问题，就是在客户端启动50个线程设置发送超时时间过短，比如200ms时，服务器端nginx进程会死掉，特别是把客户端kill 后，nginx一定会死掉。
	我分析可能是我没有增加ngx.on_abort去判断客户端主动断开，没有调用ngx.exit(),所以nginx进程会死掉。我用ab 进做系统压力测试时一切正常。
	不知道是不是在客户端主动断开后，调用resty_upload是否需要做什么处理？




在 2013-10-27，下午12:54，wgm <wgm....@gmail.com> 写道：

> 谢谢春哥，我已经升级了，这个问题已经解决了。
> 谢谢。
> 
> 
> 
> 
> 
> 在 2013-10-27，上午1:48，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
> 
>> Hello!
>> 
>> 2013/10/26 wgm:
>>>       在我生产系统中使用opresty 1.2.8.5,客户端用c + libcurl开发的客户端post文件上来。客户端的代码直接用libcurl的样例（http://curl.haxx.se/libcurl/c/multi-post.html）;
>>> 
>>>       error.log中一直报：
>>>       2013/10/26 23:06:39 [alert] 30562#0: *86 send() returned zero (11: Resource temporarily unavailable),
>> 
>> 这个 alert 消息的问题最早是在 ngx_openresty 1.4.1.1 中修复的。建议升级到最新的主线版 1.4.2.9
>> 或者最新的稳定版 1.4.2.8.
>> 
>> Best regards,
>> -agentzh
>> 
>> -- 
>>

agentzh

Hello!

2013/10/30 wgm:
>         我现在又发现一个问题，就是在客户端启动50个线程设置发送超时时间过短，比如200ms时，服务器端nginx进程会死掉，特别是把客户端kill 后，nginx一定会死掉。

请定义你这里使用的"死掉"一词。这究竟是 nginx 进程崩溃，还是 nginx 进程 CPU 占用 100%，抑或是留下了永远处于
CLOSE_WAIT 状态的连接？

另外，建议提供一个最小化的完整示例和复现问题的步骤，这样我可以在我本地看到你看到的问题。

>         我分析可能是我没有增加ngx.on_abort去判断客户端主动断开，没有调用ngx.exit(),所以nginx进程会死掉。我用ab 进做系统压力测试时一切正常。

对于读取请求体的服务，一般并不需要设置 ngx.on_abort，因为当连接断开时，读取操作必会立即返回 "closed" 错误（在
recv 调用级别上便会立即返回 0 值）。

Best regards,
-agentzh

wgm.china

你好!
	我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。
	我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。



在 2013-10-31，上午2:54，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：

> Hello!
> 
> 2013/10/30 wgm:
>>        我现在又发现一个问题，就是在客户端启动50个线程设置发送超时时间过短，比如200ms时，服务器端nginx进程会死掉，特别是把客户端kill 后，nginx一定会死掉。
> 
> 请定义你这里使用的"死掉"一词。这究竟是 nginx 进程崩溃，还是 nginx 进程 CPU 占用 100%，抑或是留下了永远处于
> CLOSE_WAIT 状态的连接？
> 
> 另外，建议提供一个最小化的完整示例和复现问题的步骤，这样我可以在我本地看到你看到的问题。
> 
>>        我分析可能是我没有增加ngx.on_abort去判断客户端主动断开，没有调用ngx.exit(),所以nginx进程会死掉。我用ab 进做系统压力测试时一切正常。
> 
> 对于读取请求体的服务，一般并不需要设置 ngx.on_abort，因为当连接断开时，读取操作必会立即返回 "closed" 错误（在
> recv 调用级别上便会立即返回 0 值）。
> 
> Best regards,
> -agentzh
> 
> -- 
>

wgm.china

春哥：
	我终于在centos上安装上了nginx-systemtap-toolkit，正准备做压力测试时看看nginx的状态。
	不过我在用sample-bt 时报错，不知道是什么原因：
	报错内容：
	ERROR: global variable 'bts' allocation failed
        WARNING: /usr/local/bin/staprun exited with status: 1
        Pass 5: run failed. [man error::pass5]

在 2013-10-31，上午9:56，wgm <wgm....@gmail.com> 写道：

> 你好!
> 	我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。
> 	我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。
> 
> 
> 
> 在 2013-10-31，上午2:54，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
> 
>> Hello!
>> 
>> 2013/10/30 wgm:
>>>       我现在又发现一个问题，就是在客户端启动50个线程设置发送超时时间过短，比如200ms时，服务器端nginx进程会死掉，特别是把客户端kill 后，nginx一定会死掉。
>> 
>> 请定义你这里使用的"死掉"一词。这究竟是 nginx 进程崩溃，还是 nginx 进程 CPU 占用 100%，抑或是留下了永远处于
>> CLOSE_WAIT 状态的连接？
>> 
>> 另外，建议提供一个最小化的完整示例和复现问题的步骤，这样我可以在我本地看到你看到的问题。
>> 
>>>       我分析可能是我没有增加ngx.on_abort去判断客户端主动断开，没有调用ngx.exit(),所以nginx进程会死掉。我用ab 进做系统压力测试时一切正常。
>> 
>> 对于读取请求体的服务，一般并不需要设置 ngx.on_abort，因为当连接断开时，读取操作必会立即返回 "closed" 错误（在
>> recv 调用级别上便会立即返回 0 值）。
>> 
>> Best regards,
>> -agentzh
>> 
>> -- 
>>

wgm.china

春哥：
	你好！
	还有一个问题就是用nginx-systemtap-toolkit怎么调试可以发现我的nginx为什么会假死？


在 2013-10-31，上午9:56，wgm <wgm....@gmail.com> 写道：

> 你好!
> 	我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。
> 	我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。
> 
> 
> 
> 在 2013-10-31，上午2:54，"Yichun Zhang (agentzh)" <age...@gmail.com> 写道：
> 
>> Hello!
>> 
>> 2013/10/30 wgm:
>>>       我现在又发现一个问题，就是在客户端启动50个线程设置发送超时时间过短，比如200ms时，服务器端nginx进程会死掉，特别是把客户端kill 后，nginx一定会死掉。
>> 
>> 请定义你这里使用的"死掉"一词。这究竟是 nginx 进程崩溃，还是 nginx 进程 CPU 占用 100%，抑或是留下了永远处于
>> CLOSE_WAIT 状态的连接？
>> 
>> 另外，建议提供一个最小化的完整示例和复现问题的步骤，这样我可以在我本地看到你看到的问题。
>> 
>>>       我分析可能是我没有增加ngx.on_abort去判断客户端主动断开，没有调用ngx.exit(),所以nginx进程会死掉。我用ab 进做系统压力测试时一切正常。
>> 
>> 对于读取请求体的服务，一般并不需要设置 ngx.on_abort，因为当连接断开时，读取操作必会立即返回 "closed" 错误（在
>> recv 调用级别上便会立即返回 0 值）。
>> 
>> Best regards,
>> -agentzh
>> 
>> -- 
>>

agentzh

Hello!

2013/10/30 wgm:
>         我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。

看起来像是你的 Lua 代码进入某个无限循环了。你可以使用 ngx-lua-bt 工具确定死循环的位置：

    https://github.com/agentzh/nginx-systemtap-toolkit#ngx-lua-bt

>         我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。
>

100% CPU 的问题是最容易通过工具定位的了。比如刚才提到的 ngx-lua-bt 工具和 on-CPU 火焰图工具。

> 不过我在用sample-bt 时报错，不知道是什么原因：
>     报错内容：
>        ERROR: global variable 'bts' allocation failed
>        WARNING: /usr/local/bin/staprun exited with status: 1
>        Pass 5: run failed. [man error::pass5]

貌似你系统上的空闲内存不足以分配 bts 这个 systemtap 变量。你使用的具体是什么命令？你可以尝试下面这条命令

    sample-bt -a '-DMAXMAPENTRIES=3000' -t 3 -p <pid>

如果仍然报那个错误，则你可以再调小 3000 或者 3 这两个数。

另外，建议在运行工具前尽量多地释放你系统中的内存，比如杀掉占用内存多的不那么重要的进程。

>    还有一个问题就是用nginx-systemtap-toolkit怎么调试可以发现我的nginx为什么会假死？

通读 nginx-systemtap-toolkit 的文档并把里面的工具都逐一把玩一遍是一个好办法。前面我也给出了一些更具体的建议。

另外，建议尽量避免使用“假死”这样模糊的词，多使用更准确的术语，比如“CPU 满载”、“进程崩溃”、“段错误”、“连接挂起”，等等。

Best regards,
-agentzh

wgm.china

问题找到了，是在接收form:read()时没有处理无typ的数据情况，一般情况下都没有问题，只有在客户端流未完全发完就直接断开时会出现。
用ngx-lua-bt太方便和准确了。



在 2013-11-1，上午2:52，Yichun Zhang (agentzh) <age...@gmail.com> 写道：

> Hello!
> 
> 2013/10/30 wgm:
>>        我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。
> 
> 看起来像是你的 Lua 代码进入某个无限循环了。你可以使用 ngx-lua-bt 工具确定死循环的位置：
> 
>    https://github.com/agentzh/nginx-systemtap-toolkit#ngx-lua-bt
> 
>>        我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。
>> 
> 
> 100% CPU 的问题是最容易通过工具定位的了。比如刚才提到的 ngx-lua-bt 工具和 on-CPU 火焰图工具。
> 
>> 不过我在用sample-bt 时报错，不知道是什么原因：
>>    报错内容：
>>       ERROR: global variable 'bts' allocation failed
>>       WARNING: /usr/local/bin/staprun exited with status: 1
>>       Pass 5: run failed. [man error::pass5]
> 
> 貌似你系统上的空闲内存不足以分配 bts 这个 systemtap 变量。你使用的具体是什么命令？你可以尝试下面这条命令
> 
>    sample-bt -a '-DMAXMAPENTRIES=3000' -t 3 -p <pid>
> 
> 如果仍然报那个错误，则你可以再调小 3000 或者 3 这两个数。
> 
> 另外，建议在运行工具前尽量多地释放你系统中的内存，比如杀掉占用内存多的不那么重要的进程。
> 
>>   还有一个问题就是用nginx-systemtap-toolkit怎么调试可以发现我的nginx为什么会假死？
> 
> 通读 nginx-systemtap-toolkit 的文档并把里面的工具都逐一把玩一遍是一个好办法。前面我也给出了一些更具体的建议。
> 
> 另外，建议尽量避免使用“假死”这样模糊的词，多使用更准确的术语，比如“CPU 满载”、“进程崩溃”、“段错误”、“连接挂起”，等等。
> 
> Best regards,
> -agentzh
> 
> -- 
>

wgm.china

问题找到了，是在接收form:read()时没有处理无typ的数据情况，一般情况下都没有问题，只有在客户端流未完全发完就直接断开时会出现。
用ngx-lua-bt太方便和准确了。



在 2013-11-1，上午2:52，Yichun Zhang (agentzh) <age...@gmail.com> 写道：

> Hello!
> 
> 2013/10/30 wgm:
>>        我现在发现的是nginx进程CPU占用100%，使用nginx -s reload命令无法重新启动服务。
> 
> 看起来像是你的 Lua 代码进入某个无限循环了。你可以使用 ngx-lua-bt 工具确定死循环的位置：
> 
>    https://github.com/agentzh/nginx-systemtap-toolkit#ngx-lua-bt
> 
>>        我也在准备最小化的完整示例，不知道能否重现这个问题，我用ab做压力时是正常的，只有用C 调用libcurl库模似form提交，50多线程时会把nginx压死。如果用libcurl的应用的话，可能春哥你测试起来太麻烦，它需要安装很多不同的包。我看看有没有其它的办法能够把这个现像重现出来，再最小化一个完整的示例。
>> 
> 
> 100% CPU 的问题是最容易通过工具定位的了。比如刚才提到的 ngx-lua-bt 工具和 on-CPU 火焰图工具。
> 
>> 不过我在用sample-bt 时报错，不知道是什么原因：
>>    报错内容：
>>       ERROR: global variable 'bts' allocation failed
>>       WARNING: /usr/local/bin/staprun exited with status: 1
>>       Pass 5: run failed. [man error::pass5]
> 
> 貌似你系统上的空闲内存不足以分配 bts 这个 systemtap 变量。你使用的具体是什么命令？你可以尝试下面这条命令
> 
>    sample-bt -a '-DMAXMAPENTRIES=3000' -t 3 -p <pid>
> 
> 如果仍然报那个错误，则你可以再调小 3000 或者 3 这两个数。
> 
> 另外，建议在运行工具前尽量多地释放你系统中的内存，比如杀掉占用内存多的不那么重要的进程。
> 
>>   还有一个问题就是用nginx-systemtap-toolkit怎么调试可以发现我的nginx为什么会假死？
> 
> 通读 nginx-systemtap-toolkit 的文档并把里面的工具都逐一把玩一遍是一个好办法。前面我也给出了一些更具体的建议。
> 
> 另外，建议尽量避免使用“假死”这样模糊的词，多使用更准确的术语，比如“CPU 满载”、“进程崩溃”、“段错误”、“连接挂起”，等等。
> 
> Best regards,
> -agentzh
> 
> -- 
>