文章的翻譯是在課程開始前夕準備的 .
定期地，在這里和那裡，會出現關於 Gluster 關於內核調整的建議以及是否需要這樣做的問題。
這種需求很少出現。 在大多數工作負載上，內核的性能都非常好。 雖然有一個缺點。 從歷史上看，如果有機會，Linux 內核一直願意消耗大量內存，包括將緩存作為提高性能的主要方式。
在大多數情況下，這工作正常，但在重負載下可能會導致問題。
我們對 CAD、EDA 等內存密集型系統有很多經驗，這些系統在重負載下開始變慢。 有時我們會在 Gluster 中遇到問題。 仔細觀察了多天的內存使用和磁盤延遲，我們得到了它們的過載、巨大的iowait、內核錯誤（kernel oops）、凍結等。
本文是在各種情況下進行的許多調優實驗的結果。 由於這些參數，不僅整體響應能力有所提高，而且集群也顯著穩定。
說到內存調優，首先要看的是虛擬內存子系統（VM，virtual memory），它有大量的選項，會讓你一頭霧水。
虛擬機交換性
參數 vm.swappiness 確定內核與 RAM 相比使用多少交換（swap，paging）。 它在源代碼中也被定義為“竊取映射內存的傾向”。 高 swappiness 意味著內核將更傾向於交換映射頁面。 低 swappiness 值意味著相反：內核將從內存中減少分頁。 換句話說，價值越高 vm.swappiness，系統將使用交換越多。
大量使用交換是不可取的，因為巨大的數據塊被加載和卸載到 RAM 中。 許多人認為 swapiness 值應該很大，但根據我的經驗，將其設置為“0”會帶來更好的性能。
你可以在這裡閱讀更多 -
但是，同樣，應謹慎應用這些設置，並且只能在測試特定應用程序之後使用。 對於高負載流式應用程序，此參數應設置為“0”。 當更改為“0”時，系統響應性會提高。
vm.vfs_cache_壓
此設置控制內核用於緩存目錄和 inode 對象（dentry 和 inode）所消耗的內存。
默認值為 100，內核將嘗試在“公平”的基礎上將 dentry 和 inode 緩存釋放給 pagecache 和 swapcache。 降低 vfs_cache_pressure 會導致內核保留 dentry 和 inode 緩存。 當該值為“0”時，由於內存壓力，內核永遠不會刷新dentry和inode緩存，這很容易導致內存不足的錯誤。 將 vfs_cache_pressure 增加到 100 以上會導致內核優先刷新 dentry 和 inode。
使用 GlusterFS 時，由於 inode/dentry 緩存，許多擁有大量數據和許多小文件的用戶可以輕鬆使用服務器上的大量 RAM，這可能導致性能下降，因為內核必須處理系統上的數據結構具有 40 GB 的內存。 將此值設置為 100 以上已幫助許多用戶實現更公平的緩存和改進的內核響應能力。
vm.dirty_background_ratio 和 vm.dirty_ratio
第一個參數 (vm.dirty_background_ratio) 確定臟頁內存的百分比，達到後有必要開始在後台將臟頁刷新到磁盤。 在達到此百分比之前，不會將任何頁面刷新到磁盤。 當重置開始時，它會在後台運行而不會中斷正在運行的進程。
第二個參數（vm.dirty_ratio) 定義在強制閃存開始之前臟頁可以佔用的內存百分比。 一旦達到這個閾值，所有進程都變成同步的（阻塞的）並且不允許繼續，直到它們請求的 I/O 實際完成並且數據在磁盤上。 對於繁重的 I/O，這會導致問題，因為沒有數據緩存，並且所有執行 I/O 的進程都被阻塞以等待 I/O。 導致大量hung進程，負載高，系統不穩定，性能差。
減少這些設置會導致數據更頻繁地刷新到磁盤而不是存儲在 RAM 中。 這可以幫助內存密集型系統，在這些系統中通常會將 45-90 GB 頁面緩存刷新到磁盤，從而導致前端應用程序出現巨大延遲，從而降低整體響應性和交互性。
“1” > /proc/sys/vm/pagecache
頁面緩存是存儲文件和可執行程序數據的緩存，也就是說，這些是具有文件或塊設備實際內容的頁面。 此緩存用於減少磁盤讀取次數。 值“1”表示 1% 的 RAM 用於緩存，從磁盤讀取的次數將多於從 RAM 讀取的次數。 沒有必要更改此設置，但如果您對控制頁面緩存偏執狂，則可以使用它。
“截止日期” > /sys/block/sdc/queue/scheduler
I/O 調度器是一個處理讀寫隊列的 Linux 內核組件。 從理論上講，智能 RAID 控制器最好使用“noop”，因為 Linux 對磁盤的物理幾何結構一無所知，因此讓熟悉磁盤幾何結構的控制器盡可能快地處理請求會更有效率。可能的。 但看起來“截止日期”提高了性能。 您可以在 Linux 內核源代碼文檔中閱讀有關調度程序的更多信息： linux/Documentation/block/*osched.txt. 而且我還看到在混合操作（許多寫操作）期間讀取吞吐量有所增加。
“256” > /sys/block/sdc/queue/nr_requests
緩衝區中的 I/O 請求在傳遞給調度程序之前的數量。 某些控制器的內部隊列大小 (queue_depth) 大於 I/O 調度程序的 nr_requests，因此 I/O 調度程序幾乎沒有機會正確排列請求的優先級和合併請求。 對於 deadline 和 CFQ 調度器，當 nr_requests 是控制器內部隊列的 2 倍時會更好。 合併和重新排序請求有助於調度程序在重負載下響應更快。
echo "16" > /proc/sys/vm/page-cluster
page-cluster 參數控制一次寫入交換的頁數。 在上面的示例中，根據 16 KB 的 RAID 條帶大小將值設置為“64”。 swappiness = 0 沒有意義，但是如果您將 swappiness 設置為 10 或 20，那麼當 RAID 條帶大小為 64K 時，使用此值將對您有所幫助。
區塊開發 --setra 4096 /dev/<開發名稱> （-sdb、hdc 或 dev_mapper）
許多 RAID 控制器的默認塊設備設置通常會導致糟糕的性能。 添加上述選項可設置 4096 * 512 字節扇區的預讀。 至少，對於流式操作，通過在內核准備 I/O 期間使用預讀填充片上磁盤緩存來提高速度。 緩存可以包含將在下一次讀取時請求的數據。 過多的預取可能會導致大文件的隨機 I/O 失效，如果它耗盡了可能有用的磁盤時間或將數據加載到緩存之外。
以下是文件系統級別的更多建議。 但他們還沒有經過測試。 確保您的文件系統知道條帶的大小和陣列中的磁盤數量。 例如，這是一個 5K 條帶 raid64 陣列，有六個磁盤（實際上是五個，因為一個磁盤用於奇偶校驗）。 這些建議基於理論假設，並由 RAID 專家從各種博客/文章中彙編而成。
-> ext4 fs, 5 disks, 64K stripe, units in 4K blocks
mkfs -text4 -E stride=$((64/4))
-> xfs, 5 disks, 64K stripe, units in 512-byte sectors
mkfs -txfs -d sunit=$((64*2)) -d swidth=$((5*64*2))對於大文件，請考慮增加上面列出的條帶大小。
警告！ 對於某些類型的應用程序，上面描述的一切都是非常主觀的。 未經用戶事先對相關應用程序進行測試，本文不保證任何改進。 僅當有必要提高系統的整體響應能力或解決當前問題時才應使用它。
其他材料：
閱讀更多
來源： www.habr.com