我們叢集中有幾台伺服器，我們想知道一般在哪些情況下我們需要配置大頁面？
我也有幾個問題
- 「記憶體頁面大小」是否等於大頁面？
在我的 Linux 伺服器中，我輸入以下命令來驗證預設記憶體頁面大小
grep Hugepagesize /proc/meminfo
Hugepagesize: 2048 kB
getconf PAGESIZE
4096
但如大家所見，我們得到了不同的結果，為什麼？
使用大頁面有哪些風險？
劑量禁用透明大頁 - 意味著禁用大頁選項？
答案1
當應用程式需要對其進行隨機存取的大型映射時，大頁會很有趣，因為這對於轉換後備緩衝區 (TLB) 來說是最糟糕的情況。您可以權衡 TLB 條目的映射粒度。
頁（包括大頁）只能對應到相同大小的實體記憶體區塊，並與該大小對齊。因此，2 MB 的大頁面需要映射到實體 RAM 中的 2 MB 邊界，而 1 GB 的大頁面需要映射到 1 GB 邊界，因為低位元尋址的是頁面內部的數據，這裡不能添加偏移量。
這意味著大頁通常在系統啟動時保留，此時實體記憶體尚未碎片化。支援大頁的應用程式可以用來hugetlbfs分配它們。
您必須使用核心參數來決定大頁的大小應為 2MB 還是 1GB，不能混合使用。普通 4kB 頁面始終可用。
最常見的用例是虛擬機器（qemu/kvm 可以使用大頁），這允許將 VM 的整個記憶體映射保留在少量 TLB 條目中，因此永遠不會被驅逐，因此 VM 內的記憶體存取需要一個頁面僅在來賓上下文內進行表格查找。
某些資料庫系統也支援大頁，但這通常僅在您使用大型資料集和索引時才有用。
問題：
有普通（4kB）頁面和巨大（2MB 或 1GB）頁面。當您查詢頁面大小時，您將獲得普通頁面的大小，當您查詢大頁面大小時，您將獲得大頁面的設定。普通頁和大頁都可以並行使用，但不能混合使用不同的大頁大小。
你會得到不同的結果，因為這是兩件不同的事。普通頁面的大小是在硬體中固定的，因此它不是一個設定。
大頁面需要儘早分配，雖然內存在技術上是“空閒”的，但除了大頁面感知應用程序之外，它不能用於任何其他應用程序，因此除了這些應用程序之外的所有應用程序都將具有更少的可用記憶體。這通常不是問題，因為您會在專用於記憶體密集型應用程式（例如虛擬機器或資料庫）的電腦上使用大頁面。
透明大頁嘗試將內存用作緩衝區和緩存（與#3 相反），並嘗試將大頁提供給映射大內存塊的應用程序，因此不了解大頁的應用程序仍然可以從中受益- 基本上是一個應用程式如果可能的話，請求 2MB/1GB 記憶體區塊將被給予一個大頁面。這是否有助於或損害效能取決於您的應用程式。如果您有一個支援大頁的應用程式並且想要手動分配內存，則需要停用 THP，而具有不支援大頁的資料庫應用程式的系統可能會受益。
答案2
大頁面的明顯用例是當 PageTables（在 /proc/meminfo 中可見）達到數十 GB 時。這意味著僅追蹤記憶體就會產生大量記憶體和 CPU 開銷。它發生在巨大的記憶體區塊、大量的進程或兩者兼而有之的情況下。經常出現在資料庫應用程式中。
大頁面顯著減少了開銷，因為單個頁表條目現在可以處理更多的內存，例如 2,048 KB 而不是 4 KB。 （其他平台上有不同的大小，例如 AIX on POWER 支援 16 MB 大頁面。）
Linux 上的大頁面可能無法用於檔案緩存，對於非共享記憶體的 malloc() 來說，這會很煩人且效率低下。因此管理員必須指派只能用於某些目的的巨大頁面池。這是使用大頁面的缺點。
透明大頁面 (THP) 試圖透過自動將連續記憶體「碎片整理」為大頁面來減少管理的麻煩。這個想法是這使得預先分配的大頁面成為可選的。好處與工作負載高度相關，可能會花費太多 CPU 而不值得。停用 THP 意味著您仍然可以手動分配大頁面。有時，關閉 THP 並將資料庫的共享記憶體段放入大頁中是值得的。
關於 Linux 大頁面的最後一個抱怨是：我發現管理它很煩人。
- 共享記憶體使用一個接口，但對於其他接口，您使用一個hugetlbfs庫和檔案系統。
- 您可以透過分配過多的大頁面而不配置應用程式來使用它來「浪費」記憶體。
- 該頁面數量必須根據每個主機大小進行縮放，因為它是頁面計數而不是記憶體百分比。
- 通常，分配大頁面的能力僅限於一組，切換資料庫使用者可能會導致意外的記憶體浪費。