同時在線訪問量繼續(xù)增大 對于1G內(nèi)存的服務(wù)器明顯感覺到吃力嚴(yán)重時甚至每天都會死機(jī) 或者時不時的服務(wù)器卡一下 這個問題曾經(jīng)困擾了我半個多月MySQL使用是很具伸縮性的算法,因此你通常能用很少的內(nèi)存運行或給MySQL更多的被存以得到更好的性能。 安裝好mysql后,配制文件應(yīng)該在/usr/local/mysql/share/mysql目錄中,配制文件有幾個,有my-huge.cnf my-medium.cnf my-large.cnf my-small.cnf,不同的流量的網(wǎng)站和不同配制的服務(wù)器環(huán)境,當(dāng)然需要有不同的配制文件了。 一般的情況下,my-medium.cnf這個配制文件就能滿足我們的大多需要;一般我們會把配置文件拷貝到/etc/my.cnf 只需要修改這個配置文件就可以了,使用mysqladmin variables extended-status –u root –p 可以看到目前的參數(shù),有3個配置參數(shù)是最重要的,即key_buffer_size,query_cache_size,table_cache。 key_buffer_size只對MyISAM表起作用, key_buffer_size指定索引緩沖區(qū)的大小,它決定索引處理的速度,尤其是索引讀的速度。一般我們設(shè)為16M,實際上稍微大一點的站點 這個數(shù)字是遠(yuǎn)遠(yuǎn)不夠的,通過檢查狀態(tài)值Key_read_requests和Key_reads,可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低,至少是1:100,1:1000更好(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%’獲得)。 或者如果你裝了phpmyadmin 可以通過服務(wù)器運行狀態(tài)看到,筆者推薦用phpmyadmin管理mysql,以下的狀態(tài)值都是本人通過phpmyadmin獲得的實例分析: 這個服務(wù)器已經(jīng)運行了20天 key_buffer_size – 128M key_read_requests – 650759289 key_reads - 79112 比例接近1:8000 健康狀況非常好 另外一個估計key_buffer_size的辦法 把你網(wǎng)站數(shù)據(jù)庫的每個表的索引所占空間大小加起來看看以此服務(wù)器為例:比較大的幾個表索引加起來大概125M 這個數(shù)字會隨著表變大而變大。 從4.0.1開始,MySQL提供了查詢緩沖機(jī)制。使用查詢緩沖,MySQL將SELECT語句和查詢結(jié)果存放在緩沖區(qū)中,今后對于同樣的SELECT語句(區(qū)分大小寫),將直接從緩沖區(qū)中讀取結(jié)果。根據(jù)MySQL用戶手冊,使用查詢緩沖最多可以達(dá)到238%的效率。 通過調(diào)節(jié)以下幾個參數(shù)可以知道query_cache_size設(shè)置得是否合理 Qcache inserts Qcache hits Qcache lowmem prunes Qcache free blocks Qcache total blocks Qcache_lowmem_prunes的值非常大,則表明經(jīng)常出現(xiàn)緩沖不夠的情況,同時Qcache_hits的值非常大,則表明查詢緩沖使用非常頻繁,此時需要增加緩沖大小Qcache_hits的值不大,則表明你的查詢重復(fù)率很低,這種情況下使用查詢緩沖反而會影響效率,那么可以考慮不用查詢緩沖。此外,在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。 Qcache_free_blocks,如果該值非常大,則表明緩沖區(qū)中碎片很多query_cache_type指定是否使用查詢緩沖 我設(shè)置: query_cache_size = 32M query_cache_type= 1 得到如下狀態(tài)值: Qcache queries in cache 12737 表明目前緩存的條數(shù) Qcache inserts 20649006 Qcache hits 79060095 看來重復(fù)查詢率還挺高的 Qcache lowmem prunes 617913 有這么多次出現(xiàn)緩存過低的情況 Qcache not cached 189896 Qcache free memory 18573912 目前剩余緩存空間 Qcache free blocks 5328 這個數(shù)字似乎有點大 碎片不少 Qcache total blocks 30953 如果內(nèi)存允許32M應(yīng)該要往上加點 table_cache指定表高速緩存的大小。每當(dāng)MySQL訪問一個表時,如果在表緩沖區(qū)中還有空間,該表就被打開并放入其中,這樣可以更快地訪問表內(nèi)容。通過檢查峰值時間的狀態(tài)值Open_tables和Opened_tables,可以決定是否需要增加table_cache的值。如果你發(fā)現(xiàn)open_tables等于table_cache,并且opened_tables在不斷增長,那么你就需要增加table_cache的值了(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables’獲得)。注意,不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高,可能會造成文件描述符不足,從而造成性能不穩(wěn)定或者連接失敗。 對于有1G內(nèi)存的機(jī)器,推薦值是128-256。 筆者設(shè)置table_cache = 256 得到以下狀態(tài): Open tables 256 Opened tables 9046 雖然open_tables已經(jīng)等于table_cache,但是相對于服務(wù)器運行時間來說,已經(jīng)運行了20天,opened_tables的值也非常低。因此,增加table_cache的值應(yīng)該用處不大。如果運行了6個小時就出現(xiàn)上述值 那就要考慮增大table_cache。 如果你不需要記錄2進(jìn)制log 就把這個功能關(guān)掉,注意關(guān)掉以后就不能恢復(fù)出問題前的數(shù)據(jù)了,需要您手動備份,二進(jìn)制日志包含所有更新數(shù)據(jù)的語句,其目的是在恢復(fù)數(shù)據(jù)庫時用它來把數(shù)據(jù)盡可能恢復(fù)到最后的狀態(tài)。另外,如果做同步復(fù)制( Replication )的話,也需要使用二進(jìn)制日志傳送修改情況。 log_bin指定日志文件,如果不提供文件名,MySQL將自己產(chǎn)生缺省文件名。MySQL會在文件名后面自動添加數(shù)字引,每次啟動服務(wù)時,都會重新生成一個新的二進(jìn)制文件。此外,使用log-bin-index可以指定索引文件;使用binlog-do-db可以指定記錄的數(shù)據(jù)庫;使用binlog-ignore-db可以指定不記錄的數(shù)據(jù)庫。注意的是:binlog-do-db和binlog-ignore-db一次只指定一個數(shù)據(jù)庫,指定多個數(shù)據(jù)庫需要多個語句。而且,MySQL會將所有的數(shù)據(jù)庫名稱改成小寫,在指定數(shù)據(jù)庫時必須全部使用小寫名字,否則不會起作用。 關(guān)掉這個功能只需要在他前面加上#號 #log-bin 開啟慢查詢?nèi)罩? slow query log ) 慢查詢?nèi)罩緦τ诟櫽袉栴}的查詢非常有用。它記錄所有查過long_query_time的查詢,如果需要,還可以記錄不使用索引的記錄。下面是一個慢查詢?nèi)罩镜睦樱? 開啟慢查詢?nèi)罩?,需要設(shè)置參數(shù)log_slow_queries、long_query_times、log-queries-not-using-indexes。 log_slow_queries指定日志文件,如果不提供文件名,MySQL將自己產(chǎn)生缺省文件名。long_query_times指定慢查詢的閾值,缺省是10秒。log-queries-not-using-indexes是4.1.0以后引入的參數(shù),它指示記錄不使用索引的查詢。筆者設(shè)置long_query_time=10 筆者設(shè)置: sort_buffer_size = 1M max_connections=120 wait_timeout =120 back_log=100 read_buffer_size = 1M thread_cache=32 interactive_timeout=120 thread_concurrency = 4 參數(shù)說明: back_log 要求MySQL能有的連接數(shù)量。當(dāng)主要MySQL線程在一個很短時間內(nèi)得到非常多的連接請求,這就起作用,然后主線程花些時間(盡管很短)檢查連接并且啟動一個新線程。back_log值指出在MySQL暫時停止回答新請求之前的短時間內(nèi)多少個請求可以被存在堆棧中。只有如果期望在一個短時間內(nèi)有很多連接,你需要增加它,換句話說,這值對到來的TCP/IP連接的偵聽隊列的大小。你的操作系統(tǒng)在這個隊列大小上有它自己的限制。 Unix listen(2)系統(tǒng)調(diào)用的手冊頁應(yīng)該有更多的細(xì)節(jié)。檢查你的OS文檔找出這個變量的最大值。試圖設(shè)定back_log高于你的操作系統(tǒng)的限制將是無效的。 max_connections 并發(fā)連接數(shù)目最大,120 超過這個值就會自動恢復(fù),出了問題能自動解決 thread_cache 沒找到具體說明,不過設(shè)置為32后 20天才創(chuàng)建了400多個線程 而以前一天就創(chuàng)建了上千個線程 所以還是有用的 thread_concurrency #設(shè)置為你的cpu數(shù)目x2,例如,只有一個cpu,那么thread_concurrency=2 #有2個cpu,那么thread_concurrency=4 skip-innodb #去掉innodb支持 代碼: # Example MySQL config file for medium systems. # # This is for a system with little memory (32M - 64M) where MySQL plays # an important part, or systems up to 128M where MySQL is used together with # other programs (such as a web server) # # You can copy this file to # /etc/my.cnf to set global options, # mysql-data-dir/my.cnf to set server-specific options (in this # installation this directory is /var/lib/mysql) or # ~/.my.cnf to set user-specific options. # # In this file, you can use all long options that a program supports. # If you want to know which options a program supports, run the program # with the "--help" option. 補(bǔ)充 優(yōu)化table_cachetable_cache指定表高速緩存的大小。每當(dāng)MySQL訪問一個表時,如果在表緩沖區(qū)中還有空間,該表就被打開并放入其中,這樣可以更快地訪問表內(nèi)容。通過檢查峰值時間的狀態(tài)值Open_tables和Opened_tables,可以決定是否需要增加table_cache的值。如果你發(fā)現(xiàn)open_tables等于table_cache,并且opened_tables在不斷增長,那么你就需要增加table_cache的值了(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘Open%tables’獲得)。注意,不能盲目地把table_cache設(shè)置成很大的值。如果設(shè)置得太高,可能會造成文件描述符不足,從而造成性能不穩(wěn)定或者連接失敗。對于有1G內(nèi)存的機(jī)器,推薦值是128-256。 案例1:該案例來自一個不是特別繁忙的服務(wù)器table_cache – 512open_tables – 103opened_tables – 1273uptime – 4021421 (measured in seconds)該案例中table_cache似乎設(shè)置得太高了。在峰值時間,打開表的數(shù)目比table_cache要少得多。 案例2:該案例來自一臺開發(fā)服務(wù)器。table_cache – 64open_tables – 64opened-tables – 431uptime – 1662790 (measured in seconds)雖然open_tables已經(jīng)等于table_cache,但是相對于服務(wù)器運行時間來說,opened_tables的值也非常低。因此,增加table_cache的值應(yīng)該用處不大。案例3:該案例來自一個upderperforming的服務(wù)器table_cache – 64open_tables – 64opened_tables – 22423uptime – 19538該案例中table_cache設(shè)置得太低了。雖然運行時間不到6小時,open_tables達(dá)到了最大值,opened_tables的值也非常高。這樣就需要增加table_cache的值。優(yōu)化key_buffer_sizekey_buffer_size指定索引緩沖區(qū)的大小,它決定索引處理的速度,尤其是索引讀的速度。通過檢查狀態(tài)值Key_read_requests和Key_reads,可以知道key_buffer_size設(shè)置是否合理。比例key_reads / key_read_requests應(yīng)該盡可能的低,至少是1:100,1:1000更好(上述狀態(tài)值可以使用SHOW STATUS LIKE ‘key_read%’獲得)。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表,但是內(nèi)部的臨時磁盤表是MyISAM表,也要使用該值??梢允褂脵z查狀態(tài)值created_tmp_disk_tables得知詳情。對于1G內(nèi)存的機(jī)器,如果不使用MyISAM表,推薦值是16M(8-64M)。 案例1:健康狀況key_buffer_size – 402649088 (384M)key_read_requests – 597579931key_reads - 56188案例2:警報狀態(tài)key_buffer_size – 16777216 (16M)key_read_requests – 597579931key_reads - 53832731案例1中比例低于1:10000,是健康的情況;案例2中比例達(dá)到1:11,警報已經(jīng)拉響。 |
|