http://ourmysql.com/archives/310
數據庫運行一段時間后，經常導致服務器大量的swap,我懷疑是innodb中的臟數據太多了，因為沒有free space了，mysql通知OS，把一些臟頁交換出去，以上只是猜測。有一個現象是每次關數據庫時都要關很久,並且在關數據庫時，發現有大量的swap in。如果是數據庫進程異常關閉，打開數據庫又會花很長的時間來作恢復。我想提高一下mysql檢查點發生的頻率。看了Adaptive checkpointing,發現mysql檢查點事件受兩個因素的制約：一個是amount,另外一個是age.amount主要由innodb_max_dirty_pages_pct參數控制;至於age,主要是由日志文件大小有關。因為修改日志文件大小，要重啟數據庫，所以沒有做這個嘗試；於是嘗試修改innodb_max_dirty_pages_pct參數。
查看當前innodb_max_dirty_pages_pct參數的值：
mysql> show variables like ‘%pct%’;
+—————————-+——-+
| Variable_name | Value |
+—————————-+——-+
| innodb_max_dirty_pages_pct | 90 |
+—————————-+——-+
1 row in set (0.00 sec)
查看當前的檢查點位置（對於如何獲取此信息，花了比較多的時間,才找到此方法）
show innodb status\G;
LOG
—
Log sequence number 16 881655880
Log flushed up to 16 881649862
Last checkpoint at 16 546135914
我們可以看到檢查點與log sequence number,Log flushed up to都有相當大的差距。
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 19338953832; in additional pool allocated 13600768
Buffer pool size 1048576
Free buffers 17666
Database pages 1009478
Modified db pages 204553
修改的頁占到整個數據庫buffer pool頁將近20%,大小為204553*16k/1024=3.196G,有這么多的臟數據沒有寫到數據文件。如果此時關閉數據庫，必然要花很長的時間。如果數據庫服務器因為掉電或者mysqld進程異常中斷，那么打開，恢復的時間也會很長。
在咨詢mysql界的朋友后，大家對innodb_max_dirty_pages_pct基本上也是采用默認值，不過，覺得這個方向是對的，就開始一步步調此參數。因為臟頁占整個pool的20%,所以直接將此參數從90調到20.反復執行命令show innodb status\G;發現檢查點仍然增長緩慢。過了一會兒，發現系統並無任何異常之處，繼續調低此參數到15,此時間發現臟頁Modified db pages減少下來，檢查點增長稍微快一點。最終綜合考慮緩存大小，把此參數設為5.
mysql> set global innodb_max_dirty_pages_pct=5;
Query OK, 0 rows affected (0.00 sec)
—
LOG
—
Log sequence number 16 1160564756
Log flushed up to 16 1160560077
Last checkpoint at 16 1037968260 –檢查點追上來了
———————-
BUFFER POOL AND MEMORY
———————-
Total memory allocated 19338952464; in additional pool allocated 15022080
Buffer pool size 1048576
Free buffers 5291
Database pages 1021765
Modified db pages 61626 –這個值從204553快速下降
情況如自己預計的那樣，臟頁迅速減少，檢查點追上來了。使用mysql的朋友，對於mysql服務器的交換，一直都采用直接關閉swap的做法。不知道使用此方法，即提高檢查點發生的頻率，減少臟頁數量，能否解決我們常見的mysql交換問題呢？讓我們試目以待吧。過一段時間，再把結果發上來。