PHP 死鎖問題分析
程序員們面對PHP死鎖問題的時候可能會不重視，認為重啟一下就好，但是其實這樣是沒有解決問題的。以下是百分網(wǎng)小編精心為大家整理的PHP 死鎖問題分析，希望對大家有所幫助!更多內(nèi)容請關(guān)注應(yīng)屆畢業(yè)生網(wǎng)!
背景：對于死鎖的問題，人們往往想到出現(xiàn)一些關(guān)于訪問很緩慢，有白頁現(xiàn)象，要是測試環(huán)境(我就真實遇到測試環(huán)境有本文談及一樣的問題)你也就重啟一下PHP的php-fpm進程發(fā)現(xiàn)又好了，隔一段時間又出類似的問題，你會看下日志，你會發(fā)現(xiàn)有很多日志是“Max execution timeout of 60 seconds exceeded”，你會發(fā)現(xiàn)這可能是一些php的守護進程導(dǎo)致的，你為了解決測試環(huán)境的問題，于是覺得應(yīng)該把那個php-fpm的進程數(shù)開多點，可能會好一些，于是你開多了，一直沒有面對這個問題的原因，為什么呢，因為公司裝PHP的是運維裝的，你沒有辦法或時間去裝一個debug版本的php，你說這個問題讓運維的人來查，你覺得能查出來?So，這個問題一拖再拖，但就是沒解決，但是有一天你發(fā)現(xiàn)磁盤滿了，用du去看整體時發(fā)現(xiàn)滿了，但是如果一個個目錄去看發(fā)現(xiàn)并沒有占用多少，也萬萬沒有想到PHP的死鎖還會導(dǎo)致磁盤空間占用太多，上面這種情況我就真實遇到過，后來重新reboot操作系統(tǒng)，磁盤又回來了，所以，我認為是一篇好文章，所以轉(zhuǎn)了此文，也想說明對于PHP的擴展這方面代碼質(zhì)量把關(guān)需要嚴格，再就是PHP本身關(guān)于鎖這塊要弱化(除開cookie/session和cache鎖外，其它能不用就不用)，盡可能少用鎖，這是博主一點小看法，下面言歸正傳。
發(fā)現(xiàn)問題
近期發(fā)現(xiàn)線上很多機器的磁盤空間報警， 且日志文件已經(jīng)清理，但是磁盤空間沒有釋放。通過ps aux | grep php-cgi 發(fā)現(xiàn)， 很多進程的啟動時間在幾天到幾周甚至幾個月之前。我們線上的php-cgi都有最大執(zhí)行次數(shù)的。一般在1天內(nèi)都會重啟一次。初步結(jié)論，這些cgi進程有問題。
通過lsof -p [pid] 發(fā)現(xiàn)， 啟動時間很久的cgi進程中打開了一些日志文件句柄，并且沒有關(guān)閉。這些日志文件在文件系統(tǒng)中已經(jīng)刪除了。但是句柄沒關(guān)閉，導(dǎo)致磁盤空間沒有釋放。到此，磁盤空間異常的問題基本確定。是由于cgi沒有關(guān)閉文件句柄造成的。
進一步分析進程， strace -p [pid]， 發(fā)現(xiàn)所有異常的進程都阻塞與 fmutex 狀態(tài)。換句話所，異常的cgi進程死鎖了。進程死鎖導(dǎo)致打開的文件句柄沒有關(guān)閉，所以導(dǎo)致磁盤空間異常。
為什么cgi進程會死鎖呢?
什么是死鎖
學(xué)過操作系統(tǒng)的通同學(xué)，都了解多線程的概念。在多線程中訪問公共資源，需要對資源加鎖。訪問結(jié)束后，釋放鎖。如果沒有釋放鎖，那么下一個線程來獲取資源的時候就會永遠都無法獲取資源的鎖，于是這個線程死鎖了。那么CGI是多線程的公共資源訪問導(dǎo)致的死鎖嗎? 答案是NO。
1. CGI 是單線程進程，通過ps 就能看到。(進程狀態(tài) Sl的才是多線程進程)。
2. 即使是多線程的，死鎖發(fā)生在PHP的shutdown過程中調(diào)用glibc 中time 函數(shù)的位置，不是php模塊造成的。而glibc 中的time相關(guān)函數(shù)是線程安全的，不會產(chǎn)生死鎖。
那是什么導(dǎo)致的死鎖呢?
通過分析linux中死鎖產(chǎn)生的機制，發(fā)現(xiàn)除了多線程會產(chǎn)生死鎖外，信號處理函數(shù)同樣會產(chǎn)生死鎖。那么cgi是由于信號處理導(dǎo)致的死鎖嗎?在這之前介紹一個感念。
函數(shù)的可重入性與信號安全
函數(shù)可重入是指，無論第幾次進入該函數(shù)，函數(shù)都能正常執(zhí)行并返回結(jié)果。那么線程安全函數(shù)是可重入的嗎?答案是NO。 線程安全函數(shù)，在第一次訪問公共資源時，會獲取全局鎖。如果函數(shù)沒有執(zhí)行完成，鎖還沒釋放，此時進程被中斷。那么在中斷處理函數(shù)中，再次訪問該函數(shù)，就會產(chǎn)生死鎖。那么什么樣的函數(shù)才可以在中斷處理函數(shù)中訪問呢? 除了沒有使用全局鎖的函數(shù)，還有一些signal safe的系統(tǒng)調(diào)用可以使用。調(diào)用任何其他的非signal safe的函數(shù)都會產(chǎn)生不可預(yù)知的后果(比如 死鎖)。 詳見 man signal。在分析死鎖的原因前，我們先看看cgi執(zhí)行的流程，分析其中有沒有產(chǎn)生死鎖的可能。
PHP-CGI的執(zhí)行流程
Glibc中的時間函數(shù)使用到了全局鎖，保證函數(shù)的線程安全，但沒有保證信號安全(signal safe)。經(jīng)過之前的分析，我們初步懷疑死鎖是由于PHP-CGI進程接收到了一個信號，然后在signal handle中執(zhí)行了非signal safe的函數(shù)。主流程在中斷前，正在執(zhí)行g(shù)libc中的時間函數(shù)。在函數(shù)獲取的鎖沒釋放前，進入中斷流程。而中斷過程中又訪問了glibc中的時間函數(shù)。于是導(dǎo)致了死鎖。
PHP-CGI的執(zhí)行流程，如下圖所示：
進一步分析發(fā)現(xiàn)，所有死鎖的cgi進程的sapi_global中都記錄了一個錯誤信息
“Max execution timeout of 60 seconds exceeded”.
60s 是我們php-cgi中設(shè)置執(zhí)行超時。所以我們確認了，cig在執(zhí)行過程中的確產(chǎn)生了超時異常，然后由于longjmp進入了shutdown過程。在shutdown過程中訪問了glibc中的時間函數(shù)。導(dǎo)致了死鎖。
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); /pic/p>
sigemptyset(&sigset);
sigaddset(&sigset, SIGPROF);
……
}
通過gdb調(diào)試發(fā)現(xiàn)，所有PHP-CGI都阻塞在zend_request_shutdown中。zend_request_shutdown會調(diào)用用戶自定義的php腳本中實現(xiàn)的shutdown函數(shù)。如果CGI執(zhí)行超市，那么定時器會產(chǎn)生SIGPROF信號使執(zhí)行流程中斷。如果此時腳本剛好處于調(diào)用時間函數(shù)的狀態(tài)，且還沒有釋放鎖資源。然后執(zhí)行流程進入了 timeout 函數(shù)，繼續(xù)跳轉(zhuǎn)到zend_request_shutdown。此時如果自定義的shutdown函數(shù)中訪問了時間函數(shù)。就會產(chǎn)生死鎖。我們從代碼中找到了證據(jù)：
register_shutdown_function ('SimpleWebSvc:: shutdown’);
我們在php代碼中使用qalarm系統(tǒng)，qalarm系統(tǒng)會在cgi執(zhí)行結(jié)束(shutdown)的時候，注入一個鉤子函數(shù)，來分析cgi執(zhí)行是否正常，如果不正常，則發(fā)送報警信息。而剛好qalarm的報警處理函數(shù)中訪問了時間函數(shù)。于是就有一定的概率產(chǎn)生死鎖。
結(jié)論
通過上面的分析，我們找到了cgi死鎖產(chǎn)生的原因，是應(yīng)為在signal handler中使用了非signal safe的函數(shù)，導(dǎo)致了死鎖。
解決辦法
去掉或簡化qalarm注冊到shutdown中的鉤子函數(shù)。避免不安全的函數(shù)調(diào)用。
【PHP 死鎖問題分析】相關(guān)文章：
php中死鎖問題剖析11-24
PHP解決session死鎖的解決方法01-26
Java程序死鎖問題原理及解決方案03-14
PHP遞歸效率分析03-09
PHP與ASP的分析對比02-27
PHP開發(fā)的安全問題02-18
PHP 多維數(shù)組的排序問題12-06
PHP版本5.2.17 5.3.27 5.3.28 5.4 5.5的兼容性問題分析03-10
解析php中的foreach問題02-17