我們曾在 php handler 介紹過相關的php型態。

其中有提到 fastcgi的崩潰狀況，
使用fastcgi可能因此導致server loading問題。
最近有讀者來詢問，該如何處理這個狀況呢？

在本篇裡，我們另外給大家另一個思維：

首先要先觀察，這個loading問題是無時無刻發生，
還是透過壓力累積(間歇性)後才會發生的呢？

如果是間歇式的，建議在排程裡加上清除php的語法，或許就能解決:

1.登入linux shell，並執行 crontab -e。(我們是用centos為範本)

2. 在其中一行裡，擺上這個語法:
0 */1 * * * /usr/bin/pkill -f -x /usr/bin/php -P 1

3.排程的時間也可以自訂，讓server自動去進行 kill php 的動作。

如果是無時無刻的發生呢？

1.這樣透過排程，進行kill php 的效果可能不是最佳。

2.需改以top指令觀察，看看是cpu,memory還是(hd,io)，
哪一個部份去咬住了主機資源，在對症調整系統，程式，或升級硬體，
才會有效果。

(本篇教學由unethost.com客服撰寫)

延伸閱讀:如何備份Cpanel後台安裝的套裝程式?

安裝上述的軟體，我們提供虛擬主機試用，七天滿意保證，
功能完整使用不受限制，歡迎點我申請。

(*) example 1：
top – 01:49:59 up 49 min, 5 users, load average: 18.02, 32.55, 34.91
Tasks: 269 total, 1 running, 268 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.6%sy, 0.0%ni, 16.7%id, 82.2%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8028612k total, 2268460k used, 5760152k free, 88348k buffers
Swap: 4192924k total, 731688k used, 3461236k free, 309828k cached

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
8842 mysql 11 -10 1274m 178m 4076 S 0.0 2.3 0:46.40 mysqld

機器跑得很不順 ( 因為load已經上來了，居然有到18 )
發現 Cpu 82.2%wa —> I/O wait
—-> 因為io busy的process通常也是cpu busy，所以直接看第一行。
—-> 八成是第一行的process把cpu cycle 吃太多了
—-> 第一行就是 mysqld
喔，這個很正常，mysqld只要config不對，就容易有這種問題。
到mysql去找問題吧。
(*) example 2：
01:15:52 up 15 min, 4 users, load average: 28.37, 20.02, 10.44
Tasks: 762 total, 1 running, 760 sleeping, 0 stopped, 1 zombie
Cpu(s): 0.5%us, 1.8%sy, 0.0%ni, 0.0%id, 97.3%wa, 0.0%hi, 0.4%si, 0.0%st
Mem: 8028612k total, 7981536k used, 47076k free, 34512k buffers
Swap: 4192924k total, 2894460k used, 1298464k free, 272708k cached

機器跑得很不順 ( 因為load已經上來了，居然有到28 )
發現 Cpu 97.3%wa —> I/O wait
此外，還發現一件事： swap 被用掉了3G，mem幾乎被用光了
—-> 八成是有一隻process把ram吃光光了，是誰呢？
—-> 按shift +m
—-> 第一行就是吃最多ram的process

(*) example 3：
top – 01:27:59 up 31 days, 22:31, 3 users, load average: 2.36, 2.33, 4.96
Tasks: 697 total, 1 running, 692 sleeping, 0 stopped, 4 zombie
Cpu(s): 2.1%us, 1.2%sy, 0.0%ni, 50.9%id, 45.5%wa, 0.1%hi, 0.1%si, 0.0%st
Mem: 4023964k total, 3917884k used, 106080k free, 298548k buffers
Swap: 8385920k total, 504136k used, 7881784k free, 1557260k cached

機器的load沒有衝高，然而，io wait 還是不低 45.5% 。swap雖然有被用到了，但是還小於0.5G，小事啦…，mem也還剩不少 ( 不是ram的問題 )

雖然cpu busy的process 通常也是io busy，但是，目前這種情況無法直接確定
所以top的第一行，cpu用最多的process，就一定是io用最多的。

所以這種時候，會需要另一隻程式 iotop，直接殺向io bound的process，找出效能瓶頸。