|
一直以來，有個產(chǎn)品，經(jīng)常性的連接不上，后通過lsof 發(fā)現(xiàn)有很多連接符，到數(shù)據(jù)庫中查看 mysql>show global status like '%open%file%'; 后把open_files_limit 改為10240，且通過ulimit -n 把系統(tǒng)的連接數(shù)也改成10240 | open_files_limit | 10240 | 但是修改后，Open_files 還是經(jīng)常性的持續(xù)增加，有時候都能達(dá)到10100左右，最后就是客戶端連接不上，用戶抱怨， 仔細(xì)分析：這個產(chǎn)品有好10個表用的是mysql 5.1 partition，分為50個分區(qū)，這樣在假設(shè)最低連接數(shù)為10，每個連接只打開一個表 那么最低也需要10*3*10*2（MYD+MYI）=6000個文件描述符，這樣隨著連接的增加，連接符越來越多，如果超過系統(tǒng)設(shè)定的連接數(shù)，那么最終就會導(dǎo)致客戶端連接不上的效果。 后想到mysql里，有兩個參數(shù)是與文件描述符有關(guān)系，一個是上面設(shè)置的open_files_limit，另一個就是我要說的table_open_cache； 文檔上說，增加table_open_cache，會增加文件描述符，當(dāng)把table_open_cache設(shè)置為很大時，如果系統(tǒng)處理不了那么多文件描述符，那么就會出現(xiàn)客戶端失效，連接不上，引用文檔上的一句話： If table_open_cache is set too high, MySQL may run out of file descriptors and refuse connections, fail to perform queries, and be very unreliable. 如果我們把table_open_cache設(shè)置小一點，那么mysql會隨著table cache的不足，而關(guān)閉不用或者少用的表的cache，這樣會釋放文件描述符，最終，總的連接數(shù)就降下來了，就不會出現(xiàn)lsof 看到N多連接的情況了。 開始時，table_open_cache設(shè)置為2048，后把他直接改為默認(rèn)64，終于解決這個讓同事不爽問題了！（^-^設(shè)置這么小，有點過于激進(jìn)了） |
|
|
