已經在一個非常奇怪的數據庫問題上卡了很久,slow log裡面全是一些非常基本的sql語句,主鍵查詢或者根據主鍵更新簡單字段,本來應該是毫秒級返回結果的sql,居然總是超時。innodb分明是行級鎖,本來這些單行操作是innodb的優勢項目,應該毫無壓力的,居然成為了瓶頸。
反復調整參數,並且請教了專家之後仍然沒有很好地解決,之前增加了
innodb_purge_threads = 32 # 5.6之後才支持大於1, 5.5上會自動變成1
讓每隔10秒的purge操作開獨立的進程有一定的改善,但是仍然還是有很多阻塞的情況和很多slow log。
今天在安裝一台新mysql的時候看到這樣一段錯誤消息
[Warning] option 'thread_concurrency': unsigned value 0 adjusted to 1
我非常驚訝,因為我一直以為thread_concurrency=0的意思是不設置thread_concurrency,即無限。如果thread_concurrency=1,那就意味著mysql始終只能有一個並發thread,這顯然會造成阻塞,嚴重影響性能。
把這個參數改成16(cpu總線程數)之後,這個阻塞的問題徹底解決了。在top裡經常能看到mysqlCPU占用率超過200%以上的瞬間,而原來mysql很少能超過200%。slow log裡面也不再出現那些簡單查詢的日志了。
查了一下相關信息,眾說紛纭,有很多人包括官方文檔說這個參數沒有意義,僅僅針對solaris才有效。
並且還說這個參數在5.6.1之後會被廢棄。
還有一些中文文章也認為這個參數沒有意義
注意,這個參數是針對Solaris系統的,如果使用Linux系統,也就不需要設置這個參數,除非你使用Solaris系統
至少經過我實踐,這個參數在linux下面是有效的。默認是10,我改成0並被系統強制變成1之後,造成了經常阻塞的問題。目前我設置的是16,等於CPU線程數。
我為什麼會蛋疼地以為把這個參數改成0會有效呢,大概是因為受了innodb_thread_concurrency的影響,innodb_thread_concurrency是可以並且推薦改成0的。
在我看來這個參數似乎除了坑人之外真的沒有什麼別的作用了,默認thread_concurrency=10就已經足夠可用了,確實不需要修改。早一點升級到5.6告別這個參數吧。