mysql 卡死大部分線程長(zhǎng)時(shí)間處于sending data的狀態(tài)

2020-01-19 00:22:25

字體：大中小

供稿：網(wǎng)友

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

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

mysql官方說(shuō)，這不是mysql的bug，但是官方也沒(méi)說(shuō)怎么處理......那么，看情況，就應(yīng)該是配置方面的問(wèn)題了。
首先從sql優(yōu)化的角度來(lái)查了查，那些卡死的sql語(yǔ)句，都是簡(jiǎn)單查詢，消耗非常低，索引做的非常好，所以覺(jué)得應(yīng)該不是sql語(yǔ)句的問(wèn)題。而且慢查詢?nèi)罩纠镆矝](méi)有出現(xiàn)慢查詢。

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

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

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

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

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

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

手頭沒(méi)有好使的工具，郁悶。反正問(wèn)題貌似好了，先放下備案吧，等以后水平高些，再來(lái)查。

MySQL很容易進(jìn)程滿而死的一個(gè)重要原因

建站不容易已經(jīng)遠(yuǎn)遠(yuǎn)超過(guò)了我的設(shè)想和預(yù)期,除了經(jīng)濟(jì)上還有技術(shù)上的,有些問(wèn)題不是一般技術(shù)人員能解決。不過(guò)在這段時(shí)間里讓我也學(xué)會(huì)了如何思考問(wèn)題和解決問(wèn)題，特別是連續(xù)解決了幾個(gè)問(wèn)題，可以說(shuō)真不是開(kāi)發(fā)人員或者別的技術(shù)人員能解決的，對(duì)此自信心也越來(lái)越足了!

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

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

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

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