有臺服務器，訪問量挺大，每天近250w動態(tài)pv，數(shù)據(jù)庫查詢平均每秒近600次
另一臺服務器，跑的程序跟這臺一樣，不過只有每天約40w動態(tài)pv
前段時間連續(xù)卡死過幾次，當時的狀態(tài)是
服務器沒崩潰，數(shù)據(jù)庫可正常登陸。只是所有的查詢都卡在“sending data”狀態(tài)，長時間無法執(zhí)行完，這些簡單的sql語句，有時候集中在A表上，有時候集中在B表上，同時還有一些卡死在locked狀態(tài)或update狀態(tài)

看mysql的說明，sending data狀態(tài)表示兩種情況，一種是mysql已經(jīng)查詢了數(shù)據(jù)，正在發(fā)給客戶端；另一種情況是，mysql已經(jīng)知道某些數(shù)據(jù)需要去什么地方讀取，正在從數(shù)據(jù)文件中讀取

mysql官方說，這不是mysql的bug，但是官方也沒說怎么處理......那么，看情況，就應該是配置方面的問題了。
首先從sql優(yōu)化的角度來查了查，那些卡死的sql語句，都是簡單查詢，消耗非常低，索引做的非常好，所以覺得應該不是sql語句的問題。而且慢查詢日志里也沒有出現(xiàn)慢查詢。

把表都做了優(yōu)化，就是optimize table ，過幾天發(fā)現(xiàn)，還是會出現(xiàn)卡死的情況.....

后來考慮增加并發(fā)性能，增加了key_buffer thread_cache 等一系列的內存配置，發(fā)現(xiàn)沒什么作用。情況依舊

再后來，把query_cache減小到默認值 16M，把一些不怎么變動的數(shù)據(jù)，做了靜態(tài)化。驚奇的發(fā)現(xiàn)，12天過去了，沒再出過問題......

后來想想，修改query_cache可能對這個問題有些幫助，畢竟數(shù)據(jù)更新比較頻繁，query_cache的更新也很頻繁。不過看mysql的狀態(tài)，query_cache的命中率還是相當高的，差不多75％。

覺得問題可能出在程序上，只是沒查出來。后來靜態(tài)化的那些內容，是一些產(chǎn)品的說明文字，一般一個產(chǎn)品的說明也就三五十個漢字。

這里出問題的嫌疑比較大，一個頁面有七八個產(chǎn)品，加起來可能三五百個漢字，雖然不多，不過查詢很頻繁，從這個表上查詢的數(shù)據(jù)量應該是很可觀的，mysql會頻繁的從這個表拿數(shù)據(jù)。不過，不過有時候卡死的語句并不是在查詢這個表......

手頭沒有好使的工具，郁悶。反正問題貌似好了，先放下備案吧，等以后水平高些，再來查。

MySQL很容易進程滿而死的一個重要原因

建站不容易已經(jīng)遠遠超過了我的設想和預期,除了經(jīng)濟上還有技術上的,有些問題不是一般技術人員能解決。不過在這段時間里讓我也學會了如何思考問題和解決問題，特別是連續(xù)解決了幾個問題，可以說真不是開發(fā)人員或者別的技術人員能解決的，對此自信心也越來越足了!

　　談到這，必須說下我們的站布衣生活網(wǎng)www.yes81.net，基本配置，LINUX 9.0系統(tǒng),JBOSS42 WEB服務，MYSQL，從五一到現(xiàn)在，運行有段時間了，目前的訪問量是4000IP左右。

　　記得以前發(fā)生過一個問題也是檢查了好久都沒解決的，故障一發(fā)生CPU就跑到100%左右，系統(tǒng)沒響應，MYSQL、JBOSS進程死。當初是通過對一些大數(shù)據(jù)表建立索引解決的!這次問題現(xiàn)象和這個有點象，死的時候幾乎服務沒有響應，通過查看后臺MYSQL進程，居然已經(jīng)超過我設置的1000個限制，第1天我把配置改成3000，想想是否跟這個有關，最近的訪問量增大了。說實話，我還是不相信并發(fā)1000個連接，但事實擺在面前，現(xiàn)在就是1000個進程堵在這!第2天發(fā)現(xiàn)3000也不行了，在進程列表中看到基本上很容易就進程滿，而且每個進程都在sending data 狀態(tài)，查找了2天還是無法解決問題，不論是重新配置啟動參數(shù)還是檢查外來攻擊都無法解決，按照一些人的說法，把臨時緩沖表增大到512M也是沒有任何幫助。象這種的每增加個連接都幾乎會卡死，而且是sending data 狀態(tài)!是數(shù)據(jù)無法發(fā)出還是查詢不能完成呢?

　　帶著這個問題，跟開發(fā)的溝通，是否存在數(shù)據(jù)死鎖或者沒有提交的問題，造成的查詢鎖死!而且有時候是正常，但大部分是不正常的死鎖!查了半天，報告說，程序沒發(fā)現(xiàn)問題，因為根據(jù)命令已經(jīng)能定位到程序的準確代碼上了!那么是什么問題呢?

　　想起以前MS SQLSERVER2000下曾經(jīng)發(fā)生過的數(shù)據(jù)庫損壞的問題，也嘗試了修復。根據(jù)堵塞命令集中在幾個重要的表上，其一是餐館信息表(4萬條記錄)，用修復命令都無法修復!發(fā)現(xiàn)設置的類型是inoubox ,把類型改成MYISAM 后再修復，修復也沒報告什么錯誤，但重新啟動系統(tǒng)后一切問題就解決了!

最新評論