? ? 準(zhǔn)備試用MySQL, 先用它來存放收集的一些性能數(shù)據(jù), 就找了一臺(tái)16GB的x86_64機(jī)器, 自已下載了源代碼進(jìn)行編譯. 編譯成功, 建庫也成功, 直接用Linux LVM下的邏輯卷做Innodb的數(shù)據(jù)文件, 以為準(zhǔn)備工作就做完了, 可以安心使用MySQL了. 在真實(shí)使用之前, 先跑跑自帶的sql-bench程序吧, 雖然看不懂sql-bench的結(jié)果, 但總算在MySQL中跑了一些SQL, 不料在這中間就出現(xiàn)MySQL掛起的情況.

? ? 事情源于發(fā)現(xiàn)轉(zhuǎn)給sql-bench程序的參數(shù)寫錯(cuò)了, 想測試一下innodb上的效果的, 要指定所有表的默認(rèn)建表選項(xiàng), 于是用Control + C中斷了正在運(yùn)行的程序, 用中斷的方式換了幾個(gè)參數(shù)后, 突然發(fā)現(xiàn)MySQL掛起了, 用"show status"命令查看MySQL的運(yùn)行情況時(shí), 發(fā)現(xiàn)大部份性能統(tǒng)計(jì)數(shù)值都不再變化. 以為是一時(shí)的情況, 沒想到今天集團(tuán)同事也遇到了同樣的問題, 于是去重試了一下, 兩個(gè)Control + C就讓MySQL掛起了. 掛起后MySQL不能讀寫磁盤上所有磁盤上的表, 不能創(chuàng)建Innodb表, Myisam表, 連內(nèi)存表也不能創(chuàng)建, 情況很嚴(yán)重.

? ? 內(nèi)存是足夠的, MySQL的進(jìn)程數(shù)也只有17個(gè), 系統(tǒng)資源肯定不是問題. 用strace看了一下, 出錯(cuò)后也沒有什么有用的出錯(cuò)信息.

write(3, "\16\0\0\0\4columns_priv\0", 18) = 18
read(3, 0x71c150, 16384)? ? = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
read(3, 0x71c150, 16384)? ? = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
read(3, 0x71c150, 16384)? ? = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---
read(3, 0x71c150, 16384)? ? = -1 EINTR (Interrupted system call)
--- SIGINT (Interrupt) @ 0 (0) ---

? ? 于是請了淘寶的MySQL高手過來診斷, 他發(fā)現(xiàn)我的MySQL是靜態(tài)編譯(據(jù)說這種編譯方式下性能更好)的, 就是在編譯時(shí)用了如下的選項(xiàng).

--with-mysqld-ldflags=-all-static
--with-client-ldflags=-all-static

? ? 估計(jì)是這個(gè)有問題, 靜態(tài)編譯和動(dòng)態(tài)編譯會(huì)使用不同的線程庫(具體情況不清楚), 很有可能是這個(gè)問題, 就去掉了這兩個(gè)選項(xiàng)重新編譯了一下. 然后繼續(xù)Control + C了幾十次, 都沒有能再重現(xiàn)掛起的情況.