在使用PHP-FPM時，我們可能會遇到一個非常煩人的bug - PHP-FPM進程被意外殺掉導致網站崩潰。這個問題在生產環境中非常嚴重，因為我們可能會失去珍貴的訪問量和利潤。因此，本文將為大家介紹PHP-FPM殺掉的原因、解決方法以及如何避免這個問題。

造成PHP-FPM進程異常終止的原因有很多。通常情況下，這些原因可以歸為兩類：

第一類是被操作系統殺掉。操作系統有一個叫做OOM killer的東西，即內存管理器，當內存使用過量時，它就會自動殺掉一些進程以釋放內存。因此，如果PHP-FPM占用了過多的內存，就會被系統殺掉。

// 內存耗盡
pid 1023 (php-fpm), uid 0: exited on signal 9 (core dumped)

第二類情況是被Nginx殺掉。當PHP-FPM進程出現問題時，Nginx會給PHP-FPM發送一些信號來關閉它。信號可以是SIGTERM、SIGINT或SIGQUIT。當接收到這些信號時，PHP-FPM將進行清理工作并關閉。然而，如果這個清理工作占用了太長時間，那么Nginx也許會給PHP-FPM發送另一個信號SIGKILL，這會強制殺掉PHP-FPM進程，造成進程異常終止。

// php-fpm進程出現故障，被強制結束
[error] 31966#0: *191396 upstream prematurely closed connection while reading response header from upstream, client: 192.168.1.1, server: example.com, request: "GET /index.php HTTP/1.1", upstream: "fastcgi://127.0.0.1:9001", host: "example.com"

為避免PHP-FPM被Nginx關閉，我們需要做以下配置：

pm.max_requests = 1000 ; 每個進程可以處理的最大請求數，0代表無限制
pm.process_idle_timeout = 10s ; 進程閑置多久后被關閉，0代表禁用
request_terminate_timeout = 5m ; 每個請求的執行時間，到期后會自動關閉

如果這些配置不起作用，或者你想再次確認PHP-FPM的狀態，我們可以使用命令行工具檢查進程是否正在運行：

ps aux | grep php-fpm

如果PHP-FPM進程不在運行，則可以使用以下命令重新啟動它：

service php-fpm restart

總之，PHP-FPM進程異常終止是一個非常嚴重的問題，如果不及時處理，將對網站的正常運行帶來很大影響。通過我們的介紹，相信大家已經明白了PHP-FPM殺掉的原因和解決方法，希望本文能夠幫助大家排查并解決這個問題。