MySQL本天早上8点到明早8点_似乎找到 OSChina 早上 8 点钟容易宕机的原因
最近一段時間,OSChina 網(wǎng)站在早上 8 點出頭的時候很容易因為數(shù)據(jù)庫連接池爆滿而導(dǎo)致網(wǎng)站宕機。表現(xiàn)的情況是數(shù)據(jù)庫處理大量的查詢,堆積大量并發(fā)連接,導(dǎo)致無法再連接到數(shù)據(jù)庫,執(zhí)行一個簡單的查詢速度也非常慢,數(shù)據(jù)庫機器的 CPU 很高。
但事實上早上 8 點并非 OSC 網(wǎng)站的高峰期,高峰期的時候都不會掛,為什么偏偏在這么一個沒多少人訪問的時間點宕機呢?
找了很久沒發(fā)現(xiàn)系統(tǒng)在 8 點這個時間點有什么特殊的任務(wù)要做,對數(shù)據(jù)庫也做了一些調(diào)整,包括 “MySQL Can’t Create Thread: Errno 11” 的問題。
但是問題依舊。
再次挨個檢查系統(tǒng) crontab 中定義的作業(yè)。其中自動構(gòu)建 Lucene 索引的作業(yè)引起了注意。
*/5 8-22?* * * /data/oschina/build.sh lucene_build
系統(tǒng)每 5 分鐘執(zhí)行一次增量索引構(gòu)建,該構(gòu)建過程僅在一天早上8點到晚上10點鐘進行。
我記得當(dāng)初這么設(shè)置的原因是有一個索引的構(gòu)建容易出問題,為了避免出問題時沒人處理,因此設(shè)置了這個時間段,后來一直沒去調(diào)整。
再查看系統(tǒng)跑 lucene 的進程,我靠,那么那么那么多。。。。。
趕緊一個 killall java 殺掉所有的 lucene 索引構(gòu)建進程,沒幾秒鐘數(shù)據(jù)庫的連接就下來了,系統(tǒng)恢復(fù)正常訪問。
所以我現(xiàn)在有 80% 的把握能確定宕機問題就是因為這個索引構(gòu)建進程導(dǎo)致的。而且索引構(gòu)建本身不存在問題,問題出在時間點的設(shè)定上。試想白天高峰期時候 5 分鐘執(zhí)行一次從來沒出過任何問題。也就是說經(jīng)過了一個晚上(從晚上10點到早上8點這段時間)系統(tǒng)又有很多的數(shù)據(jù),導(dǎo)致8點鐘啟動增量索引構(gòu)建時一次性任務(wù)量很大,無法在下一個5分鐘到來之前結(jié)束,于是不斷啟動新的進程,于是不斷連接到數(shù)據(jù)庫,于是數(shù)據(jù)庫性能急劇下降,于是掛機。
好吧,It's my fault!
將 8-22 改為 * 后繼續(xù)觀察!
總結(jié)
以上是生活随笔為你收集整理的MySQL本天早上8点到明早8点_似乎找到 OSChina 早上 8 点钟容易宕机的原因的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: 依赖注入模式中,为什么用对象而不是用数组
- 下一篇: mysql 里面不等于符号_mysql