<kbd id="afajh"><form id="afajh"></form></kbd>
<strong id="afajh"><dl id="afajh"></dl></strong>
    <del id="afajh"><form id="afajh"></form></del>
        1. <th id="afajh"><progress id="afajh"></progress></th>
          <b id="afajh"><abbr id="afajh"></abbr></b>
          <th id="afajh"><progress id="afajh"></progress></th>

          為什么 HugePages 可以提升數(shù)據(jù)庫(kù)性能

          共 4732字,需瀏覽 10分鐘

           ·

          2020-11-24 10:42

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

          內(nèi)存是計(jì)算機(jī)的重要資源,雖然今天大多數(shù)的服務(wù)對(duì)內(nèi)存的需求都沒(méi)有那么高,但是數(shù)據(jù)庫(kù)以及 Hadoop 全家桶這些服務(wù)卻是消耗內(nèi)存的大戶,它們?cè)谏a(chǎn)環(huán)境動(dòng)輒占用 GB 和 TB 量級(jí)的內(nèi)存來(lái)提升計(jì)算的速度,Linux 操作系統(tǒng)為了更好、更快地管理這些內(nèi)存并降低開(kāi)銷(xiāo)引入了很多策略,我們今天要介紹的是 HugePages,也就是大頁(yè)[^1]。

          絕大多數(shù)的 CPU 架構(gòu)都支持更大的頁(yè)面,只是不同操作系統(tǒng)會(huì)使用不同的術(shù)語(yǔ),例如:Linux 上的 HugePages、BSD 上的 SuperPages 以及 Windows 上的 LargePages,這些不同的術(shù)語(yǔ)都代表著類(lèi)似的大頁(yè)面功能。

          圖 1 - CPU 架構(gòu)和更大的頁(yè)面

          我們都知道 Linux 會(huì)以頁(yè)為單位管理內(nèi)存,而默認(rèn)的頁(yè)面大小為 4KB,雖然部分處理器會(huì)使用 8KB、16KB 后者 64KB 作為默認(rèn)的頁(yè)面大小,不過(guò) 4KB 仍然是操作系統(tǒng)的默認(rèn)頁(yè)面配置的主流[^2],雖然 64KB 的頁(yè)面是 4KB 的 16 倍,但是與最小 2MB 的 HugePages 相比,64KB 的頁(yè)面實(shí)在是不夠大,更不用說(shuō)默認(rèn)的 4KB 了:

          圖 2 - 默認(rèn)和大頁(yè)面大小

          2MB 一般都是 HugePages 的默認(rèn)大小,在 arm64 和 x86_64 的架構(gòu)上甚至支持 1GB 的大頁(yè)面,是 Linux 默認(rèn)頁(yè)面大小的 262,144 倍,我們可以使用如下所示的命令查看當(dāng)前機(jī)器上 HugePages 的相關(guān)信息:

          $ cat /proc/meminfo | grep Huge
          AnonHugePages: 71680 kB
          ShmemHugePages: 0 kB
          FileHugePages: 0 kB
          HugePages_Total: 0
          HugePages_Free: 0
          HugePages_Rsvd: 0
          HugePages_Surp: 0
          Hugepagesize: 2048 kB
          Hugetlb: 0 kB

          通過(guò)上面的輸出結(jié)果,我們可以看到當(dāng)前機(jī)器上的大頁(yè)面默認(rèn)大小為 2MB 并且大頁(yè)面的數(shù)量也為 0,即沒(méi)有進(jìn)程在申請(qǐng)或者使用大頁(yè)。各位讀者可以在 Linux 嘗試執(zhí)行上述命令,如果機(jī)器上沒(méi)有做過(guò)額外的配置,那么使用上述命令得到的輸出與這里也不會(huì)有太大的差別。

          /proc/sys/vm/nr_hugepages 中存儲(chǔ)的數(shù)據(jù)就是大頁(yè)面的數(shù)量,雖然在默認(rèn)情況下它的值都是 0,不過(guò)我們可以通過(guò)更改該文件的內(nèi)容申請(qǐng)或者釋放操作系統(tǒng)中的大頁(yè):

          $ echo 1 > /proc/sys/vm/nr_hugepages
          $ cat /proc/meminfo | grep HugePages_
          HugePages_Total: 1
          HugePages_Free: 1
          ...

          在 Linux 中,與其他內(nèi)存的申請(qǐng)和釋放方式相同,我們可以在向 mmap 系統(tǒng)調(diào)用中傳入 MAP_HUGETLB 標(biāo)記申請(qǐng)操作系統(tǒng)的大頁(yè)并使用 munmap 釋放內(nèi)存[^3],使用如下所示的代碼片段可以在操作系統(tǒng)中申請(qǐng) 2MB 的大頁(yè):

          size_t?s?=?(2UL?*?1024?*?1024);

          char?*m?=?mmap(
          ????NULL,?s,?PROT_READ?|?PROT_WRITE,
          ????MAP_PRIVATE?|?MAP_ANONYMOUS?|?MAP_HUGETLB?/*?flags?*/,
          ????-1,?0
          );

          munmap(m,?s);

          雖然 HugePages 的申請(qǐng)方式與默認(rèn)的內(nèi)存相差不多,但是它實(shí)際上是操作系統(tǒng)單獨(dú)管理的特殊資源,Linux 會(huì)在 /proc/meminfo 中單獨(dú)展示 HugePages 的相關(guān)數(shù)據(jù),而容器編排系統(tǒng) Kubernetes 也會(huì)認(rèn)為大頁(yè)是不同于內(nèi)存的獨(dú)立資源,如下所示的 Pod 也需要單獨(dú)申請(qǐng)大頁(yè)資源[^4]:

          apiVersion:?v1
          kind:?Pod
          metadata:
          ??name:?huge-pages-example
          spec:
          ??containers:
          ??-?name:?example
          ????...
          ????volumeMounts:
          ????-?mountPath:?/hugepages-2Mi
          ??????name:?hugepage-2mi
          ????-?mountPath:?/hugepages-1Gi
          ??????name:?hugepage-1gi
          ????resources:
          ??????limits:
          ????????hugepages-2Mi:?100Mi
          ????????hugepages-1Gi:?2Gi
          ????????memory:?100Mi
          ??????requests:
          ????????memory:?100Mi
          ??volumes:
          ??-?name:?hugepage-2mi
          ????emptyDir:
          ??????medium:?HugePages-2Mi
          ??-?name:?hugepage-1gi
          ????emptyDir:
          ??????medium:?HugePages-1Gi

          作為 Linux 從 2.6.32 引入的新特性,HugePages 能夠提升數(shù)據(jù)庫(kù)、Hadoop 全家桶等占用大量?jī)?nèi)存的服務(wù)的性能,該特性對(duì)于常見(jiàn)的 Web 服務(wù)以及后端服務(wù)沒(méi)有太多的幫助,反而可能會(huì)影響服務(wù)的性能,我們?cè)谶@篇文章中會(huì)介紹 HugePages 為什么能夠提升數(shù)據(jù)庫(kù)等服務(wù)的性能:

          • HugePages 可以降低內(nèi)存頁(yè)面的管理開(kāi)銷(xiāo);
          • HugePages 可以鎖定內(nèi)存,禁止操作系統(tǒng)的內(nèi)存交換和釋放;

          管理開(kāi)銷(xiāo)

          雖然 HugePages 的開(kāi)啟大都需要開(kāi)發(fā)或者運(yùn)維工程師的額外配置,但是在應(yīng)用程序中啟用 HugePages 卻可以在以下幾個(gè)方面降低內(nèi)存頁(yè)面的管理開(kāi)銷(xiāo):

          • 更大的內(nèi)存頁(yè)能夠減少內(nèi)存中的頁(yè)表層級(jí),這不僅可以降低頁(yè)表的內(nèi)存占用,也能降低從虛擬內(nèi)存到物理內(nèi)存轉(zhuǎn)換的性能損耗;
          • 更大的內(nèi)存頁(yè)意味著更高的緩存命中率,CPU 有更高的幾率可以直接在 TLB(Translation lookaside buffer)中獲取對(duì)應(yīng)的物理地址;
          • 更大的內(nèi)存頁(yè)可以減少獲取大內(nèi)存的次數(shù),使用 HugePages 每次可以獲取 2MB 的內(nèi)存,是 4KB 的默認(rèn)頁(yè)效率的 512 倍;

          因?yàn)檫M(jìn)程的地址空間都是虛擬的,所以 CPU 和操作系統(tǒng)需要記錄頁(yè)面和進(jìn)程之間的對(duì)應(yīng)關(guān)系,操作系統(tǒng)中的頁(yè)面越多,我們也就需要花費(fèi)更多的時(shí)間在如下所示的五層頁(yè)表結(jié)構(gòu)中查找虛擬內(nèi)存對(duì)應(yīng)的物理內(nèi)存,我們會(huì)根據(jù)虛擬地址依次訪問(wèn)頁(yè)表中的目錄(Directory)最終查找到對(duì)應(yīng)的物理內(nèi)存:

          圖 3 - 默認(rèn)頁(yè)的五層頁(yè)表

          如上圖所示,如果我們使用 Linux 中默認(rèn)的 4KB 內(nèi)存頁(yè),那么 CPU 在訪問(wèn)對(duì)應(yīng)的內(nèi)存時(shí)需要分別讀取 PGD、PUD、PMD 和 PTE 才能獲取物理內(nèi)存,但是 2MB 的大內(nèi)存可以減少目錄訪問(wèn)的次數(shù):

          圖 4 - 頁(yè)表與大頁(yè)

          因?yàn)?2MB 的內(nèi)存頁(yè)占用了 21 位的地址,所以我們也不再需要五層頁(yè)表中的 PTE 結(jié)構(gòu),這不僅能夠減少翻譯虛擬地址時(shí)訪問(wèn)頁(yè)表的次數(shù),還能夠降低頁(yè)表的內(nèi)存占用。

          CPU 總可以通過(guò)上述復(fù)雜的目錄結(jié)構(gòu)找到虛擬頁(yè)對(duì)應(yīng)的物理頁(yè),但是每次翻譯虛擬地址時(shí)都使用上述結(jié)構(gòu)是非常昂貴的操作,操作系統(tǒng)使用 TLB 作為緩存來(lái)解決這個(gè)問(wèn)題,TLB 是內(nèi)存管理組件(Memory Management Unit)的一個(gè)部分,其中緩存的頁(yè)表項(xiàng)可以幫助我們快速翻譯虛擬地址:

          圖 5 - TLB

          更大的內(nèi)存頁(yè)面意味著更高的緩存命中率,因?yàn)?TLB 緩存的容量是一定的,它只能緩存指定數(shù)量的頁(yè)面,在這種情況下,緩存 2MB 的大頁(yè)能夠?yàn)橄到y(tǒng)提高緩存的命中率,從而提高系統(tǒng)的整體性能。

          除了較少頁(yè)表項(xiàng)和提高緩存命中率之外,使用更大的頁(yè)面還可以提高內(nèi)存的訪問(wèn)效率,對(duì)于相同的 1GB 內(nèi)存,使用 4KB 的內(nèi)存頁(yè)需要系統(tǒng)處理 262,144 次,但是使用 2MB 的大頁(yè)卻只需要 512 次,這可以將系統(tǒng)獲取內(nèi)存所需要的處理次數(shù)降低幾個(gè)數(shù)量級(jí)。

          鎖定內(nèi)存

          使用 HugePages 可以鎖定內(nèi)存,禁止操作系統(tǒng)的內(nèi)存交換和釋放。Linux 系統(tǒng)提供了交換分區(qū)(Swap)機(jī)制,該機(jī)制會(huì)在內(nèi)存不足時(shí)將一部分內(nèi)存頁(yè)從內(nèi)存拷貝到磁盤(pán)上,釋放內(nèi)存頁(yè)占用的內(nèi)存空間,而當(dāng)對(duì)應(yīng)的內(nèi)存進(jìn)程訪問(wèn)時(shí)又會(huì)被交換到內(nèi)存中,這種機(jī)制能夠?yàn)檫M(jìn)程構(gòu)造一種內(nèi)存充足的假象,但是也會(huì)造成各種問(wèn)題。

          圖 6 - 交換分區(qū)

          我們?cè)?為什么 NUMA 會(huì)影響程序的延遲 一文中就介紹過(guò) Swap 在開(kāi)啟 NUMA 時(shí)可能會(huì)影響數(shù)據(jù)庫(kù)的性能[^5],系統(tǒng)中偶然發(fā)生的 Swap 并不是不可以接受的,但是頻繁地讀寫(xiě)磁盤(pán)會(huì)顯著地降低操作系統(tǒng)的運(yùn)行速度。

          HugePages 與其他內(nèi)存頁(yè)不同,它是由系統(tǒng)工程師預(yù)先在操作系統(tǒng)上使用命令分配的,當(dāng)進(jìn)程通過(guò) mmap 或者其他系統(tǒng)調(diào)用申請(qǐng)大頁(yè)時(shí),它們得到的都是預(yù)先分配的資源。Linux 中的 HugePages 都被鎖定在內(nèi)存中,所以哪怕是在系統(tǒng)內(nèi)存不足時(shí),它們也不會(huì)被 Swap 到磁盤(pán)上,這也就能從根源上杜絕了重要內(nèi)存被頻繁換入和換出的可能[^6]。

          REHL 6 引入了透明大頁(yè)(Transparent Huge Pages、THP),它是一個(gè)可以自動(dòng)創(chuàng)建、管理和使用大頁(yè)的抽象層,能夠?yàn)橄到y(tǒng)管理員和開(kāi)發(fā)者隱藏了大頁(yè)使用時(shí)的復(fù)雜性,但是不推薦在數(shù)據(jù)庫(kù)以及類(lèi)似負(fù)載中開(kāi)啟。[^7]

          總結(jié)

          隨著單機(jī)內(nèi)存越來(lái)越大、服務(wù)消耗的內(nèi)存越來(lái)越多,Linux 和其他操作系統(tǒng)都引入了類(lèi)似 HugePages 的功能,該功能可以從以下兩個(gè)方面提升數(shù)據(jù)庫(kù)等占用大量?jī)?nèi)存的服務(wù)的性能:

          • HugePages 可以降低內(nèi)存頁(yè)面的管理開(kāi)銷(xiāo),它可以減少進(jìn)程中的頁(yè)表項(xiàng)、提高 TLB 緩存的命中率和內(nèi)存的訪問(wèn)效率;
          • HugePages 可以鎖定內(nèi)存,禁止操作系統(tǒng)的內(nèi)存交換和釋放,不會(huì)被交換到磁盤(pán)上為其它請(qǐng)求讓出內(nèi)存;

          雖然 HugePages 的管理相對(duì)比較復(fù)雜,需要系統(tǒng)管理員額外做出特定的配置,但是對(duì)于特定類(lèi)型的工作負(fù)載,它確定能夠起到降低管理開(kāi)銷(xiāo)和鎖定內(nèi)存的作用,從而提高系統(tǒng)的性能。到最后,我們還是來(lái)看一些比較開(kāi)放的相關(guān)問(wèn)題,有興趣的讀者可以仔細(xì)思考一下下面的問(wèn)題:

          • 透明大頁(yè)(Transparent Huge Pages、THP)可能會(huì)造成哪些問(wèn)題?
          • 手動(dòng)管理系統(tǒng)中的 HugePages 有哪些優(yōu)點(diǎn)?

          如果對(duì)文章中的內(nèi)容有疑問(wèn)或者想要了解更多軟件工程上一些設(shè)計(jì)決策背后的原因,可以在博客下面留言,作者會(huì)及時(shí)回復(fù)本文相關(guān)的疑問(wèn)并選擇其中合適的主題作為后續(xù)的內(nèi)容。

          -關(guān)注我

          推薦閱讀

          TCP/IP的底層隊(duì)列

          基于Redis和Lua的分布式限流

          AbstractQueuedSynchronizer超詳細(xì)原理解析


          瀏覽 79
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          評(píng)論
          圖片
          表情
          推薦
          點(diǎn)贊
          評(píng)論
          收藏
          分享

          手機(jī)掃一掃分享

          分享
          舉報(bào)
          <kbd id="afajh"><form id="afajh"></form></kbd>
          <strong id="afajh"><dl id="afajh"></dl></strong>
            <del id="afajh"><form id="afajh"></form></del>
                1. <th id="afajh"><progress id="afajh"></progress></th>
                  <b id="afajh"><abbr id="afajh"></abbr></b>
                  <th id="afajh"><progress id="afajh"></progress></th>
                  高清无码免费在线 | 免费成人一级片 | 国产亚洲在线观看 | 黃色A片一级一级一级久别的草原 | 波多野结衣无码AⅤ一区t二区三区 |