摘要：有競爭，就會(huì)有性能損失。內(nèi)核之間互相競爭共享資源，比如系統(tǒng)請求隊(duì)列和內(nèi)存管理器等。至于原因，下文將會(huì)給出。原因在于還是在相互競爭。事實(shí)上在系統(tǒng)中這的確是起作用了雖然對于的競爭還是存在的。而且還引來了兩個(gè)問題，這兩個(gè)問題會(huì)嚴(yán)重影響的性能。。

本文參考了以下這篇論文：

A Case for NUMA-aware Contention Management on Multicore Systems 直接點(diǎn)擊鏈接就可以下載

上一篇文章 簡單地介紹了一下多 CPU 下的 NUMA 架構(gòu)。NUMA 架構(gòu)中將內(nèi)存劃分為多個(gè)不同的區(qū)域，將CPU 和臨近的內(nèi)存組成一個(gè) node 節(jié)點(diǎn)，OS 調(diào)度的時(shí)候會(huì)優(yōu)先使用臨近的內(nèi)存，從而解決了之前 UMA 架構(gòu)下 BUS 帶來的性能問題（因?yàn)槎鄠€(gè) CPU 會(huì)對這一條總線產(chǎn)生競爭）。同時(shí)也講到了在MySQL在 NUMA 架構(gòu)下遇到的 “swap insanity”問題，也就是當(dāng)MySQL 占用的內(nèi)存超過 (100 / node 總數(shù)) % 時(shí)，由于『優(yōu)先使用臨近內(nèi)存』這個(gè)調(diào)度模式的存在，造成了內(nèi)存分配不均，導(dǎo)致系統(tǒng)整體內(nèi)存充足的情況下，依然出現(xiàn)大量『不正?！坏牡?swap 現(xiàn)象。如下圖所示：

本文將從『資源競爭管理』的角度切入，將會(huì)看到UMA 時(shí)代的競爭管理算法將不再適用于 NUMA，并給出具體的原因分析和解決方案?？赐曛笙嘈拍阋欢〞?huì)對 NUMA有更加深刻的理解，并對多CPU 時(shí)代的編程有個(gè)感性的認(rèn)識(shí)。

有共享資源的地方，就會(huì)有競爭。有競爭，就會(huì)有性能損失。

一直以來，多核系統(tǒng)的共享資源競爭都是一個(gè)大問題。內(nèi)核之間互相競爭共享資源，比如 last-level cache（LLC）、系統(tǒng)請求隊(duì)列和內(nèi)存管理器等。目前比較流行的解決方案叫做 contention-aware scheduler（競爭感知調(diào)度程序，下面簡稱為 CAS），也就是說它能夠區(qū)分在互相競爭共享資源的 threads，然后把他們分開到不同的 domain。有數(shù)據(jù)顯示，這種調(diào)度方法可以提高最壞情況下80%、平均10%的性能。

這種算法在 UMA 中是有效的。但是需要考慮到的是， NUMA 相比 UMA 有一點(diǎn)很大的不同，那就是 UMA 只有一個(gè) memory node，配備一個(gè) memory controller；而 NUMA中 每個(gè) node 里面都有一個(gè) memory node，各自配備了一個(gè) memory controller，如下圖所示：16個(gè)核被分為了4個(gè) node，每個(gè) node 有一個(gè)獨(dú)立的 memory（當(dāng)然每個(gè)核都可以訪問任意位置的內(nèi)存）。

那么這種調(diào)度方式到底起不起作用呢？如果只是簡單的想一下的話，也許會(huì)覺得為什么不行呢？如果同一個(gè) node 里面的 threads 競爭特別激烈，那我就把其中一個(gè)移到另一個(gè) node 上，雖然說這會(huì)帶來一定的延遲，但是競爭就解決了啊。

然后，事情沒那么簡單，一切真理都來自于實(shí)踐，實(shí)踐發(fā)現(xiàn)，在 NUMA 上面實(shí)施這種調(diào)度算法的時(shí)候，非但沒能很好地解決競爭，反而性能下降了30%。至于原因，下文將會(huì)給出。

在 NUMA 架構(gòu)下，CAS 會(huì)感知有哪些相互競爭的 threads，然后把其中一個(gè)移到不同的 domain 中。這會(huì)導(dǎo)致一種情況：thread的內(nèi)存沒有分配在該thread 運(yùn)行的那個(gè) node 里面，比如說上圖中，一個(gè) thread 本來運(yùn)行在 c1上，之后由于競爭被移到 c5上了，但是它的 memory 還在 M1。我們把這種由于移動(dòng) thread，導(dǎo)致 thread 和它的內(nèi)存分家的行為稱作『NUMA-agnostic migrations』（agnostic 中文意思是不可知，自已意會(huì)一下~）。

NUMA-agnostic migrations導(dǎo)致了一些問題，比較明顯一點(diǎn)的是thread 獲取內(nèi)存的延遲提高了，不過這還不是關(guān)鍵。更重要的是，NUMA-agnostic migrations無法緩解一些關(guān)鍵資源（memory controller）的競爭問題，甚至還引起對更多資源（interconnect connection）的競爭。

下面這張圖很重要，請仔細(xì)看：

解釋一下：T 和 C 分別表示兩個(gè)程序（thread）

圖0：兩個(gè)程序相安無事，沒有競爭關(guān)系。

圖1：CT 的內(nèi)存在一個(gè) node，對 memory controller（MC） 產(chǎn)生了競爭關(guān)系。（應(yīng)該還有訪問延遲，圖中可能忘記標(biāo)注了）

圖2： 兩個(gè)程序都需要試用進(jìn)行CPU 之間的快速通道，產(chǎn)生了interconnect connection（IC）競爭。同時(shí)還有訪問遠(yuǎn)程 memory 帶來的訪問延遲（RL）。

圖3：memory controller （MC）競爭，加上遠(yuǎn)程訪問延時(shí)（RL）。

圖4：TC 位于一個(gè) CPU 里面，對 last-level cache（CA） 產(chǎn)生競爭關(guān)系。

圖5：CA + RL

圖6：CA + MC

圖7：最壞的情況，CA + MC + IC + MC

實(shí)驗(yàn)發(fā)現(xiàn)，圖3的性能下降了110%。原因在于 threads 還是在相互競爭 memory controller。NUMA-agnostic migrations在遷移 thread 的時(shí)候，很有可能最后會(huì)導(dǎo)致這種情況出現(xiàn)。

假如現(xiàn)在有兩個(gè)threads，A 和 B，A 運(yùn)行在圖一中的 c1上，B 運(yùn)行在 c2上，他們之間存在競爭關(guān)系（競爭last-level cache）。現(xiàn)在有一個(gè) contention-aware 調(diào)度器檢測到了 A 和 B 的競爭關(guān)系，于是把 B 移動(dòng)到 c5上去了，現(xiàn)在A 和 B 不再競爭 last-level cache 了。事實(shí)上在 UMA 系統(tǒng)中這的確是起作用了（雖然對于 memory controller 的競爭還是存在的）。

但是對于 NUMA，A 和 B 的 memory 還在一個(gè)地方，對于 最關(guān)鍵資源memory controller 的競爭沒有得到解決。而且還引來了兩個(gè)問題，這兩個(gè)問題會(huì)嚴(yán)重影響 B 的性能。

interconnect connection。（這點(diǎn)影響會(huì)很嚴(yán)重）

remote access。

NUMA-agnostic migrations無法提高 甚至還會(huì)降低NUMA競爭管理的性能，按照對性能的影響程度排序有：

沒能夠解決對 memory controller 的競爭關(guān)系（memory 還在原來那個(gè)地方）。

引起了額外的 interconnect connection。

引起了額外的 remote access。

原論文中還提到了作者自己研究出的一種解決方案，有興趣的同學(xué)可以去啃一下原文。

相信你看完了，應(yīng)該對 NUAM 架構(gòu)有了一個(gè)比較感性的認(rèn)識(shí)了吧。覺得寫的不錯(cuò)（看在gakki 的情面上）不點(diǎn)個(gè)贊鼓勵(lì)一下？

廣告時(shí)間，歡迎大家關(guān)注我的微信公眾號(hào)。同時(shí)本文同步于 github： https://github.com/liaochangjiang/TechDaily