作者：盧鈞軼(cenalulu) 本文原文地址：http://cenalulu.github.io/linux/numa/。
本文是最近在查找kvm相關優化資料查找到的，看過之后，似懂非懂，但多了一個linux 系統優化 思考的方向，很不錯。要學的東西越來越多了。最后，感謝大神的精彩分享。
另外分享一篇IBM技術文庫中的文章：https://www.ibm.com/developerworks/cn/linux/l-numa/
NUMA簡介
這部分將簡要介紹下NUMA架構的成因和具體原理，已經了解的讀者可以直接跳到第二節。
為什么要有NUMA
在NUMA架構出現前，CPU歡快的朝着頻率越來越高的方向發展。受到物理極限的挑戰，又轉為核數越來越多的方向發展。如果每個core的工作性質都是share-nothing（類似於map-reduce的node節點的作業屬性），那么也許就不會有NUMA。由於所有CPU Core都是通過共享一個北橋來讀取內存，隨着核數如何的發展，北橋在響應時間上的性能瓶頸越來越明顯。於是，聰明的硬件設計師們，先到了把內存控制器（原本北橋中讀取內存的部分）也做個拆分，平分到了每個die上。於是NUMA就出現了！
NUMA是什么
NUMA中，雖然內存直接attach在CPU上，但是由於內存被平均分配在了各個die上。只有當CPU訪問自身直接attach內存對應的物理地址時，才會有較短的響應時間（后稱Local Access）。而如果需要訪問其他CPU attach的內存的數據時，就需要通過inter-connect通道訪問，響應時間就相比之前變慢了（后稱Remote Access）。所以NUMA（Non-Uniform Memory Access）就此得名。
我們需要為NUMA做什么
假設你是Linux教父Linus，對於NUMA架構你會做哪些優化？下面這點是顯而易見的：
既然CPU只有在Local-Access時響應時間才能有保障，那么我們就盡量把該CPU所要的數據集中在他local的內存中就OK啦~
沒錯，事實上Linux識別到NUMA架構后，默認的內存分配方案就是：優先嘗試在請求線程當前所處的CPU的Local內存上分配空間。如果local內存不足，優先淘汰local內存中無用的Page（Inactive，Unmapped）。 那么，問題來了。。。
NUMA的“七宗罪”
幾乎所有的運維都會多多少少被NUMA坑害過，讓我們看看究竟有多少種在NUMA上栽的方式：
- MySQL – The MySQL “swap insanity” problem and the effects of the NUMA architecture
- PostgreSQL – PostgreSQL, NUMA and zone reclaim mode on linux
- Oracle – Non-Uniform Memory Access (NUMA) architecture with Oracle database by examples
- Java – Optimizing Linux Memory Management for Low-latency / High-throughput Databases
究其原因幾乎都和：“因為CPU親和策略導致的內存分配不平均”及“NUMA Zone Claim內存回收”有關，而和數據庫種類並沒有直接聯系。所以下文我們就拿MySQL為例，來看看重內存操作應用在NUMA架構下到底會出現什么問題。
MySQL在NUMA架構上會出現的問題
幾乎所有NUMA + MySQL關鍵字的搜索結果都會指向：Jeremy Cole大神的兩篇文章
- The MySQL “swap insanity” problem and the effects of the NUMA architecture
- A brief update on NUMA and MySQL
大神解釋的非常詳盡，有興趣的讀者可以直接看原文。博主這里做一個簡單的總結：
- CPU規模因摩爾定律指數級發展，而總線發展緩慢，導致多核CPU通過一條總線共享內存成為瓶頸
- 於是NUMA出現了，CPU平均划分為若干個Chip（不多於4個），每個Chip有自己的內存控制器及內存插槽
- CPU訪問自己Chip上所插的內存時速度快，而訪問其他CPU所關聯的內存（下文稱Remote Access）的速度相較慢三倍左右
- 於是Linux內核默認使用CPU親和的內存分配策略，使內存頁盡可能的和調用線程處在同一個Core/Chip中
- 由於內存頁沒有動態調整策略，使得大部分內存頁都集中在
CPU 0上 - 又因為
Reclaim默認策略優先淘汰/Swap本Chip上的內存，使得大量有用內存被換出 - 當被換出頁被訪問時問題就以數據庫響應時間飆高甚至阻塞的形式出現了
解決方案
Jeremy Cole大神推薦的三個方案如下，如果想詳細了解可以閱讀 原文
numactl --interleave=all- 在MySQL進程啟動前，使用
sysctl -q -w vm.drop_caches=3清空文件緩存所占用的空間 - Innodb在啟動時，就完成整個
Innodb_buffer_pool_size的內存分配
這三個方案也被業界普遍認可可行，同時在 Twitter 的5.5patch 和 Percona 5.5 Improved NUMA Support 中作為功能被支持。
不過這種三合一的解決方案只是減少了NUMA內存分配不均，導致的MySQL SWAP問題出現的可能性。如果當系統上其他進程，或者MySQL本身需要大量內存時，Innodb Buffer Pool的那些Page同樣還是會被Swap到存儲上。於是又在這基礎上出現了另外幾個進階方案
- 配置
vm.zone_reclaim_mode = 0使得內存不足時去remote memory分配優先於swap out local page echo -15 > /proc/<pid_of_mysqld>/oom_adj調低MySQL進程被OOM_killer強制Kill的可能- memlock
- 對MySQL使用Huge Page（黑魔法，巧用了Huge Page不會被swap的特性）
重新審視問題
如果本文寫到這里就這么結束了，那和搜索引擎結果中大量的Step-by-Step科普帖沒什么差別。雖然我們用了各種參數調整減少了問題發生概率，那么真的就徹底解決了這個問題么？問題根源究竟是什么？讓我們回過頭來重新審視下這個問題：
NUMA Interleave真的好么？
為什么Interleave的策略就解決了問題？ 借用兩張 Carrefour性能測試 的結果圖，可以看到幾乎所有情況下Interleave模式下的程序性能都要比默認的親和模式要高，有時甚至能高達30%。究其根本原因是Linux服務器的大多數workload分布都是隨機的：即每個線程在處理各個外部請求對應的邏輯時，所需要訪問的內存是在物理上隨機分布的。而Interleave模式就恰恰是針對這種特性將內存page隨機打散到各個CPU Core上，使得每個CPU的負載和Remote Access的出現頻率都均勻分布。相較NUMA默認的內存分配模式，死板的把內存都優先分配在線程所在Core上的做法，顯然普遍適用性要強很多。 
也就是說，像MySQL這種外部請求隨機性強，各個線程訪問內存在地址上平均分布的這種應用，Interleave的內存分配模式相較默認模式可以帶來一定程度的性能提升。 此外 各種 論文 中也都通過實驗證實，真正造成程序在NUMA系統上性能瓶頸的並不是Remote Acess帶來的響應時間損耗，而是內存的不合理分布導致Remote Access將inter-connect這個小水管塞滿所造成的結果。而Interleave恰好，把這種不合理分布情況下的Remote Access請求平均分布在了各個小水管中。所以這也是Interleave效果奇佳的一個原因。
那是不是簡簡單單的配置個Interleave就已經把NUMA的特性和性能發揮到了極致呢？ 答案是否定的，目前Linux的內存分配機制在NUMA架構的CPU上還有一定的改進空間。例如：Dynamic Memory Loaction, Page Replication。
Dynamic Memory Relocation 我們來想一下這個情況：MySQL的線程分為兩種，用戶線程（SQL執行線程）和內部線程（內部功能，如：flush，io，master等）。對於用戶線程來說隨機性相當的強，但對於內部線程來說他們的行為以及所要訪問的內存區域其實是相對固定且可以預測的。如果能對於這把這部分內存集中到這些內存線程所在的core上的時候，就能減少大量Remote Access，潛在的提升例如Page Flush，Purge等功能的吞吐量，甚至可以提高MySQL Crash后Recovery的速度（由於recovery是單線程）。 那是否能在Interleave模式下，把那些明顯應該聚集在一個CPU上的內存集中在一起呢？ 很可惜，Dynamic Memory Relocation這種技術目前只停留在理論和實驗階段。我們來看下難點：要做到按照線程的行為動態的調整page在memory的分布，就勢必需要做線程和內存的實時監控（profile）。對於Memory Access這種非常異常頻繁的底層操作來說增加profile入口的性能損耗是極大的。在 關於CPU Cache程序應該知道的那些事的評論中我也提到過，這個道理和為什么Linux沒有全局監控CPU L1/L2 Cache命中率工具的原因是一樣的。當然優化不會就此停步。上文提到的Carrefour算法和Linux社區的Auto NUMA patch都是積極的嘗試。什么時候內存profile出現硬件級別，類似於CPU中 PMU 的功能時，動態內存規划就會展現很大的價值，甚至會作為Linux Kernel的一個內部功能來實現。到那時我們再回過頭來審視這個方案的實際價值。
Page Replication 再來看一下這些情況：一些動態加載的庫，把他們放在任何一個線程所在的CPU都會導致其他CPU上線程的執行效率下降。而這些共享數據往往讀寫比非常高，如果能把這些數據的副本在每個Memory Zone內都放置一份，理論上會帶來較大的性能提升，同時也減少在inter-connect上出現的瓶頸。實時上，仍然是上文提到的Carrefour也做了這樣的嘗試。由於缺乏硬件級別（如MESI協議的硬件支持）和操作系統原生級別的支持，Page Replication在數據一致性上維護的成本顯得比他帶來的提升更多。因此這種嘗試也僅僅停留在理論階段。當然，如果能得到底層的大力支持，相信這個方案還是有極大的實際價值的。
究竟是哪里出了問題
NUMA的問題？ NUMA本身沒有錯，是CPU發展的一種必然趨勢。但是NUMA的出現使得操作系統不得不關注內存訪問速度不平均的問題。
Linux Kernel內存分配策略的問題？ 分配策略的初衷是好的，為了內存更接近需要他的線程，但是沒有考慮到數據庫這種大規模內存使用的應用場景。同時缺乏動態調整的功能，使得這種悲劇在內存分配的那一刻就被買下了伏筆。
數據庫設計者不懂NUMA？ 數據庫設計者也許從一開始就不會意識到NUMA的流行，或者甚至說提供一個透明穩定的內存訪問是操作系統最基本的職責。那么在現狀改變非常困難的情況下（下文會提到為什么困難）是不是作為內存使用者有義務更好的去理解使用NUMA？
總結
其實無論是NUMA還是Linux Kernel，亦或是程序開發他們都沒有錯，只是還做得不夠極致。如果NUMA在硬件級別可以提供更多低成本的profile接口；如果Linux Kernel可以使用更科學的動態調整策略；如果程序開發人員更懂NUMA，那么我們完全可以更好的發揮NUMA的性能，使得無限橫向擴展CPU核數不再是一個夢想。
- Percona NUMA aware Configuration
- Numa system performance issues – more than just swapping to consider
- MySQL Server and NUMA architectures
- Checking /proc/pid/numa_maps can be dangerous for mysql client connections
- on swapping and kernels
- Optimizing Linux Memory Management for Low-latency / High-throughput Databases
- Memory System Performance in a NUMA Multicore Multiprocessor
- A Case for NUMA-aware Contention Management on Multicore Systems