☰

PHP-FPM 創建太多進程並佔用所有 CPU

tag-icon • tag-icon nginx amazon-ec2 php-fpm ubuntu-16.04
PHP-FPM 創建太多進程並佔用所有 CPU

這是一個迫切的問題。我的具有 4GB RAM 和 2vCPU 的 AWS 執行個體因過多的 php-fpm 進程而耗盡。

PHP-FPM 開始創建太多之前沒有創建的進程。這會導致網站載入緩慢。我無法弄清楚為什麼會發生這種情況。

我的 php.ini 配置：

html errors = off
precision = 14
output_buffering = 4096
serialize_precision = 17
max_execution_time = 300
max_input_time = 60
max_input_vars = 5000
log_errors_max_len = 1024
post_max_size = 27M 
upload_max_filesize = 27M 
max_file_uploads = 20
default_socket_timeout = 60
pdo_mysql.cache_size = 2000
memory_limit = 256M

www.conf：

pm = dynamic
pm.max_children = 35
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 1000

top指令截圖： 頂部命令輸出

答案1

回答你的問題

在 www.conf 中更改此（35 個進程）

pm.max_children = 35
pm.start_servers = 10
pm.min_spare_servers = 10
pm.max_spare_servers = 20
pm.max_requests = 1000

到這個（8個進程）-或者任何你喜歡的數字

pm.max_children = 8
pm.start_servers = 4
pm.min_spare_servers = 1
pm.max_spare_servers = 2
pm.max_requests = 1000

您可能還想糾正這個錯字

max_file_uploads = 20 = 20

回答評論裡的問題

作為背景，pm.max_children 是可用於服務請求的 PHP 執行緒數。如果沒有可用的線程，請求將排隊，直到 Web 伺服器逾時，直到有工作可用。

PHP 是非常記憶體密集的，並且相當CPU 密集型的。如果您有足夠的 RAM（例如）10 個 PHP 線程，但分配了 30 個，您的伺服器將發生交換，效能將會很糟糕。如果你過度分配CPU，它會變慢，但不會像RAM不足那麼糟。

一般來說，您應該計算在不耗盡伺服器 RAM 的情況下可以運行多少個 PHP 工作執行緒。假設您的伺服器使用 2GB RAM 並且關閉了 PHP，並且每個執行緒使用 100MB RAM，您可以擁有大約 20 個 PHP 工作執行緒。您應該盡量避免 RAM 飽和，因為它用作磁碟緩存，因此請保留一些空閒 RAM。

您需要在慢速 PHP 線程和排隊之間找到平衡。沒有人可以為您做到這一點，這將是一種實驗，直到您的伺服器充分利用但不會陷入困境。但是，首先，假設最多有 10 個線程，然後從那裡開始。使用“top”來監視可用內存，但對於內存，您可能需要使用“res”（我假設駐留在內存中）列而不是“virt”來估計 PHP RAM 使用情況。

操作快取

我懷疑（但不確定）啟用 opcache 的建議已經過時，因為 PHP7 已經進行了相當好的最佳化，並且可能預設為啟用。

快取

PHP 獲得良好效能的關鍵是快取。匿名用戶訪問未自訂的頁面通常可以被緩存，即使只有 1 / 5 / 60 秒，這對於高負載的伺服器來說也是一個很大的幫助。確保您的快取標頭正確描述了頁面過期時間，然後配置 Nginx / Apache 進行適當快取 - 如果您使用的是 Web 伺服器。

您也可以在 CDN 上快取靜態資源，例如 CloudFront / CloudFlare（請注意，CloudFlare 有免費套餐，並且與 AWS 配合良好）。不會說需要多少CPU或RAM，但會節省頻寬。每一點對負載較高的伺服器都有幫助。

答案2

我會檢查一下你的CPU是什麼類型的。如果您使用 Graviton CPU，它們在 CPU 與執行緒上的比例是 1 比 1。

IE。 CPU 計數是您應該擁有的 number pm.max_children。如果您擔心記憶體洩漏或其反覆出現的問題，您可以隨時使用該pm.max_requests功能並將其設定為適當的值。

該值在某種程度上取決於洩漏增長的速度。太小了，您可能會不時遇到不好的網關。

相關內容