=============================================================
NUMA(Non-Uniform Memory Access)，非一致性內存訪問
NUMA服務器的基本特征是具有多個CPU模塊，每個CPU模塊由多個CPU(如4個)組成，並且具有獨立的本地內存、I/O槽口等。由於其節點之間可以通過互聯模塊(如稱為Crossbar Switch)進行連接和信息交互，因此每個CPU可以訪問整個系統的內存(這是NUMA系統與MPP系統的重要差別)。顯然，訪問本地內存的速度將遠遠高於訪問遠地內存(系統內其它節點的內存)的速度，這也是非一致存儲訪問NUMA的由來。
利用NUMA技術，可以較好地解決原來SMP系統的擴展問題，在一個物理服務器內可以支持上百個CPU。但NUMA技術同樣有一定缺陷，由於訪問遠地內存的延時遠遠超過本地內存，因此當CPU數量增加時，系統性能無法線性增加。
=============================================================
查看CPU和MUMA的拓撲信息
numactl --hardware
上面是2U服務器，配置64G內存
=============================================================
MySQL與NUMA問題
在單實例的MySQL服務器上，通過會為MySQL的Buffer Pool分配50%至70%甚至更高的內存，讓MySQL 服務會盡可能多地占用系統資源。在基於NUMA系統中，內存被分配到各NUMA節點上，系統的默認為進程分配該進程所在NUMA節點的內存，而數據庫應用又希望使用到所有CPU節點和內存，由於MySQL對NUMA支持不是很完善，在特殊場景中容易出現系統擁有空閑內存但發生SWAP導致性能問題的情況。
如對於2個NUMA節點64GB內存的MySQL服務器來說，為MySQL Buffer Pool配置48GB的內存，在默認NUMA策略下，會存在以下問題：
1、節點0和節點1的內存分配不平衡，內存會優先分配給節點0，節點1被用於備份，如：
2、當屬於節點0的內存完全分配給節點0，如果位於NODE0上的進程調度需要大量內存，盡管節點1仍有大量空閑物理內存，也不會將NODE1上的內存分配給該進程使用，由於節點0已無空閑內存，因此會導致NODE0上部分內存被SWAP到磁盤上，引發性能問題。
=============================================================
為MySQL關閉NUMA
在MUMA架構下，雖然訪問其他節點內存的性能低於訪問本地節點內存，但並不是導致性能問題的主要原因，為解決系統存在空閑內存而部分NUMA發生SWAP操作的問題.
解決方式：
1、在BIOS層關閉NUMA
2、在Linux Kernel啟動參數中加上numa=off（這樣也會影響到其他進程使用NUMA）；
3、在mysqld_safe腳本中加上“numactl –interleave all”來啟動mysqld。
參數--interleave=nodes用於設定內存的交織分配模式，即系統在為多個節點分配內存空間時，將以輪詢分發的方式分配給多個節點，如果當前眾多的交織分配內存節點中的目標節點無法正確地分配內存空間的話，內存空間將會由其他節點來分配。
修改后MySQL內存分配如：
=============================================================
參考資料：
http://mysql.taobao.org/monthly/2015/07/06/
http://linux.51yip.com/search/numactl
http://sohulinux.blog.sohu.com/181968823.html
http://imysql.com/2016/11/30/mysql-faq-find-who-cause-mysql-swap.shtml?utm_source=tuicool&utm_medium=referral
=============================================================