-1

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

对于初始用户，它工作正常，但一段时间后它开始抛出 502 bad gateway 错误。

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

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

  • 我需要在 php-fpm.conf 中进行哪些调整才能解决此错误？
  • 如何让 nginx 长时间等待 php-fpm 的响应？
  • 如何增加 php-fpm 最大执行时间？

以下是附上的日志。

NGINX 日志

2013/01/29 15:03:38 [错误] 2493#0: 1046562 recv() 在从上游读取响应标头时失败（104：对等方重置连接），客户端：49.248.0.2，服务器：** * * .com，请求：“GET 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，请求：“GET 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 慢日志

[14-Feb-2013 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() 未知：0 [0x00007f446e8de0d8] call_user_func_array() MY_SCRIPT_PATH_4:359 [0x00007f446e8dd4d0] +++ 转储失败

[14-FEB-2013 12:55:13] [pool www] pid 10117 script_filename = my_script_path [0x00007f446e8e8e06b0 curl_exec（curl_exec（）my_sscript_ppath_ppath_ppath_ppath_path_path_path_path_path_path_path_path_path_path：317 [0x000077f446e.346e.88e.8e8e8ebeservice_14.814ebevice]：34.14.8e8ebeervice） [0x00007fff0102b4d0] convert() 未知：0 [0x00007f446e8de0d8] call_user_func_array() MY_SCRIPT_PATH_4:359 [0x00007f446e8dd4d0] +++ 转储失败

4

1 回答 1

3

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

阅读慢日志，看起来您的应用程序正在调用 curl_exec() 命令，并且该命令很慢。我猜正在发生的是您的 30 个并发用户都在请求您的脚本；反过来，您的脚本正在某处调用另一个 Web 应用程序，该应用程序要么响应非常慢，要么完全超时（基于max_execution_timephp.ini）。我不知道 NGINX 和 PHP-FPM 的来龙去脉，但我认为它触发的并发 PHP 实例的数量是最大的；由于这些实例都在等待您的 CURL 请求返​​回，因此 NGINX 无法启动更多 PHP 实例，而是返回一个错误的网关。

我首先要看的是加快脚本的响应时间，或者通过异步运行 CURL 请求，或者缓存它，或者找到另一种加速它的方法——运行同步 CURL 请求基本上意味着性能和可伸缩性您网站的性能完全取决于您调用的 URL 的性能和可扩展性。

如果您不能这样做，请将 CURL 的超时时间（php.ini 中的 max_execution_time）减少到 5 秒；这将导致您的一些 CURL 请求失败，但至少您的应用可以处理该问题并更快地返回给用户；这也意味着您等待的 PHP 线程要少得多。

大概有一种方法可以增加 NGINX 启动的 PHP 实例的数量。你可以玩这个，但你只是稍微转移了问题 - 没有 Web 服务器可以优雅地支持大量等待线程。

于 2013-02-20T12:54:29.000 回答