對於對吞吐量和延遲有極致追求的程式來說，提升應用程式的執行速度無疑能夠顯著增強其核心競爭力。下面就本人目前的認識簡要介紹如下，有不足之處，還望指正。

阻止CPU的切換

CPU的切換會給成勳的執行帶來非常大的損耗，主要是因為CPU切換帶來的是CPU對應的記憶體資料的洗禮，當程式執行的CPU發生切換時，由於目前的CPU架構大部分都是NUMA架構，記憶體控制器天然的會把記憶體進行切割，固定分配到各個CPU，這就使得如果執行程式的CPU發生切換時，就需要重建頁表，以建立虛擬記憶體和實際實體記憶體之間的對映關係，而這會極大的影響程式的執行速度。

解決方案：
為應用程式繫結CPU。

依據應用程式的特點開啟大頁記憶體

目前作業系統的記憶體都比較大，動輒幾十G非常常見，如果應用程式屬於高記憶體佔用型，那麼使用預設的記憶體分頁大小（4KB）會使得虛擬記憶體和實體記憶體之間的頁表變大，增加了記憶體地址的檢索時間，同時也增大了快表失效的概率，如此將會增加CPU和記憶體互動的耗時，從而影響應用程式的響應時間。

當然對於記憶體佔用比較小，且記憶體訪問不隨機的應用程式，則不需要開啟大頁記憶體，因為該類應用程式不會出現塊表失效的可能或者說極少出現。

解決方案：
開啟作業系統的大頁記憶體。

依據應用場景合理控制記憶體分配策略

NUMA架構決定了CPU對於local access的時間遠低於remote access，所以如果能夠根據應用場景合理的控制記憶體分配策略，同時配合CPU的繫結機制，可以使得應用程式在指定的CPU上執行且改CPU不會remote access去訪問其他節點的記憶體，那麼就能夠最大限度的提升應用程式的執行速度。

NUMA架構

在NUMA架構出現前，CPU歡快的朝著頻率越來越高的方向發展。受到物理極限的挑戰，又轉為核數越來越多的方向發展。如果每個core的工作性質都是share-nothing（類似於map-reduce的node節點的作業屬性），那麼也許就不會有NUMA。由於所有CPU Core都是通過共享一個北橋來讀取記憶體，隨著核數如何的發展，北橋在響應時間上的效能瓶頸越來越明顯。於是，聰明的硬體設計師們，先到了把記憶體控制器（原本北橋中讀取記憶體的部分）也做個拆分，平分到了每個die上。於是NUMA就出現了！

NUMA中，雖然記憶體直接attach在CPU上，但是由於記憶體被平均分配在了各個die上。只有當CPU訪問自身直接attach記憶體對應的實體地址時，才會有較短的響應時間（後稱Local Access）。而如果需要訪問其他CPU attach的記憶體的資料時，就需要通過inter-connect通道訪問，響應時間就相比之前變慢了（後稱Remote Access）。所以NUMA（Non-Uniform Memory Access）就此得名。