首页 文章

由于并发用户导致重负载导致502坏网关错误[关闭]

提问于
浏览 次
-1

我的服务器上安装了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日志

[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] [池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 [14-Feb-2013 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]转储失败

php nginx

1 回答

  • 3

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

    读慢速日志，看起来你的应用程序正在调用curl_exec（）命令，而且这个命令很慢 . 我猜测正在发生的是你的30个并发用户都在请求你的脚本;反过来，你的脚本在某个地方调用另一个web应用程序，这个应用程序要么响应很慢，要么完全超时（基于php.ini中的 max_execution_time ） . 我不知道它启动的最大并发PHP实例数量是多少？因为这些实例都在等待你的CURL请求返回，所以NGINX无法启动任何PHP实例，而是返回一个坏网关 .

    我要看的第一件事是加快脚本的响应时间，或者通过异步运行CURL请求，或者缓存它，或者找到另一种加速它的方法 - 运行同步CURL请求基本上意味着性能和可伸缩性您的网站完全取决于您所呼叫的网址的性能和可扩展性 .

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

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

    回复于

相关问题