☰

通过 Nginx VPS 上的管理区域将 WordPress 3.6 更新至 3.7 时挂起并失败

tag-icon • tag-icon php nginx wordpress php-fpm
通过 Nginx VPS 上的管理区域将 WordPress 3.6 更新至 3.7 时挂起并失败

所以我在我的 VPS（Ubuntu 12.10、Nginx、php-fpm 5.4）上运行了几个 WordPress 网站

这些网站都在单独的虚拟主机上，使用自己的配置文件（尽管彼此相似），复杂程度各不相同。其中一个非常简单，使用最少的插件。

当我尝试通过管理区域更新任何站点上的核心时，我单击“立即更新”按钮（该按钮应该在wp-admin/update-core.php页面中运行脚本，挂起一两分钟，然后转到空白的管理页面（即 wp-admin 菜单栏和标题栏在那里，但页面正文中没有内容）。通过静止菜单栏访问另一个管理页面显示核心尚未更新。

检查错误日志时我看到以下条目：

2013/10/29 23:20:48 [错误] 9384#0：*5318248 上游超时（110：连接超时）读取上游时，客户端：--.---.--.--，服务器：www.mysite.com，请求：“POST /wp-admin/update-core.php?action=do-core-upgrade HTTP/1.1”，上游：“fastcgi://unix:/var/run/php5-fpm.sock:”，主机：“mysite.com”，引荐来源：“http://mysite.com/wp-admin/update-core.php“

以前的旧更新中没有发生过这种情况，并且网站的其余部分（包括更新插件）均运行正常。

有什么想法吗？会不会只是超时错误？我觉得不太可能，因为服务器应该在几秒钟内完成 wp 升级。

答案1

WordPress 更新是一个缓慢的过程。

添加

request_terminate_timeout = 300s

到你的 www.conf

您需要在 nginx vhost 文件中增加 fastcgi 读取超时时间

fastcgi_read_timeout 300s

另外，检查 php ini 中的执行时间，或者在 www.conf 中为 php-fpm 重新定义它

php_admin_value[execution_time] = 300

答案2

根据我的经验，您需要检查 WP 更新中的两件事。

  • 网络问题，在服务器上执行 netstat 以查看是否有来自正在更新的 php 进程和外部服务器的连接。有些服务器比其他服务器慢。
  • php-fpm 工作者数量有限，我看到 WP 更新通过 HTTP 调用自身，因此它会锁定所有可用的工作者。

尝试：

  • php-fpm 的 slowlog
  • nginx 在 fastcgi 上的超时时间更长
  • 除了 nutella，strace 是最好的。使用它。

相关内容