---------------
發現問題
近期發現線上很多機器的磁盤空間報警, 且日志文件已經清理,但是磁盤空間沒有釋放。通過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技術文章
- PHP中session和cookie的區別
- php設計模式(一):簡介及創建型模式
- php設計模式結構型模式
- Php設計模式(三):行為型模式
- 十款最出色的 PHP 安全開發庫中文詳細介紹
- 12個提問頻率最高的PHP面試題
- PHP 語言需要避免的 10 大誤區
- PHP 死鎖問題分析
- 致PHP路上的“年輕人”
- PHP網站常見安全漏洞,及相應防范措施總結
- 各開源框架使用與設計總結(一)
- 數據庫的本質、概念及其應用實踐(二)
- PHP導出MySQL數據到Excel文件(fputcsv)
- PHP中14種排序算法評測
- 深入理解PHP原理之--echo的實現
- PHP性能分析相關的函數
- PHP 性能分析10則
- 10 位頂級 PHP 大師的開發原則
- 30條爆笑的程序員梗 PHP是最好的語言
- PHP底層的運行機制與原理
- PHP 性能分析與實驗——性能的宏觀分析
- PHP7 性能翻倍關鍵大揭露
- 鳥哥:寫在PHP7發布之際一些話
- PHP與MySQL通訊那點事
- Php session內部執行流程的再次剖析
- 關于 PHP 中的 Class 的幾點個人看法
- PHP Socket 編程過程詳解
- PHP過往及現在及變革
- PHP吉祥物大象的由來
- PHP生成靜態頁面的方法
- 吊炸天的 PHP 7 ,你值得擁有!
- PHP開發中文件操作疑難問答
- MongoDB PHP Driver的連接處理解析
- PHP 雜談《重構-改善既有代碼的設計》之二 對象
- 在php中判斷一個請求是ajax請求還是普通請求的方法
- 使用HAProxy、PHP、Redis和MySQL支撐10億請求每周架構細節
- HTML、HTML5、XHTML、CSS、SQL、JavaScript、PHP、Web Services 是什么?
- 重構-改善既有代碼的設計
- PHP場景中getshell防御思路分享
- 移動互聯時代,你看看除了PHP你還會些什么
- 安卓系統上搭建本地php服務器環境
- PHP中常見的緩存技術!
- PHP里10個鮮為人知但卻非常有用的函數
- 成為一名PHP專家其實并不難
- PHP 命令行?是的,您可以!
- PHP開發提高效率技巧
- PHP八大安全函數解析
- PHP實現四種基本排序算法
- PHP開發中的中文編碼問題
- php.get.post
- php發送get、post請求的6種方法簡明總結
- 中高級PHP開發者應該掌握哪些技術?
- 前端開發
- web前端知識體系大全
- 前端工程與性能優化(下)
- 前端工程與性能優化(上)
- 2016 年技術發展方向
- Web應用檢查清單
- 如何成為一名優秀的web前端工程師
- 前端組件化開發實踐
- 移動端H5頁面高清多屏適配方案
- 2015前端框架何去何從
- 從前端看“百度遷徙”的技術實現(一)
- 從前端看“百度遷徙”的技術實現(二)
- 前端路上的旅行
- 大公司里怎樣開發和部署前端代碼?
- 5個經典的前端面試問題
- 前端工程師新手必讀
- 手機淘寶前端的圖片相關工作流程梳理
- 一個自動化的前端項目實現(附源碼)
- 前端代碼異常日志收集與監控
- 15年雙11手淘前端技術總結 - H5性能最佳實踐
- 深入理解javascript原型和閉包系列
- 一切都是對象
- 函數和對象的關系
- prototype原型
- 隱式原型
- instanceof
- 繼承
- 原型的靈活性
- 簡述【執行上下文】上
- 簡述【執行上下文】下
- this
- 執行上下文棧
- 簡介【作用域】
- 【作用域】和【上下文環境】
- 從【自由變量】到【作用域鏈】
- 閉包
- 完結
- 補充:上下文環境和作用域的關系
- Linux私房菜