linux內核機制常識

數據庫系統通常是企業的核心應用，因此針對運行 MySQL 的 Linux 系統通常需要進行一些特殊的優化。

本人非 MySQL 大牛，本文不涉及 MySQL 參數優化，僅對 Linux 系統優化進行一些總結。

CPU

現代操作系統都是多任務多用戶的操作系統，服務器能夠支持的CPU數量也越來越多，對于多CPU的服務器有多種架構，常見的是 NUMA 和 SMP.

SMP

SMP 即 Symmetric Multi-Processing，對稱多處理，這種架構中，每個處理器的地位都是平等的，對資源的使用權限相同，它們共享同一主存，由一個操作系統控制。

由于共享同一主存，隨著 CPU 增多，對內存的資源的爭用也會增多，造成 CPU 資源的浪費，因此CPU增多，系統并不能線性提升。實驗表明 SMP 服務器CPU 個數為2-4個時 CPU 的利用率最佳。

NUMA

NUMA, Non-Uniform Memory Access，非一致性內存訪問，這種架構下，每個 CPU 都有自己的專用內存和內存控制器（可能就在 CPU 內部），這樣一來 CPU 對內存的爭用情況將減少。

每個 CPU 都有自己的運行隊列，內核會平衡各個內存的運行隊列(rebalancing)，當0號CPU的運行進程被調度至1號 CPU 的運行隊列中，由于進程需要原來的數據，那么1號 CPU 就有可能需要訪問0號 CPU 的專用內存（請求0號CPU的內存控制器），此時需要跨越 CPU 插槽，需要多個 CPU 時鐘周期。

在 NUMA 結構下，應該盡可能的保證 CPU 至訪問自身的內存，常用的方法是進程綁定（CPU affinity）。

兩種架構的圖示：

NUMA 架構不適合用于運行數據庫服務，由于每個 CPU 使用自身的內存，因此可能出現一個 CPU 的內存使用完，而另一個 CPU 的內存有大量剩余，造成內存資源的浪費，甚至可能出現內存有較多剩余，系統卻一直使用 swap 空間的情況（具體可參見 MySQL “swap insanity”）。

NUMA 架構的內存分配方式可以設置，但最簡單的方式是關閉 NUMA 特性。

可以使用 numastat 或 numastat -p <PID> 查看 NUMA 結構 CPU 內存訪問狀態

關閉 NUMA

1. 從 BIOS 關閉

2. 在操作系統中關閉，在 /etc/grub/grub.conf 的 kernel 行追加 numa=off

3. 修改 /etc/init.d/mysql 或者 mysqld_safe 腳本，這種方式較復雜，不便于管理，不推薦

4. 啟動 MySQL 的時候，關閉 NUMA 特性，使用 numactl --interleave=all mysqld &

最好的方法還是 1 和 2

Memory

vm.swappiness

vm.swappiness 是操作系統使用交換分區的策略，它的值從 0 至 100，系統默認值為 60. 值為 0 表示盡量少使用 swap，100 表示盡量將 inactive 的內存頁交換出去。當系統內存使用到一定量時，系統就根據這個參數判斷是否使用交換分區。

由于使用 swap 會導致數據庫性能急劇下降，有人建議不使用 swap，這樣是比較危險的，因為當系統出現 OOM(Out Of Memory) 時，系統會啟動OOM-killer，有可能殺死 MySQL 進程，造成業務中斷，甚至丟失數據。

我建議設置較小的 swap 分區，并設置 vm.swappiness=0，不要忘了寫進 /etc/sysctl.conf 永久生效，swap 分區不宜太大是因為如果 vm.swappiness 設置不當可能造成大量的內存交換。

注意：在較新的內核中(2.6.32-303.el6及以后) 對 vm.swappiness 設置為 0 時的系統使用交換分區策略進行了調整，系統永遠不會使用交換分區，這意味著如果出現內存耗盡，系統將啟動 OOM-killer 殺死消耗內存的進程。因此 可以設置vm.swappiness=1.

再次注意： Kernel 2.6.28 之前的版本中（如 CentOS 5），有 Bug，不管設置 vm.swappiness 設置為多大，由于內存管理算法的問題，Linux 都有可能會將 MySQL 內存交換至交換分區，如果你經常遇到這種情況，修復的方法是升級你的 kernel，或者考慮使用這個腳本 A perl script you can run from cron.

I/O

IO scheduler

針對機械磁盤的特性，Linux 引入了多種 IO 調度器來優化 IO 性能，簡單來說優化磁盤讀寫的策略就是將 IO 請求合并與重排。合并操作是將相鄰扇區的 IO 請求合并為一個，重排是將 IO 請求按扇區邏輯地址順序排列。

Linux2.4 只有一種 IO 調度器，2.6后引入了多種 IO 調度器，這里不多介紹，具體可以參考我的另一片文章——Linux 性能優化之 IO 子系統

Linux 默認使用 IO 調度算法是 CFQ，該算法可能會出現 IO 請求餓死的情況。

下圖為 Choosing an I/O Scheduler for Red Hat Enterprise Linux 4 and the 2.6 Kernel 中的測試結果

從很多實際測試場景來看，Deadline 更適合跑 MySQL 數據庫。

修改 IO 調度算法為 Deadline

echo deadline > /sys/block/sda/queue/scheduler

這里需要注意，通常的調度算法的行為都是合并請求，排序請求，這些行為是針對機械磁盤的特性來優化的，對于使用 SSD 硬盤的系統，由于沒有了磁頭尋道，磁片旋轉定位等操作，對 SSD 硬盤使用通常的調度算法就變得沒有意義，因此我們使用一種特殊的調度算法 NOOP(NO OPeration)，即不對 IO 請求進行操作，直接按 FIFO 規則進行處理。

設置調度算法為 NOOP.

echo noop > /sys/block/sda/queue/scheduler

Filesystem

現代操作系統都使用日志型文件系統，Linux 中一般使用 ext4 或者 xfs，兩者的具體性能比較我不太清楚，據說 XFS 更適合大文件 IO.

文件系統的掛載參數，建議使用 noatime，nobarrier 兩個選項。

noatime

默認情況下，文件每次被讀取或修改（修改也需要先讀取），系統將更新atime并寫入至文件元數據中。

使用 noatime 掛載文件系統，訪問文件時將不對文件的 atime 進行更新，此時 atime 就相當于 mtime。磁盤性能可以得到 0-10% 的提升。

大多數時候關閉文件的 atime 也只能獲得較小的性能提升（這個說法引用于 IMB Redbook），但是也聊勝于無，在 /etc/fstab 這樣掛載

/dev/sdb /mountlocation ext4 default, noatime 0 0

nobarrier

barrier 是保證日志型文件系統的 WAL(Write Ahead Logging) 的一種手段，數據寫入磁盤時，理應先寫入 journal 區，再寫入數據在磁盤的實際對應位置，磁盤廠商為了加快磁盤寫入速度，磁盤都會內置 cache，數據一般都先寫入磁盤的 cache.

cache 能加快磁盤寫入速度，但磁盤一般會對 cache 內緩存數據排序使之按最優的數序刷寫到磁盤，這樣就可能導致要刷寫的數據和實際 journal 記錄順序錯亂。一旦系統崩潰，下次開機時磁盤要參考 journal 區來恢復數據，但此時 journal 記錄順序與數據實際刷寫順序不同，就會導致數據反而「恢復」到不一致狀態了。而 barrier 如其名 —— 柵欄，先加一個「柵欄」，保證 journal 總是先寫入記錄，然后對應數據才刷寫到磁盤，這種方式保證了系統崩潰后磁盤恢復的正確性，但對寫入性能有影響。

數據庫服務器底層存儲設備要么采用 RAID 卡，RAID 卡本身的電池可以掉電保護；要么采用 Flash 卡，它也有自我保護機制，保證數據不會丟失。所以我們可以安全的使用 nobarrier 掛載文件系統。設置方法如下：

對于 ext3，ext4 和 reiserfs 文件系統可以在 mount 時指定 barrier=0；對于xfs可以指定 nobarrier 選項。

總結

• CPU 方面，禁用 NUMA

• 內存方面，設置 vm.swappiness=0

• IO 方面，使用 deadline 或者 noop 調度策略，使用 noatime，nobarrier 掛載文件系統

</br> 深入了解 MySQL 在操作系統方面的調優，可以閱讀這個 PDF —— Linux and H/W optimizations for MySQL

還有一些能對 MySQL 運行情況進行一些簡單判斷和分析的腳本，可以閱讀這個了解 —— MySQL Performance Tuning Scripts and Know-How

</br>