分析PHP的死結問題

標籤：小夥伴   空間   技術   清理   

對於死結的問題，人們往往想到出現一些關於訪問很緩慢，有白頁現象，要是測試環境你也就重啟一下PHP的php-fpm進程發現又好了，隔一段時間又出類似的問題，本期我們邀請到了 兄弟連PHP教育www.lampbrother.net的PHP大牛為大家分享，一個隱蔽已久的PHP死結問題被層層掘出，感謝鐵成為我們帶來這次暢快的體驗，小夥伴們，準備好這次技術之旅了嗎？

 

---------------

 

發現問題

近期發現線上很多機器的磁碟空間警示， 且記錄檔已經清理，但是磁碟空間沒有釋放。通過ps aux | grep php-cgi 發現， 很多進程的啟動時間在幾天到幾周甚至幾個月之前。我們線上的php-cgi都有最大執行次數的。一般在1天內都會重啟一次。初步結論，這些cgi進程有問題。

 

通過lsof -p [pid] 發現， 啟動時間很久的cgi進程中開啟了一些記錄檔控制代碼，並且沒有關閉。這些記錄檔在檔案系統中已經刪除了。但是控制代碼沒關閉，導致磁碟空間沒有釋放。到此，磁碟空間異常的問題基本確定。是由於cgi沒有關閉檔案控制代碼造成的。

 

進一步分析進程， strace -p [pid]， 發現所有異常的進程都阻塞與 fmutex 狀態。換句話所，異常的cgi進程死結了。進程死結導致開啟的檔案控制代碼沒有關閉，所以導致磁碟空間異常。

 

為什麼cgi進程會死結呢？

什麼是死結

 

學過作業系統的通同學，都瞭解多線程的概念。在多線程中訪問公用資源，需要對資源加鎖。訪問結束後，釋放鎖。如果沒有釋放鎖，那麼下一個線程來擷取資源的時候就會永遠都無法擷取資源的鎖，於是這個線程死結了。那麼CGI是多線程的公用資源訪問導致的死結嗎？ 答案是NO。

 

1. CGI 是單線程進程，通過ps 就能看到。（進程狀態 Sl的才是多線程進程）。

 

2. 即使是多線程的，死結發生在PHP的shutdown過程中調用glibc 中time 函數的位置，不是php模組造成的。而glibc 中的time相關函數是安全執行緒的，不會產生死結。

 

那是什麼導致的死結呢？

通過分析linux中死結產生的機制，發現除了多線程會產生死結外，訊號處理函數同樣會產生死結。那麼cgi是由於訊號處理導致的死結嗎？在這之前介紹一個感念。

 

函數的可重新進入性與訊號安全

函數可重新進入是指，無論第幾次進入該函數，函數都能正常執行並返回結果。那麼安全執行緒函數是可重新進入的嗎？答案是NO。 安全執行緒函數，在第一次訪問公用資源時，會擷取全域鎖。如果函數沒有執行完成，鎖還沒釋放，此時進程被中斷。那麼在中斷處理函數中，再次訪問該函數，就會產生死結。那麼什麼樣的函數才可以在中斷處理函數中訪問呢？ 除了沒有使用全域鎖的函數，還有一些signal safe的系統調用可以使用。調用任何其他的非signal safe的函數都會產生不可預知的後果（比如 死結）。 詳見 man signal。在分析死結的原因前，我們先看看cgi執行的流程，分析其中有沒有產生死結的可能。

 

PHP-CGI的執行流程

Glibc中的時間函數使用到了全域鎖，保證函數的安全執行緒，但沒有保證訊號安全（signal safe）。經過之前的分析，我們初步懷疑死結是由於PHP-CGI進程接收到了一個訊號，然後在signal handle中執行了非signal safe的函數。主流程在中斷前，正在執行glibc中的時間函數。在函數擷取的鎖沒釋放前，進入中斷流程。而中斷過程中又訪問了glibc中的時間函數。於是導致了死結。

 

PHP-CGI的執行流程，如所示：

進一步分析發現，所有死結的cgi進程的sapi_global中都記錄了一個錯誤資訊

 

“Max execution timeout of 60 seconds exceeded”.

 

60s 是我們php-cgi中設定執行逾時。所以我們確認了，cig在執行過程中的確產生了逾時異常，然後由於longjmp進入了shutdown過程。在shutdown過程中訪問了glibc中的時間函數。導致了死結。

 

void zend_set_timeout(long seconds)

{

TSRMLS_FETCH();

EG(timeout_seconds) = seconds;

if(!seconds) {

return;

}

……

setitimer(ITIMER_PROF, &t_r, NULL);

signal(SIGPROF, zend_timeout); // 此處會調用zend異常處理函數

sigemptyset(&sigset);

sigaddset(&sigset, SIGPROF);

……

}

 

通過gdb調試發現，所有PHP-CGI都阻塞在zend_request_shutdown中。zend_request_shutdown會調用使用者自訂的php指令碼中實現的shutdown函數。如果CGI執行超市，那麼定時器會產生SIGPROF訊號使執行流程中斷。如果此時指令碼剛好處於調用時間函數的狀態，且還沒有釋放鎖資源。然後執行流程進入了 timeout 函數，繼續跳轉到zend_request_shutdown。此時如果自訂的shutdown函數中訪問了時間函數。就會產生死結。我們從代碼中找到了證據：

 

register_shutdown_function (‘SimpleWebSvc:: shutdown’);

 

我們在php代碼中使用qalarm系統，qalarm系統會在cgi執行結束（shutdown）的時候，注入一個鉤子函數，來分析cgi執行是否正常，如果不正常，則發送警示資訊。而剛好qalarm的警示處理函數中訪問了時間函數。於是就有一定的機率產生死結。

 

結論

通過上面的分析，我們找到了cgi死結產生的原因，是應為在signal handler中使用了非signal safe的函數，導致了死結。

 

解決辦法

去掉或簡化qalarm註冊到shutdown中的鉤子函數。避免不安全的函數調用。

分析PHP的死結問題