NUMA和SMP 架構差別以及對SWAP的影響

本文是轉帖,轉自: http://blog.chinaunix.net/uid-116213-id-3595888.html

必須得承認，即使看完了MySQL如何避免使用swap和MySQL如何避免使用swap（二），swap仍然可能頑固地在主機上複現。不過幸運的是，最近一年來衆多swap問題的受害者們通過不懈的努力找到了終極原因——NUMA。下面站在巨人的肩膀上，為大家簡單講解一下NUMA的原理和優化方法。

一、NUMA和SMP

NUMA和SMP是兩種CPU相關的硬體架構。在SMP架構裡面，所有的CPU争用一個總線來通路所有記憶體，優點是資源共享，而缺點是總線争用激烈。随着PC伺服器上的CPU數量變多（不僅僅是CPU核數），總線争用的弊端慢慢越來越明顯，于是Intel在Nehalem CPU上推出了NUMA架構，而AMD也推出了基于相同架構的Opteron CPU。

NUMA最大的特點是引入了node和distance的概念。對于CPU和記憶體這兩種最寶貴的硬體資源，NUMA用近乎嚴格的方式劃分了所屬的資源組（node），而每個資源組内的CPU和記憶體是幾乎相等。資源組的數量取決于實體CPU的個數（現有的PC server大多數有兩個實體CPU，每個CPU有4個核）；distance這個概念是用來定義各個node之間調用資源的開銷，為資源排程優化算法提供資料支援。

二、NUMA相關的政策

1、每個程序（或線程）都會從父程序繼承NUMA政策，并配置設定有一個優先node。如果NUMA政策允許的話，程序可以調用其他node上的資源。

2、NUMA的CPU配置設定政策有cpunodebind、physcpubind。cpunodebind規定程序運作在某幾個node之上，而physcpubind可以更加精細地規定運作在哪些核上。

3、NUMA的記憶體配置設定政策有localalloc、preferred、membind、interleave。localalloc規定程序從目前node上請求配置設定記憶體；而preferred比較寬松地指定了一個推薦的node來擷取記憶體，如果被推薦的node上沒有足夠記憶體，程序可以嘗試别的node。membind可以指定若幹個node，程序隻能從這些指定的node上請求配置設定記憶體。interleave規定程序從指定的若幹個node上以RR算法交織地請求配置設定記憶體。

三、NUMA和swap的關系

可能大家已經發現了，NUMA的記憶體配置設定政策對于程序（或線程）之間來說，并不是公平的。在現有的Redhat Linux中，localalloc是預設的NUMA記憶體配置設定政策，這個配置選項導緻資源獨占程式很容易将某個node的記憶體用盡。而當某個node的記憶體耗盡時，Linux又剛好将這個node配置設定給了某個需要消耗大量記憶體的程序（或線程），swap就妥妥地産生了。盡管此時還有很多page cache可以釋放，甚至還有很多的free記憶體。

四、解決swap問題

雖然NUMA的原理相對複雜，實際上解決swap卻很簡單：隻要在啟動MySQL之前使用numactl –interleave來修改NUMA政策即可。

值得注意的是，numactl這個指令不僅僅可以調整NUMA政策，也可以用來檢視目前各個node的資源是用情況，是一個很值得研究的指令。

引用資料：

The MySQL “swap insanity” problem and the effects of the NUMA architecture

NUMA Status: Item Definition

Linux Administrator’s Manual（#man numactl）