對付 MySQL 的死鏈接，Sleep的進程的來源探究[轉]

對付 MySQL 的死鏈接，Sleep的進程的來源探究[轉]

當前的鏈接數:
mysql > show status like '%Threads_connected%';
+-------------------+-------+
| Variable_name | Value |
+-------------------+-------+
| Threads_connected | 27 |
+-------------------+-------+
1 row in set (0.00 sec)

最大鏈接數：
show variables like '%max_connections%';
set GLOBAL max_connections=800;
flush privileges
也能夠修改/etc/my.cnf中的max_connections：
max_connections = 1000

關於php應該在什麼時候調用mysql _close()以及pconnect方式 和傳統方式有何種區別收藏
之前我一直認爲，當php的頁面執行結束時，會自動釋放掉一切。相信不少人都跟我想的同樣。但事實證實並非這樣。好比session就不會隨着頁面執行完畢而釋放。
php的垃圾回收機制，其實只針對於php自己。對於mysql ，php沒權利去自動去釋放它的東西。若是你在頁面執行完畢前不調用mysql _close()，那麼mysql 那邊是不會關閉這個鏈接的。若是你是用的是pconnect方式，即便你在頁面執行完畢前調用mysql _close()，也沒法另mysql 關閉這個鏈接。
也許在負載低的狀況下，你感覺不到有何不妥。可是，一旦負載很高，就回出現不少的死連接 ，因而得殺掉它們，現象:
在php中使用pconnect方式創建鏈接，而後到mysql 客戶端下執行show processlist；若是你的負載到必定程度的話，你能夠看到不少sleep的進程，這些進程就是人們常說的死鏈接，它們會一直保持sleep，直到my.cnf裏面設置的wait_timeout這個參數值的時間到了，mysql 纔會本身 殺死它。在殺死它的時候，mysql 還會在error-log裏面記錄一條Aborted connection xxx to db: 'xxx' user: 'xxx' host: 'xxx'的日誌，用google 翻譯一下，會獲得一個至關強悍的解釋"胎死腹中的鏈接"!
那麼形成sleep的緣由，有三個，下面是mysql 手冊給出的解釋:
1.客戶端程序在退出以前沒有調用mysql _close().[寫程序的疏忽，或者數據庫 的db類庫沒有自動關閉每次的鏈接。。。]
2.客戶端sleep的時間在wait_timeout或interactive_timeout規定的秒內沒有發出仁何請求到服務器. [相似常連，相似於不完整的tcp ip協議構造，服務端一直認爲客戶端仍然存在（有可能客戶端已經斷掉了）]
3.客戶端程序在結束以前向服務器發送了請求還沒獲得返回結果就結束掉了. [參看：tcp ip協議的三次握手]




網上有一個哥們寫了一個，以下：




將它當中的 $password 改爲你實際的數據庫 密碼，死鏈接的時間也能夠修改。而後加入計劃 仁務就能夠了。好比用 crontab -e 命令加入：

*/2 * * * * php /usr/local/sbin/kill-mysql -sleep-proc.php就能夠每隔 2 分鐘檢捕孝清除一次數據庫 中的死鏈接了。
 

閱讀全文>>