通過 Nginx VPS 上的管理區域將 WordPress 3.6 更新到 3.7 掛起並失敗
所以我在我的 VPS 上執行了一些 WordPress 站點（Ubuntu 12.10、Nginx、php-fpm 5.4）
這些站點都位於單獨的虛擬主機上，並使用自己的配置文件（儘管彼此相似），並且複雜性各不相同。一個非常簡單，使用最少的外掛。
當我嘗試通過管理區域更新任何站點上的核心時，我點擊“立即更新”按鈕（它應該在
wp-admin/update-core.php頁面中執行腳本掛起一兩分鐘，然後轉到空白管理頁面（即 wp-admin 菜單欄和標題欄存在，但頁面正文中沒有內容）。通過靜止菜單欄訪問另一個管理頁面顯示核心尚未更新。檢查錯誤日誌我看到這個條目：
2013/10/29 23:20:48
$$ error $$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 升級。
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
根據我的經驗，您希望通過 WP 更新檢查兩件事。
- 網路問題，在伺服器上做一個 netstat，看看是否有一些來自正在更新的 php 程序和外部伺服器的連接。有些伺服器比其他伺服器慢。
- php-fpm 工作人員數量有限，我已經看到 WP 更新通過 HTTP 呼叫自己，因此它鎖定了所有可用的工作人員。
嘗試：
- php-fpm 的慢日誌
- fastcgi 上更高的 nginx 側超時
- strace 是 nutella 旁邊最好的東西。用它。