在os層numa關閉時,打開bios層的numa會影響性能，QPS會降低15-30%;java
在bios層面numa關閉時，不管os層面的numa是否打開，都不會影響性能。 node
安裝numactl:
#yum install numactl -y
#numastat 等同於 cat /sys/devices/system/node/node0/numastat ，在/sys/devices/system/node/文件夾中記錄系統中的全部內存節點的相關詳細信息。 #numactl --hardware 列舉系統上的NUMA節點python
#numactl --show 查看綁定信息mysql
Redhat或者Centos系統中能夠經過命令判斷bios層是否開啓numa
# grep -i numa /var/log/dmesg
若是輸出結果爲： No NUMA configuration found
說明numa爲disable，若是不是上面內容說明numa爲enable,例如顯示：NUMA: Using 30 for the hash shift.
能夠經過lscpu命令查看機器的NUMA拓撲結構。linux
當發現numa_miss數值比較高時，說明須要對分配策略進行調整。例如將指定進程關聯綁定到指定的CPU上，從而提升內存命中率。ios
---------------------------------------------算法
如今的機器上都是有多個CPU和多個內存塊的。之前咱們都是將內存塊當作是一大塊內存，全部CPU到這個共享內存的訪問消息是同樣的。這就是以前廣泛使用的SMP模型。可是隨着處理器的增長，共享內存可能會致使內存訪問衝突愈來愈厲害，且若是內存訪問達到瓶頸的時候，性能就不能隨之增長。NUMA（Non-Uniform Memory Access）就是這樣的環境下引入的一個模型。好比一臺機器是有2個處理器，有4個內存塊。咱們將1個處理器和兩個內存塊合起來，稱爲一個NUMA node，這樣這個機器就會有兩個NUMA node。在物理分佈上，NUMA node的處理器和內存塊的物理距離更小，所以訪問也更快。好比這臺機器會分左右兩個處理器（cpu1, cpu2），在每一個處理器兩邊放兩個內存塊(memory1.1, memory1.2, memory2.1,memory2.2)，這樣NUMA node1的cpu1訪問memory1.1和memory1.2就比訪問memory2.1和memory2.2更快。因此使用NUMA的模式若是能儘可能保證本node內的CPU只訪問本node內的內存塊，那這樣的效率就是最高的。sql
在運行程序的時候使用numactl -m和-physcpubind就能制定將這個程序運行在哪一個cpu和哪一個memory中。玩轉cpu-topology 給了一個表格，當程序只使用一個node資源和使用多個node資源的比較表（差很少是38s與28s的差距）。因此限定程序在numa node中運行是有實際意義的。mongodb
可是呢，話又說回來了，制定numa就必定好嗎？--numa的陷阱。SWAP的罪與罰文章就說到了一個numa的陷阱的問題。現象是當你的服務器還有內存的時候，發現它已經在開始使用swap了，甚至已經致使機器出現停滯的現象。這個就有多是因爲numa的限制，若是一個進程限制它只能使用本身的numa節點的內存，那麼當自身numa node內存使用光以後，就不會去使用其餘numa node的內存了，會開始使用swap，甚至更糟的狀況，機器沒有設置swap的時候，可能會直接死機！因此你可使用numactl --interleave=all來取消numa node的限制。
綜上所述得出的結論就是，根據具體業務決定NUMA的使用。
若是你的程序是會佔用大規模內存的，你大多應該選擇關閉numa node的限制（或從硬件關閉numa）。由於這個時候你的程序頗有概率會碰到numa陷阱。
另外，若是你的程序並不佔用大內存，而是要求更快的程序運行時間。你大多應該選擇限制只訪問本numa node的方法來進行處理。
---------------------------------------------------------------------
內核參數overcommit_memory ：
它是 內存分配策略
可選值：0、一、2。
0:表示內核將檢查是否有足夠的可用內存供應用進程使用；若是有足夠的可用內存，內存申請容許；不然，內存申請失敗，並把錯誤返回給應用進程。
1:表示內核容許分配全部的物理內存，而無論當前的內存狀態如何。
2:表示內核容許分配超過全部物理內存和交換空間總和的內存
內核參數zone_reclaim_mode：
可選值0、1
a、當某個節點可用內存不足時：
一、若是爲0的話，那麼系統會傾向於從其餘節點分配內存
二、若是爲1的話，那麼系統會傾向於從本地節點回收Cache內存多數時候
b、Cache對性能很重要，因此0是一個更好的選擇
----------------------------------------------------------------------
mongodb的NUMA問題
mongodb日誌顯示以下:
WARNING: You are running on a NUMA machine.
We suggest launching mongod like this to avoid performance problems:
numactl –interleave=all mongod [other options]
解決方案，臨時修改numa內存分配策略爲 interleave=all （在全部node節點進行交織分配的策略）：
1.在原啓動命令前面加numactl –interleave=all
如# numactl --interleave=all ${MONGODB_HOME}/bin/mongod --config conf/mongodb.conf
2.修改內核參數
echo 0 > /proc/sys/vm/zone_reclaim_mode ; echo "vm.zone_reclaim_mode = 0" >> /etc/sysctl.conf
----------------------------------------------------------------------
1、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之間調用資源的開銷，爲資源調度優化算法提供數據支持。
2、NUMA相關的策略
一、每一個進程（或線程）都會從父進程繼承NUMA策略，並分配有一個優先node。若是NUMA策略容許的話，進程能夠調用其餘node上的資源。
二、NUMA的CPU分配策略有cpunodebind、physcpubind。cpunodebind規定進程運行在某幾個node之上，而physcpubind能夠更加精細地規定運行在哪些核上。
三、NUMA的內存分配策略有localalloc、preferred、membind、interleave。
localalloc規定進程從當前node上請求分配內存；
而preferred比較寬鬆地指定了一個推薦的node來獲取內存，若是被推薦的node上沒有足夠內存，進程能夠嘗試別的node。
membind能夠指定若干個node，進程只能從這些指定的node上請求分配內存。
interleave規定進程從指定的若干個node上以RR（Round Robin 輪詢調度）算法交織地請求分配內存。
由於NUMA默認的內存分配策略是優先在進程所在CPU的本地內存中分配，會致使CPU節點之間內存分配不均衡，當某個CPU節點的內存不足時，會致使swap產生，而不是從遠程節點分配內存。這就是所謂的swap insanity 現象。
MySQL採用了線程模式，對於NUMA特性的支持並很差，若是單機只運行一個MySQL實例，咱們能夠選擇關閉NUMA，關閉的方法有三種：
1.硬件層，在BIOS中設置關閉
2.OS內核，啓動時設置numa=off；
3.能夠用numactl命令將內存分配策略修改成interleave（交叉)。
若是單機運行多個MySQL實例，咱們能夠將MySQL綁定在不一樣的CPU節點上，而且採用綁定的內存分配策略，強制在本節點內分配內存，這樣既能夠充分利用硬件的NUMA特性，又避免了單實例MySQL對多核CPU利用率不高的問題
3、NUMA和swap的關係
可能你們已經發現了，NUMA的內存分配策略對於進程（或線程）之間來講，並非公平的。在現有的Redhat Linux中，localalloc是默認的NUMA內存分配策略，這個配置選項致使資源獨佔程序很容易將某個node的內存用盡。而當某個node的內存耗盡時，Linux又恰好將這個node分配給了某個須要消耗大量內存的進程（或線程），swap就妥妥地產生了。儘管此時還有不少page cache能夠釋放，甚至還有不少的free內存。
4、解決swap問題
雖然NUMA的原理相對複雜，實際上解決swap卻很簡單：只要在啓動MySQL以前使用numactl –interleave來修改NUMA策略便可。
值得注意的是，numactl這個命令不只僅能夠調整NUMA策略，也能夠用來查看當前各個node的資源使用狀況，是一個很值得研究的命令。
1、CPU
首先從CPU提及。
你仔細檢查的話，有些服務器上會有的一個有趣的現象：你cat /proc/cpuinfo時，會發現CPU的頻率居然跟它標稱的頻率不同：
#cat /proc/cpuinfo
processor : 5
model name : Intel(R) Xeon(R) CPU E5-2620 0 @2.00GHz
cpu MHz : 1200.000
這個是Intel E5-2620的CPU，他是2.00G * 24的CPU，可是，咱們發現第5顆CPU的頻率爲1.2G。
這是什麼緣由呢?
這些其實都源於CPU最新的技術：節能模式。操做系統和CPU硬件配合，系統不繁忙的時候，爲了節約電能和下降溫度，它會將CPU降頻。這對環保人士和抵制地球變暖來講是一個福音，可是對MySQL來講，多是一個災難。
爲了保證MySQL可以充分利用CPU的資源，建議設置CPU爲最大性能模式。這個設置能夠在BIOS和操做系統中設置，固然，在BIOS中設置該選項更好，更完全。因爲各類BIOS類型的區別，設置爲CPU爲最大性能模式千差萬別，咱們這裏就不具體展現怎麼設置了。
而後咱們看看內存方面，咱們有哪些能夠優化的。
i) 咱們先看看numa
非一致存儲訪問結構 (NUMA ： Non-Uniform Memory Access) 也是最新的內存管理技術。它和對稱多處理器結構 (SMP ： Symmetric Multi-Processor) 是對應的。簡單的隊別以下：
如圖所示，詳細的NUMA信息咱們這裏不介紹了。可是咱們能夠直觀的看到：SMP訪問內存的都是代價都是同樣的;可是在NUMA架構下，本地內存的訪問和非 本地內存的訪問代價是不同的。對應的根據這個特性，操做系統上，咱們能夠設置進程的內存分配方式。目前支持的方式包括：
--interleave=nodes
--membind=nodes
--cpunodebind=nodes
--physcpubind=cpus
--localalloc
--preferred=node
簡而言之，就是說，你能夠指定內存在本地分配，在某幾個CPU節點分配或者輪詢分配。除非 是設置爲--interleave=nodes輪詢分配方式，即內存能夠在任意NUMA節點上分配這種方式之外。其餘的方式就算其餘NUMA節點上還有內 存剩餘，Linux也不會把剩餘的內存分配給這個進程，而是採用SWAP的方式來得到內存。有經驗的系統管理員或者DBA都知道SWAP致使的數據庫性能 降低有多麼坑爹。
因此最簡單的方法，仍是關閉掉這個特性。
關閉特性的方法，分別有：能夠從BIOS，操做系統，啓動進程時臨時關閉這個特性。
a) 因爲各類BIOS類型的區別，如何關閉NUMA千差萬別，咱們這裏就不具體展現怎麼設置了。
b) 在操做系統中關閉，能夠直接在/etc/grub.conf的kernel行最後添加numa=off，以下所示：
kernel /vmlinuz-2.6.32-220.el6.x86_64 ro root=/dev/mapper/VolGroup-root rd_NO_LUKS LANG=en_US.UTF-8 rd_LVM_LV=VolGroup/root rd_NO_MD quiet SYSFONT=latarcyrheb-sun16 rhgb crashkernel=auto rd_LVM_LV=VolGroup/swap rhgb crashkernel=auto quiet KEYBOARDTYPE=pc KEYTABLE=us rd_NO_DM numa=off
另外能夠設置 vm.zone_reclaim_mode=0儘可能回收內存。
c) 啓動MySQL的時候，關閉NUMA特性：
numactl --interleave=all mysqld
固然，最好的方式是在BIOS中關閉。
ii) 咱們再看看vm.swappiness。
vm.swappiness是操做系統控制物理內存交換出去的策略。它容許的值是一個百分比的值，最小爲0，最大運行100，該值默認爲60。vm.swappiness設置爲0表示儘可能少swap，100表示儘可能將inactive的內存頁交換出去。
具體的說：當內存基本用滿的時候，系統會根據這個參數來判斷是把內存中不多用到的inactive 內存交換出去，仍是釋放數據的cache。cache中緩存着從磁盤讀出來的數據，根據程序的局部性原理，這些數據有可能在接下來又要被讀 取;inactive 內存顧名思義，就是那些被應用程序映射着，可是 長時間 不用的內存。
咱們能夠利用vmstat看到inactive的內存的數量：
#vmstat -an 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
r b swpd free inact active si so bi bo in cs us sy id wa st
1 0 0 27522384 326928 1704644 0 0 0 153 11 10 0 0 100 0 0
0 0 0 27523300 326936 1704164 0 0 0 74 784 590 0 0 100 0 0
0 0 0 27523656 326936 1704692 0 0 8 8 439 1686 0 0 100 0 0
0 0 0 27524300 326916 1703412 0 0 4 52 198 262 0 0 100 0 0
經過/proc/meminfo 你能夠看到更詳細的信息：
#cat /proc/meminfo | grep -i inact
Inactive: 326972 kB
Inactive(anon): 248 kB
Inactive(file): 326724 kB
這裏咱們對不活躍inactive內存進一步深刻討論。 Linux中，內存可能處於三種狀態：free，active和inactive。衆所周知，Linux Kernel在內部維護了不少LRU列表用來管理內存，好比LRU_INACTIVE_ANON, LRU_ACTIVE_ANON, LRU_INACTIVE_FILE , LRU_ACTIVE_FILE, LRU_UNEVICTABLE。其中LRU_INACTIVE_ANON, LRU_ACTIVE_ANON用來管理匿名頁，LRU_INACTIVE_FILE , LRU_ACTIVE_FILE用來管理page caches頁緩存。系統內核會根據內存頁的訪問狀況，不定時的將活躍active內存被移到inactive列表中，這些inactive的內存能夠被 交換到swap中去。
通常來講，MySQL，特別是InnoDB管理內存緩存，它佔用的內存比較多，不常常訪問的內存也會很多，這些內存若是被Linux錯誤的交換出去了，將浪費不少CPU和IO資源。 InnoDB本身管理緩存，cache的文件數據來講佔用了內存，對InnoDB幾乎沒有任何好處。
因此，咱們在MySQL的服務器上最好設置vm.swappiness=1或0
