共計 3735 個字符，預計需要花費 10 分鐘才能閱讀完成。
LVS 系統優化的注意事項有什么，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面丸趣 TV 小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。
Linux 環境
CentOS 5.5
名詞
LVS : Linux Virtual Server
IPVS : IP Virtual Server，IPVS 是 LVS 實現的關鍵。
IPVS connection hash table : IPVS 連接哈希表，用來“跟蹤”進來、出去的網絡包（for input and output packets lookups of IPVS)。
ip_vs_conn 結構體：定義在內核檔 include/net/ip_vs.h 中。該結構體（對象）是 IPVS 的調度對象。在 32 位系統上 128 字節，64 位系統上 192 字節。
IPVS connection hash table
內核中的代碼：net/netfilter/ipvs/ip_vs_conn.c
int ip_vs_conn_tab_bits;
編譯時可以定，Kconfig 文件中說明該值的大小應該在 8 到 20 之間。當 ip_vs_conn_tab_bits=20 時，哈希表的的大小（條目）為 pow(2,20)，即 1048576，約 104 萬，足夠用了。
int ip_vs_conn_tab_size;
IPVS 哈希連接表的條目數（list_head 結構數）。
ip_vs_conn_tab_size = 1 ip_vs_conn_tab_bits;
哈希表的大小（條目數）是 2 的 ip_vs_conn_tab_bits 次方。
ip_vs_conn_tab = vmalloc(ip_vs_conn_tab_size * sizeof(struct list_head));
其中 IPVS 連接哈希表占用的內存大小是 ip_vs_conn_tab_size * sizeof(struct list_head)
內核 Kconfig 文件中說一個哈希條目點用 8 個字節，但是實示上，一個條目占用的內存大小是和 list_head 結構體的大小相關，（可能）在 32 位的內核里是 8 個字節，64 位的內核里是 16 個字節。當加載 ip_vs 模塊的時候，使用 dmesg 可以看到具體的信息：
在 32 位系統上
IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=32Kbytes)
IPVS: ipvs loaded.
在 64 位的系統上：
IPVS: Registered protocols (TCP, UDP, AH, ESP)
IPVS: Connection hash table configured (size=4096, memory=64Kbytes)
IPVS: ipvs loaded.
哈希沖突，是哈希算法的致命傷。“IPVS”使用“鏈表策略”(chaining scheme) 解決哈希沖突。當有大量的連接時，一個大的“IPVS 連接哈希表”將大大減少沖突。減少了沖突，意為著 IPVS 定位 ip_vs_conn 對象的速度更快。
下圖示意了哈希表（Hash Table）這種數據結構。引用
如上圖所示，首先分配一個指針數組，數組的每個元素是一個鏈表的頭指針，每個鏈表稱為一個槽（Slot）。哪個數據應該放入哪個槽中由哈希函數決定，在這個例子中我們簡單地選取哈希函數 h(x) = x % 11，這樣任意數據 x 都可以映射成 0~10 之間的一個數，就是槽的編號，將數據放入某個槽的操作就是鏈表的插入操作。
如果每個槽里至多只有一個數據，可以想像這種情況下 search、insert 和 delete 操作的時間復雜度都是 O(1)，但有時會有多個數據被哈希函數映射到同一個槽中，這稱為碰撞（Collision），設計一個好的哈希函數可以把數據比較均勻地分布到各個槽中，盡量避免碰撞。如果能把 n 個數據比較均勻地分布到 m 個槽中，每個糟里約有 n / m 個數據，則 search、insert 和 delete 和操作的時間復雜度都是 O(n/m)，如果 n 和 m 的比是常數，則時間復雜度仍然是 O(1)。一般來說，要處理的數據越多，構造哈希表時分配的槽也應該越多，所以 n 和 m 成正比這個假設是成立的。
關聯到 IPVS，ip_vs_conn_tab_size 指的就是“槽”的數量。N 指的應該是所有的調度對象 struct ip_vs_conn 的數量。
確定 ip_vs_conn_tab_bits 的 *** 值：
假如你的 LVS 上每秒有 W 個“連接”建立，平均每個“連接”將要保持 S 秒，即每個連接工作 S 秒，*** ip_vs_conn_tab_bits 值應該滿足 2 的 ip_vs_conn_tab_bits 次方靠近 W*S。*** 的 ip_vs_conn_tab_bits = log(W*S,2).
還有一個容易的方法：
使用 slabtop 觀察 ip_vs_conn 結構的數量（OBJS），當然，應該是在系統流量 *** 的時候取得這個值，對該值求以 2 為底 的對數，log(OBJS,2)。
獲取 ip_vs_conn OBJS 的值：awk lsquo;/ip_vs_conn/{print $3} rsquo; /proc/slabinfo
這個 *** 值，以我理解，就是上面“哈希表”結構說明中提到的 M 值，而 OBJS 就是 N 值，當 M 接近 N 的時候，哈希表的復制度為 O(1)，為 *** 狀態。
使我不解的是，這里為什么不設置的更大一些，僅僅是浪費一些內存而且（一個條目用去 8 或者 16 個字節）。即使取 *** 值 20, 在 64 位內核上，也才只占去 16M 的內存，在 32 位的內核上，占去 8M 內存。
IPVS 的默認值是 12，32 位機用掉 32K，64 位機用掉 64K 內存。假如不是因為小內存容易使用 CPU 緩存，那么就一定是為了節省內存，在服務器上，這樣的策略，明顯落后了。
問題的關鍵是查明 vmalloc() 函數的作用。
vmalloc() 函數的作用：
申請邏輯地址連續的內存，返回首內存地址。
看來 IPVS 連接哈希表的大小，與使用的內存（是高速緩存，還是普通內存）并無影響。
調整 ip_vs_conn_tab_bits 的方法：
新的 IPVS 代碼，允許調整 ip_vs_conn_bits 的值。而老的 IPVS 代碼則需要通過重新編譯來調整。
在發行版里，IPVS 通常是以模塊的形式編譯的。
確認能否調整使用命令 modinfo -p ip_vs（查看 ip_vs 模塊的參數），看有沒有 conn_tab_bits 參數可用。假如可以用，那么說時可以調整，調整方法是加載時通過設置 conn_tab_bits 參數：
在 /etc/modprobe.conf 添加下面一行
options ip_vs conn_tab_bits=20
假如沒有 conn_tab_bits 參數可用，則需要重新調整編譯選項，重新編譯。
很不幸，即使將 CentOS 內核升級到 *** 版，也不支持這個參數，只能自定義編譯了（沒有編譯成功，很郁悶）。
另外，假如 IPVS 支持調整 ip_vs_conn_tab_bits，而又將 IPVS 集成進了內核，那么只能通過重啟，向內核傳遞參數來調整了。在引導程序的 kernel 相關的配置行上，添加：ip_vs.conn_tab_bits=20，然后，重啟。
最終建意：
增大哈希表，調到 ip_vs_conn_tab_bits 到 20。有一種說法是哈希表過大，會影響性能。但是根據我對哈希算法的理解，這種說法沒有道理。
另一個有力的證據是，IPVS 的作者也是這樣配置的。
Network
增加 LVS 主機的網絡吞吐能力，有利于提高 LVS 的處理速度和能力。
1. 使用更快的網卡，比如使用千兆、萬兆的網卡。
2. 可以進一步將兩塊或多塊網卡綁定（多塊網卡的綁定有待驗證），bonding 時 mode=0（balance-rr）或者 mode=4（802.3ad，需要交換機支持聚合端口），miimon=80 或者 miimon=100（毫秒）。
TCP/IP
/etc/sysctl.conf
net.core.netdev_max_backlog = 60000
Hardware
IPVS 的運行，使用的服務器資源主要是 CPU、內存 I /O、網絡 I /O；IPVS 完全運行在內存中，并且運行在內核態。
當 IPVS 的應用在 DR 模式時，即不耗 CPU，也不耗 I /O，運行非常快，所以系統負載非常的低，跟據我的經驗，一般負載總是 0。所以 LVS 應用對服務器的配置要求非常低。以為 LVS 很重要，所以配置一個相當高端的服務器，實在是一種浪費。
其實我們可以做一下計算：
以 64 位系統為例，一個哈希表條目，16 個字節，一個 ip_vs_conn 結構 192 字節。以哈希表的沖突盡可能的少為場景（將 ip_vs_conn_tab_bits 設置為 *** 值 20），那么：
pow(2,20)=1048576
pow(2,20)*(16+192)/1024/1024 = 208 M
就是說，當系統當前有 100 萬連接的時候，才用去內存 208 M，所以 IPVS 的主機，即使是 1G 的內存，也足以承載負載。
看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注丸趣 TV 行業資訊頻道，感謝您對丸趣 TV 的支持。
