小蘇的世界

http://openvz.org/UBC_secondary_parameters

有關UBC的次要參數說明，

在此將它中文白化一下，僅供各位參考用，同時也給自己做個記錄

因為牽扯太多作業系統的觀念了，如果有誤，也請各位包函~

UBC secondary parameters有七個，分別為 kmemsize、tcpsndbuf、tcprcvbuf、othersockbuf、dgramrcvbuf、oomguarpages、privvmpages

次要UBC參數是直接連接到主要參數的，同時也不可以隨意設定。

 @kmemsize

作業系統核心配置的不可交換記憶體區(unswappable memory)，以 Bytes 計算。

核心內部資料結構(kernel internal data)用來處理容器程序，此不包含網路暫存空間，這些資料結構存放於電腦的第一個 GB 的記憶體當中，稱為「low memory」區域。

x86 的 low_memory 區域通常位於 832MB 之前，可被核心直接存取，x64 無 low_memory 區，因為 x64 的核心可以存取任的記憶體區域。

然後這個參數與另一個參數 numproc 相關聯，每個程序消耗了一定量的核心記憶體，

通常為 24KB~60KB 不等，甚至更大的程序則需要更多的核心記憶體。

有一個安全的間隔值(10%)在 kmemsize 的 barrier 與 limit 間是重要的。

kmemsize 的 barrier 與 limit 設定值相同的話，可能會引發作業系核心刪除容器的程序以確保用量在 limit 規範之下。

kmemsize 值無法設定太高，因為包含全部 containers 的 kmemsize、再加上 socket 的暫存空間，都必需受限在作業系統硬體可以取用的資源。

 @tcpsndbuf

用來傳送 TCP 連線資料所使用的緩衝區大小，這緩衝區也位於 low memory 區域。

該參數與另一個參數 numtcpsock 有相依性，得替每一個 socket 配置最小量的緩衝空間。

如果無法滿足以上限制，某些網路連線可能會停滯，而無法傳送資料。

設定過高的 tcpsndbuf 非必要，不一定會增加網路通訊(network communications)的效能。

tcpsndbuf 到達 limits 時，不會對應用程式造成過大的負面影響，只會降低網路通訊的效能。

tcpsndbuf 值無法設定太高，因為包含全部 containers 的 tcpsndbuff、 kmemsize、其它 socket 的暫存空間，都必需受限在作業系統硬體可以取用的資源。

 @tcprcvbuf

用來暫存接收所有來自 TCP 網路連線所需要的總緩衝空間，這緩衝區也位於 low memory 區域。

該參數與另一個參數 numtcpsock 有相依性，得替每一個 socket 配置最小量的緩衝空間。

如果無法滿足以上限制，某些網路連線可能會停滯，而無法接受資料，數分鐘後連線就會中斷。

與 tcpsndbuf 相同，tcprcvbuf 設定過高非必要，不一定會增加網路通訊)的效能，tcprcvbuf 到達 limits 時，不會對應用程式造成過大的負面影響，只會降低網路通訊的效能。

如果 tcprcvbuf 到達 barrier 值的時間太長所受到的傷害會比 tcpsndbuf 少，長時間超過 barrier 可能會造成某些連線終止。

tcprcvbuf 值無法設定太高，包含全部 containers 的 tcprcvbuff、 kmemsize、其它 socket 的暫存空間，都必需受限在作業系統硬體可以取用的資源。

 @othersockbuf

用於系統內部程序間(between processes)本地(Unix-Domain)連線(如連接本地端資料庫伺服器)，傳送 UDP 還有其它 datagram 協定的緩衝區大小。

該參數與另一個參數 numothersock 有相依性，設定必需滿足以下：

為了提高內部(Unix-Domain)通訊的效能，增加 othersockbuf 的 limits 是必要的。

與 tcpsndbuf 相同的是，othersockbuf 到達 limits 時，只會降低網路通訊的效能，而不會影響功能。

othersockbuf值無法設定太高，包含全部 containers 的 othersockbuf、kmemsize、其它 socket 的暫存空間，都必需受限在作業系統硬體可以取用的資源。

 @dgramrcvbuf

用來接收 UDP 還有其它 datagram 協定的緩衝區大小。

該參數與另一個參數 numothersock 有相依性，dgramrcvbuf 的 limits 通常不需要太高，假如容器需要傳送接收非常大的 datagrams 的話，othersockbuf 和dgramrcvbuf 的 barrier 都必需要提高。

不像其它的 socket buffer參數，dgramrcvbuf 的 barrier 必需設定成 limit。

dgramrcvbuf 值無法設定太高，包含全部 containers 的 dgramrcvbuf、kmemsize、其它 socket 的暫存空間，都必需受限在作業系統硬體可以取用的資源。

 @oomguarpages

保證可得多少記憶體當記憶體用完時(Out-Of-Memory kill guarantee)，oomguarpages 與 vmguarpages 有關聯。

當應用程式消耗了電腦有的記憶體後，系統會進入記憶體用完的狀態(Out-Of-Memory condition)，作業系統會開始殺掉容器(containers)的程序以得到更多可用的記憶體空間，以避免系統本身的死亡。雖然在一般的系統負載下，這種情況很少發生。但當記憶體空間用完的時後，刪除程序卻是作業系統一般的反應。

oomguarpages參數計算(accounts)了特定容器程序所使用的總記憶體量和交換空間，barrier值則是 OOM 的保證。

當 OOM 發生時，如果 oomguarpages 加上kmemsize、socket buffer 用量低於 barrier 設定值，系統保證不會刪除該容器裡的程序。若系統 OOM 發生時，有多個容器 oomguarpages 的用量超出了設定值，則容器裡超出最多的應用程序將會先被殺掉，同時 failcnt 的值會增加。

如果管理者需要確保應用程式不會被強制刪除，將 privvmpages 的 limits 設定不要超過 oomguarpages，則能顯著的降低被刪除的可能性，設定成1/2的話，則能完全避免發生。但這樣子的配置是不受歡迎的，因這樣會顯著的降低硬體的使用率。

oomguarpages 的 limits 值在目前的版本中的意義是不明的。

所有 containers 的 oomguarpages 的總和不應該超出電腦的實體容量，否則當 OOM 發生時，容器裡一些保證層級的服務或系統服務(system daemons)可能會被刪除。

@privvmpages

記憶體配置限制，單位 pages (通常指 4096 Bytes)。

privvmpages 參數可以控制應用程式分配的記憶體總量。

privvmpages 參數的 barrier 與 limits 值控制了分配記憶體總大小的上邊界，但這上邊界不保證容器可以分配到多少記體，也不保證其它的容器可以公平分配共享記憶體，最主要的控制機制還是在 vmgurapages。

privvmpages 統計了記憶體配置的情況(但可能未使用中)。統計出來的值是估算應用程式啟動時實際上會消耗的記憶體，而實際上會消耗的記憶體是被統計在 oomguarpages 裡的。

privvmpages 統計的記憶體用量也許不是實際使用的，而所有容器的 privvmpages 值總和可能會超過電腦的記憶體和交換區(swap)的大小。

應該要有一個安全的區間在 privvmpages 的 barrier 與 limits 值之間，用來降低記憶體分配失敗的次數。這個區間將會被用來處理「高優先權」的記憶體配置，像是stack expansion，一般優先權的記憶體配置在 privvmpages 到達 barrier 值就會失敗了。

總 privvmpages 值應與電腦的實體資源相關。更重要是，不允許任何容器配置了資源的極大部分，而降級了其它容器服務的程度。

所有的次要參數都與記憶體有關，與記憶體有關的參數限制總額不能超出電腦實體的資源。相關的限制請參考 UBC systemwide configuration，這些限制非常重要，如果違反，可能因任何容器而卡住了整個系統。