由于并发用户的重负载导致502错误的网关错误

时间:2013-02-20 12:34:43

标签: php nginx

我的服务器上安装了Nginx + PHP FPM。我们正在为30个并发用户长期加载服务器。

对于初始用户,它工作正常,但一段时间后它开始抛出502错误的网关错误。

我已经放了一些nginx php-fpm的日志和php-fpm的慢日志。

由于长时间运行的脚本和服务器上的负载,有些条目被记录在php-fpm的慢速日志中。我认为这是502错误网关错误的原因。但我不知道如何解决这个问题。

  • 我需要在php-fpm.conf中进行哪些调整才能解决这些错误?
  • 如何让nginx等待很长时间来回复php-fpm?
  • 如何增加php-fpm最大执行时间?

以下是附加的日志。

NGINX LOG

  

2013/01/29 15:03:38 [错误] 2493#0: 1046562 recv()失败(104:通过对等方重置连接)从上游读取响应头,客户端:49.248.0.2,服务器: ** * * .com,请求:“获取MY_SCRIPT_URI HTTP / 1.1”,上游:“fastcgi:// 127.0.0.1:9000“,主持人:” * **** .com“,推荐人:”MY_SCRIPT_URL“

     

2013/01/29 15:03:39 [错误] 2493#0: 1046561 recv()失败(104:通过对等方重置连接)从上游读取响应头,客户端:49.248.0.2,服务器: ** * .com,请求:“获取MY_SCRIPT_URI HTTP / 1.1”,上游:“fastcgi://127.0 .0.1:9000“,主持人:” * **** .com“,推荐人:”MY_SCRIPT_URL“

这种类型有很多错误,它们在整个文件中重复。

PHP FPM LOG

[14-Feb-2013 12:54:13] ERROR: failed to ptrace(PEEKDATA) pid 10748: Input/output error (5)
[14-Feb-2013 12:54:18] ERROR: failed to ptrace(PEEKDATA) pid 10112: Input/output error (5)
[14-Feb-2013 12:54:18] ERROR: failed to ptrace(PEEKDATA) pid 12147: Input/output error (5)
[14-Feb-2013 12:54:19] ERROR: failed to ptrace(PEEKDATA) pid 30857: Input/output error (5)
[snip: many more]

PHP FPM SLOW LOG

  

[2013年2月14日12:55:13] [pool www] pid 10748   script_filename = MY_SCRIPT_PATH   [0x00007f446e8e06b0] curl_exec()MY_SCRIPT_PATH_1.php:317   [0x00007f446e8e0490] callService()MY_SCRIPT_PATH_2:1331   [0x00007f446e8e0148] convertToPurchaseOrders()MY_SCRIPT_PATH_3:15   [0x00007fff0102b4d0] convertToPurchaseOrders()unknown:0   [0x00007f446e8de0d8] call_user_func_array()MY_SCRIPT_PATH_4:359   [0x00007f446e8dd4d0] +++ dump failed

     

[2013年2月14日12:55:13] [pool www] pid 10117   script_filename = MY_SCRIPT_PATH   [0x00007f446e8e06b0] curl_exec()MY_SCRIPT_PATH_1.php:317   [0x00007f446e8e0490] callService()MY_SCRIPT_PATH_2:1331   [0x00007f446e8e0148] convert()MY_SCRIPT_PATH_3:15   [0x00007fff0102b4d0] convert()unknown:0   [0x00007f446e8de0d8] call_user_func_array()MY_SCRIPT_PATH_4:359   [0x00007f446e8dd4d0] +++ dump failed

1 个答案:

答案 0 :(得分:3)

首先,30个并发用户负载相当低 - 取决于应用程序和硬件,我期待更多。

读取slowlog,看起来你的应用程序正在调用curl_exec()命令,而且这个命令很慢。我猜测的是你的30个并发用户都在请求你的脚本;反过来,你的脚本在某个地方调用另一个Web应用程序,这个应用程序要么响应很慢,要么完全超时(基于php.ini中的max_execution_time)。我不知道NGINX和PHP-FPM的来龙去脉,但我认为它启动的并发PHP实例的最大数量是多少;因为这些实例都在等待你的CURL请求返回,所以NGINX无法启动任何PHP实例,而是返回一个坏网关。

我要注意的第一件事是加快脚本的响应时间,或者通过异步运行CURL请求,或者缓存它,或者找到另一种加速它的方法 - 基本上运行同步CURL请求表示您网站的性能和可扩展性完全取决于您调用的网址的性能和可扩展性。

如果你不能这样做,请将CURL的超时时间(php.ini中的max_execution_time)减少到5秒;这会导致一些CURL请求失败,但至少你的应用程序可以处理它并更快地返回给用户;它还意味着你有更少的PHP线程在等待。

据推测,有一种方法可以增加NGINX启动的PHP实例数量;您可以使用它,但您只是轻微地移动问题 - 没有Web服务器可以优雅地支持大量等待线程。