編者按:本文對大流量、高負載LVS系統優化提供了參考意見,從IPVS、網卡、TCP/IP配置、硬件資源配置等方面進行了闡述。文章重點關注了IPVS connection hash table的參數計算過程。算法
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 字節。ide
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 ‘/ip_vs_conn/{print $3}’ /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的內存,也足以承載負載。
轉自:http://hi.baidu.com/imfam520/item/50727b123187750ee65c36a2