環境是單顆 E5405 的機器，上面的作業系統是 FreeBSD 7.1，應用程式的部份是 apache 2.2 (worker) + mod_fastcgi 2.4.6 + PHP 5.2.8 + APC 3.0.19。
由於前陣子發現 PHP 在 MP 架構下效能不太好，偶而會有一堆 php-cgi 卡住，用 top 會發現卡在 "lockf" 這個狀態，這時候前端的 L4 switch 會看到 500 Internal Server Error 而把這台機器暫時離線。等到 php-cgi 慢慢消化完，前端的 L4 switch 又會抓到 200。
在 php-cgi 卡住的狀況下試著用 gdb 找原因，當時 backtrace 發現是卡在 APC 裡的 lockf，所以就有一些想法，等有空閒的時候測試。
第一個想法是把 APC 的 lockf (fcntl) 改用 IPC semaphore，這個在 ports 可以調整。重新編完後發現 php-cgi 跑不起來，後來試出來，需要同時打開 mmap support 與 IPC semaphore。
第一張是 webfront-7，跑 mmap + semaphore。第二張是 webfront-8，保持原來的 shm + fcntl (lockf)：
效能有「好一點」，但很難觀察出來，實際再加上 webfront-{9,10} 比較後 (都是完全同型的伺服器)，看起來 webfront-7 的效能是最好的，所以得觀察當爆量時是否會卡 lockf。
Hmmm.. 看的到 "500 Internal Server Error", 應該到 L7 的 switch 了, 真羨慕有這樣的設備。
是 health check 的時候會抓到 500，而非使用者的連線...
APC 在流量大的时候，容易出现一个 http://pecl.php.net/bugs/bug.php?id=15313 的错误，我是在配合 PHP-FPM 的时候在FPM的日志里发现的。这种情况就会出现 500 错误。不知道你这里有否发现？
忘了说，APC 的作者之一推荐用 spinlock 方式。不过这个问题在最新的 CVS 版本依然没有解决。
Suggest to use xcache to replace APC in FreeBSD 7.1 SMP.
您好, 請問intel xeon e5405 cpu 是使用 7.2R AMD64的安裝片嗎？我用這片安裝，沒辦法進入安裝畫面，會不斷地重新開機，thanks
那就不是 cpu 的問題了...