最近php機器頻繁出現過載後再也無法提供服務的現象，只要一有請求發過去，負責處理該請求的php進程就是cpu佔用100%。本來的負載平衡策略是一旦某機器的php請求出現連線逾時就將該機器的權重降低，發向該機器的請求機率就會降低，雖然有一定滯後效應，但是最終應該能夠降壓並且最後恢複服務，但是這個策略在最近突然失效了。出現這個情況之後無法發送什麼請求到php-fpm都會cpu100%，即使請求的是一個空的php檔案。於是猜想可能是eaccelerator造成的。 我們的Php-fpm的request_terminate_timeout設定的是5s，於是只要是有請求執行超過5s就會被php-fpm將執行進程幹掉，在出問題的前後出現了大量的5s逾時，初步猜想可能是因為eaccelerator的共用記憶體造成的，子進程被幹掉時共用記憶體被寫錯了，導致所有請求過來都會出錯，但是這解釋不了新檔案也會被卡住的問題，於是去看eacceleraotr的代碼，發現如下代碼 [cpp] #define spinlock_try_lock(rw) asm volatile("lock ; decl %0" :"=m" ((rw)->lock) : : "memory") #define _spinlock_unlock(rw) asm volatile("lock ; incl %0" :"=m" ((rw)->lock) : : "memory") static int mm_do_lock(mm_mutex* lock, int kind) { while (1) { spinlock_try_lock(lock); if (lock->lock == 0) { lock->pid = getpid(); lock->locked = 1; return 1; } _spinlock_unlock(lock); sched_yield(); } return 1; } static int mm_do_unlock(mm_mutex* lock) { if (lock->locked && (lock->pid == getpid())) { lock->pid = 0; lock->locked = 0; _spinlock_unlock(lock); } return 1; } [cpp] 其中mm_mutex是指向共用記憶體的，也就是說eac用了共用記憶體來當作進程間的鎖，並且使用的spinlock方式，那這樣一來一切都能解釋的通了。設想如下一種情況，某個進程拿到鎖之後被php-fpm幹掉了，它沒有unlock，這樣一來所有的php-fpm子進程都拿不到鎖，於是大家就都在這個while(1)迴圈裡卡死了。猜想有了，怎麼去證實呢？原來的想法是直接去讀那片共用記憶體，結果發現php時IPC_PRIVATE的，所以沒辦法讀了。於是只能等到線上出問題後gdb上去看記憶體，今天終於有了確鑿的證據[html] (gdb) p *mm->lock $8 = {lock = 4294966693, pid = 21775, locked = 1} 這裡可以看到記憶體已經被進程號為21775的進程拿到了，但事實是，這個進程在很早以前就已經被幹掉了。問題得到證實了，那麼再回頭看一下這個問題發生的條件1、請求執行時間很長，長到會被php-fpm幹掉2、進程被幹掉時，php正在require檔案，並且eac拿到了鎖 從這裡可以看到，有一些特定情形會將這個機率放大1、request_terminate_timeout時間很短2、使用auoload方式，或者在執行邏輯裡require檔案，因為如果在請求開始前就將所有的檔案載入，那除非光require檔案就已經逾時，否則不應該會在require檔案時被幹掉。但是同樣的使用autload方式也有一個比較醜陋的辦法可以避過這個問題，那就是在autload函數裡判斷一下，如果執行時間過長了就直接exit而不是require 個人覺得，解決這個問題的最好辦法是request_terminate_timeout時間設定的足夠長，比如30s， 300s，而將逾時判斷全部放在應用程式層，不能通過php-fpm來處理這種問題，php-fpm事實只能用作最後一重保險，不得不使用的保險。另外php裡還有一個逾時設定max_execution_time，但是這個逾時在cgi模式下是cpu時間，所以作用不大
http://www.bkjia.com/PHPjc/477815.htmlwww.bkjia.comtruehttp://www.bkjia.com/PHPjc/477815.htmlTechArticle最近php機器頻繁出現過載後再也無法提供服務的現象，只要一有請求發過去，負責處理該請求的php進程就是cpu佔用100%。本來的負載平衡策略...
