[[348624]]

為什么這么設(shè)計(jì)(Why’s THE Design)是一系列關(guān)于計(jì)算機(jī)領(lǐng)域中程序設(shè)計(jì)決策的文章，我們在這個系列的每一篇文章中都會提出一個具體的問題并從不同的角度討論這種設(shè)計(jì)的優(yōu)缺點(diǎn)、對具體實(shí)現(xiàn)造成的影響。如果你有想要了解的問題，可以在文章下面留言。

非一致性內(nèi)存訪問(Non-Uniform Memory Access、NUMA)是一種計(jì)算機(jī)內(nèi)存的設(shè)計(jì)方式[^1]，與 NUMA 相對的還有一致性內(nèi)存訪問(Uniform Memory Access、UMA)，也被稱作對稱多處理器架構(gòu)(Symmetric Multi-Processor、SMP)，早期的計(jì)算機(jī)都會使用 SMP，然而現(xiàn)代的多數(shù)計(jì)算機(jī)都會采用 NUMA 架構(gòu)管理 CPU 和內(nèi)存資源。

uma-and-numa

圖 1 - UMA 和 NUMA

作為應(yīng)用程序的開發(fā)者，因?yàn)椴僮飨到y(tǒng)為我們屏蔽了很多硬件層面的實(shí)現(xiàn)細(xì)節(jié)，所以不太需要直接接觸硬件，不過因?yàn)?NUMA 會影響應(yīng)用程序，所以想要寫出高性能、低延遲的服務(wù)，NUMA 是我們必須要了解并熟悉的，本文將從以下兩個方面介紹它的影響：

• NUMA 引入了本地內(nèi)存和遠(yuǎn)程內(nèi)存，CPU 訪問本地內(nèi)存的延遲會小于訪問遠(yuǎn)程內(nèi)存;
• NUMA 的內(nèi)存分配與內(nèi)存回收策略結(jié)合時會可能會導(dǎo)致 Linux 的頻繁交換分區(qū)(Swap)進(jìn)而影響系統(tǒng)的穩(wěn)定性;

本地內(nèi)存

如果主機(jī)使用 NUMA 這種架構(gòu)設(shè)計(jì)，那么 CPU 訪問本地內(nèi)存的延遲會小于訪問遠(yuǎn)程內(nèi)存，這種現(xiàn)象并不是 CPU 設(shè)計(jì)者刻意制造的，而是物理層面的限制。不過 NUMA 這種設(shè)計(jì)并不是與計(jì)算機(jī)一同誕生的，我們在繼續(xù)分析 NUMA 對程序的影響之前先來分析一下 CPU 架構(gòu)的演進(jìn)過程。

在計(jì)算機(jī)誕生的最初幾十年，處理器基本都是單核的，根據(jù)摩爾定律，隨著技術(shù)的進(jìn)步，處理器的性能每隔兩年就會翻一倍[^2]，這一定律在上個世紀(jì)基本都是生效的，然而在過去十幾年，單個處理器中晶體管數(shù)目的增加速度逐漸放緩，很多廠商開始推出了雙核以及多核的計(jì)算機(jī)。

moores-law

圖 2 - 摩爾定律

單核或者多核計(jì)算機(jī)上的 CPU 最早會通過前端總線(Front-side bus)、北橋(Northbridge)和內(nèi)存總線(Memory bus)訪問內(nèi)存槽中的內(nèi)存，所有的 CPU 會通過相同的總線訪問相同的內(nèi)存以及 I/O 設(shè)備，計(jì)算機(jī)中的所有資源都是共享的，這種架構(gòu)被稱作對稱多處理器架構(gòu)(Symmetric Multi-Processor、SMP)，也被稱為一致存儲器訪問結(jié)構(gòu)(Uniform Memory Access、UMA)。

single-and-multi-core

圖 3 - 單核和多核處理器

然而隨著計(jì)算機(jī)中 CPU 數(shù)量的增加，多個 CPU 都需要通過總線和北橋訪問內(nèi)存，當(dāng)同一個主機(jī)中包含幾十個 CPU 時，總線和北橋兩個模塊成為了系統(tǒng)的瓶頸，為了解決這一問題，CPU 架構(gòu)的設(shè)計(jì)者使用如下所示的多個 CPU 模塊解決了這個問題：

numa-local-remote-access

圖 4 - 雙節(jié)點(diǎn) NUMA 架構(gòu)

如上圖所示，該主機(jī)中包含 2 個 NUMA 節(jié)點(diǎn)，每個 NUMA 節(jié)點(diǎn)都包含物理 CPU 和內(nèi)存，從圖中我們可以看出 CPU 1 訪問本地內(nèi)存和遠(yuǎn)程內(nèi)存會經(jīng)過不同的通道，這是訪問內(nèi)存時間不同的根本原因。

操作系統(tǒng)作為管理計(jì)算機(jī)硬件、軟件資源并為應(yīng)用程序提供通用服務(wù)的軟件，它本身就會與底層的硬件打交道，Linux 操作系統(tǒng)就會為我們提供硬件相關(guān)的 NUMA 信息，你可以直接通過 numactl 命令查看機(jī)器上的 NUMA 節(jié)點(diǎn)[^3]：

$ numactl -H 
available: 2 nodes (0-1) 
node 0 cpus: 0 1 2 3 4 5 6 7 8 9 10 11 24 25 26 27 28 29 30 31 32 33 34 35 
node 0 size: 63539 MB 
node 0 free: 18566 MB 
node 1 cpus: 12 13 14 15 16 17 18 19 20 21 22 23 36 37 38 39 40 41 42 43 44 45 46 47 
node 1 size: 64485 MB 
node 1 free: 20716 MB 
node distances: 
node   0   1 
  0:  10  21 
  1:  21  10 

從上述輸出結(jié)果我們可以看出，該機(jī)器上包含兩個 NUMA 節(jié)點(diǎn)，每個節(jié)點(diǎn)上都包含 24 個 CPU 以及 64GB 的內(nèi)存，最后的節(jié)點(diǎn)距離(node distances)告訴我們兩個 NUMA 節(jié)點(diǎn)訪問內(nèi)存的開銷，其中 NUMA 節(jié)點(diǎn) 0 和 NUMA 節(jié)點(diǎn) 1 互相訪問對方內(nèi)存的延遲是各自節(jié)點(diǎn)訪問本地內(nèi)存的 2.1 倍(21 / 10 = 2.1)，所以如果 NUMA 節(jié)點(diǎn) 0 上的進(jìn)程如果在節(jié)點(diǎn) 1 上分配內(nèi)存，會增加進(jìn)程的延遲。

正是因?yàn)?NUMA 節(jié)點(diǎn)訪問不同內(nèi)存的開銷不同，所以操作系統(tǒng)會為應(yīng)用程序提供接口控制 CPU 和內(nèi)存的分配策略，在 Linux 系統(tǒng)中，我們可以使用 numactl 命令控制進(jìn)程使用的 CPU 和內(nèi)存。

numactl 提供了 cpunodebind 和 physcpubind 兩種策略為進(jìn)程分配 CPU，這兩種策略分別提供了不同粒度的綁定方法：

• cpunodebind — 將進(jìn)程綁定到某幾個 NUMA 節(jié)點(diǎn)上;
• physcpubind — 將進(jìn)程綁定到某幾個物理 CPU 上;

除了這兩種 CPU 分配策略之外，numactl 還提供四種不同的內(nèi)存分配策略，分別是：localalloc、preferred、membind 和 interleave：

• localalloc — 總是在當(dāng)前節(jié)點(diǎn)上分配內(nèi)存;
• preferred — 傾向于在特定節(jié)點(diǎn)上分配內(nèi)存，當(dāng)指定節(jié)點(diǎn)的內(nèi)存不足時，操作系統(tǒng)會在其他節(jié)點(diǎn)上分配;
• membind — 只能在傳入的幾個節(jié)點(diǎn)上分配內(nèi)存，當(dāng)指定節(jié)點(diǎn)的內(nèi)存不足時，內(nèi)存的分配就會失敗;
• interleave — 內(nèi)存會在傳入的節(jié)點(diǎn)上依次分配(Round Robin)，當(dāng)指定節(jié)點(diǎn)的內(nèi)存不足時，操作系統(tǒng)會在其他節(jié)點(diǎn)上分配;

上述的兩種 CPU 分配策略和四種內(nèi)存分配策略是我們與 NUMA 打交道時經(jīng)常需要接觸的，當(dāng)進(jìn)程的性能受到 NUMA 的影響時，我們可能需要通過 numactl 命令調(diào)整 CPU 或者內(nèi)存的分配策略。

交換分區(qū)

NUMA 架構(gòu)雖然能夠解決總線上的性能瓶頸并可以讓我們在同一個主機(jī)上運(yùn)行更多的 CPU，但是如果不了解 NUMA 的工作原理或者使用錯誤的策略會帶來一些問題，Jeremy Cole 的文章 The MySQL “swap insanity” problem and the effects of the NUMA architecture 就曾經(jīng)分析過 NUMA 架構(gòu)下 MySQL 可能出現(xiàn)的問題 — 頻繁發(fā)生的交換分區(qū)影響服務(wù)延遲[^4]，我們在這里簡單介紹一下該問題背后的原因：

uneven-memory-node

圖 5 - 分配不均勻的內(nèi)存

因?yàn)?MySQL 等數(shù)據(jù)庫的運(yùn)行會占用大量的內(nèi)存，在默認(rèn)情況進(jìn)程會先在所在的 NUMA 節(jié)點(diǎn)上分配內(nèi)存，當(dāng)本地內(nèi)存不足時，才會在遠(yuǎn)程分配內(nèi)存。如上圖所示，主機(jī)上包含兩個 NUMA 節(jié)點(diǎn)，其中每個節(jié)點(diǎn)都有 32GB 的內(nèi)存，但是當(dāng) MySQL InnoDB 的緩存池占用 48GB 的內(nèi)存時，它會在 NUMA 節(jié)點(diǎn) 0 和 NUMA 節(jié)點(diǎn) 1 分別分配 32GB 和 16GB 的內(nèi)存。

雖然 48GB 的內(nèi)存遠(yuǎn)遠(yuǎn)沒有到達(dá)主機(jī) 64GB 的內(nèi)存上限，但是當(dāng)某些數(shù)據(jù)必須要在 NUMA 節(jié)點(diǎn) 0 的內(nèi)存上分配時，就會導(dǎo)致 NUMA 節(jié)點(diǎn) 0 中的內(nèi)存被交換到了文件系統(tǒng)上為新的內(nèi)存請求讓出位置[^5]，InnoDB 緩存池中內(nèi)存的頻繁換入和換出會使 MySQL 的查詢隨機(jī)地出現(xiàn)延遲，而一旦發(fā)生了交換分區(qū)，可能就是性能螺旋下降的開始。

Linux 中的 zone_reclaim_mode 可以允許工程師設(shè)置在 NUMA 節(jié)點(diǎn)內(nèi)存不足時內(nèi)存的回收策略，在默認(rèn)情況下該模式都會處于關(guān)閉狀態(tài)[^6]，如果我們在 NUMA 系統(tǒng)中通過該配置啟用了激進(jìn)的內(nèi)存回收策略，可能會影響程序的性能[^7]，MySQL 也會受到內(nèi)存回收策略的影響，但是僅僅關(guān)閉該策略并不會解決它遇到的頻繁觸發(fā)交換分區(qū)的問題[^8]。

$ cat /proc/sys/vm/zone_reclaim_mode 
0 

想要解決該問題，我們需要使用上一節(jié)提到的 numactl 將內(nèi)存的分配策略改為 interleave，使用該內(nèi)存分配策略會使得 MySQL 的內(nèi)存均勻地分配到不同的 NUMA 節(jié)點(diǎn)上，能夠降低頁面頻繁換入換出的可能性。

even-memory-node

圖 6 - 分配均勻的內(nèi)存

該問題并不是 MySQL 獨(dú)有的，很多占用大量內(nèi)存的數(shù)據(jù)庫都會遇到上述問題，雖然使用 interleave 能夠暫時解決這些問題，但是 MySQL 進(jìn)程訪問遠(yuǎn)程內(nèi)存時，與本地內(nèi)存相比仍然會遇到性能損失，想要一勞永逸地避免服務(wù)在 NUMA 上運(yùn)行的額外開銷，最好的辦法還是開發(fā)能夠感知底層 NUMA 架構(gòu)的應(yīng)用程序。以 MySQL 為例，Jeremy Cole 在文章中提出了如下的修改，可以更好地利用 NUMA 的本地內(nèi)存[^9]：

• 將緩存池中的數(shù)據(jù)按照塊或者索引智能地分配到不同節(jié)點(diǎn)上;
• 為正常的查詢線程保留默認(rèn)的分配策略，內(nèi)存還是會優(yōu)先分配本地節(jié)點(diǎn)上;
• 將簡單的查詢線程重新調(diào)度到能夠訪問本地內(nèi)存的節(jié)點(diǎn)上;

除了 MySQL 可以利用 NUMA 來提高性能之外，一些框架或者編程語言也可以通過感知底層的 NUMA 信息來提升服務(wù)的響應(yīng)速度，例如 Go 語言社區(qū)中就有關(guān)于 NUMA 感知調(diào)度的設(shè)計(jì)文檔[^10]，雖然由于該特性的實(shí)現(xiàn)過于復(fù)雜，目前沒有投入到開發(fā)中，但是這仍然是調(diào)度器未來的發(fā)展方向。

總結(jié)

很多軟件工程師可能認(rèn)為操作系統(tǒng)以及底層的硬件與我們的距離非常遙遠(yuǎn)，我們在開發(fā)軟件時不需要考慮這么多細(xì)節(jié)，對于絕大多數(shù)的應(yīng)用程序來說，這一點(diǎn)都是成立的，操作系統(tǒng)能夠?yàn)槲覀兤帘魏芏嗟讓拥膶?shí)現(xiàn)細(xì)節(jié)，讓我們能夠?qū)⒏嗟木ν度氲綐I(yè)務(wù)邏輯的實(shí)現(xiàn)上。

不過正如我們在文章中提到的，哪怕操作系統(tǒng)做出再多的隔離和抽象，物理世界存在的限制還是會在暗處影響我們的應(yīng)用程序，想要開發(fā)高性能的軟件必須要關(guān)注下兩層甚至更底層的實(shí)現(xiàn)細(xì)節(jié)，NUMA 這種硬件層面的設(shè)計(jì)就會深刻的影響我們的軟件，這里再來回顧一下文章開頭提到的兩點(diǎn)影響：

• NUMA 引入了本地內(nèi)存和遠(yuǎn)程內(nèi)存，CPU 訪問本地內(nèi)存的延遲會小于訪問遠(yuǎn)程內(nèi)存;
• NUMA 的內(nèi)存分配與內(nèi)存回收策略結(jié)合時會可能會導(dǎo)致 Linux 的頻繁交換分區(qū)(Swap)進(jìn)而影響系統(tǒng)的穩(wěn)定性;

我們當(dāng)然更希望主機(jī)上的所有 CPU 都能夠快速地訪問全部的內(nèi)存，但是硬件的限制導(dǎo)致我們無法實(shí)現(xiàn)這么理想的情況，而 NUMA 可能是 CPU 架構(gòu)發(fā)展的必然方向，通過將 CPU 和內(nèi)存資源分組降低總線的壓力，讓單個主機(jī)容納很多的 CPU。到最后，我們還是來看一些比較開放的相關(guān)問題，有興趣的讀者可以仔細(xì)思考一下下面的問題：

NUMA 架構(gòu)最多可以支持多少 CPU?該架構(gòu)又存在哪些瓶頸?

MPP(Massive Parallel Processing)是如何擴(kuò)展系統(tǒng)的?它解決了哪些問題?

• Optimizing Linux Memory Management for Low-latency / High-throughput Databases https://engineering.linkedin.com/performance/optimizing-linux-memory-management-low-latency-high-throughput-databases
• NUMA (Non-Uniform Memory Access): An Overview https://queue.acm.org/detail.cfm?id=2513149
• PostgreSQL, NUMA and zone reclaim mode on linux http://frosty-postgres.blogspot.com/2012/08/postgresql-numa-and-zone-reclaim-mode.html

本文轉(zhuǎn)載自微信公眾號「真沒什么邏輯」，可以通過以下二維碼關(guān)注。轉(zhuǎn)載本文請聯(lián)系真沒什么邏輯公眾號。