onconfig中對CPU 記憶體的利用率影響的引數

Online 配置檔案onconfig中的下列引數對CPU的利用率有明顯的影響

• NUMCPUVPS 

• SINGLE_CPU_VP 

• MULTIPROCESSOR 

• AFF_NPROCS 

• AFF_SPROC 

• NUMAIOVPS 

• OPTCOMPAND 

• NETTYPE 

NUMCPUVPS、MULTIPROCESSOR和SINGL_CPU_VP

NUMCPUVPS引數規定了Online 開始啟動的CPU VP的數量。分配的CPU VP的個數不要超過可以為它們服務的CPU的個數。 

• 對於單處理器的計算機系統，Informix 建議使用一個CPU VP。 

• 對於有4個以上CPU，主要用做資料庫伺服器的多處理器系統，Informix 建議設定NUMCPUVPS的值等於處理器總數減一。 

• 對於雙處理器系統，執行兩個CPU VP可能會改善效能。這需要監控作業系統的CPU使用情況。可以使用作業系統命令sar 或 vmstat。    

如果執行多個CPU VP，應將MULTIPROCESSOR 設定為1，當設定MULTIPROCESSOR為1時， Online 以對應於多處理器的方式執行鎖定。否則，設定該引數為0。 

注意：如果設定SINGLE_CPU_VP引數為，則NUMCPUVPS 引數的值也必須是1，如果後者大於1，Online就不能初始化並顯示下面的錯誤資訊： Cannot have 'SINGLE_CPU_VP' now-zero and 'NUMCPUVPS' greater than 1 

AFF_NPROCS 和 AFF_SPROC

在支援Online和客戶應用的系統上，可以透過作業系統把應用連線到某些特定的CPU。這樣做可以有效地保留剩餘的CPU給Online CPU VP使用，它們是用AFF--NPROCES和AFF_SPROC配置引數連線到剩餘CPU的。

AFF_NPROCS指定了連線到Online的CPU VP上的CPU的個數。連線一個CPU VP到一個CPU 會引起該CPU VP在這個CPU上的排它性執行。AFF_SPROC指定了Online把CPU VP連線到CPU上時所啟動的CPU。

AFF_NPROCS規定了計算機上可以幫定CPU VP的CPU的數目。NUMCPUVPS引數指定了 Online將啟動的CPU VP的數目，AFF_SPROC引數指定了Online連線第一個CPU序號。例如，某個Online 系統所在的硬體平臺有8個CPU，AFF_NPROCS設定為8（即可用於幫定CPU VP的CPU有8個），NUMCPUVPS設定為3，AFF_SPROC設定為5，則3個CPU VP需要幫定到CPU上，是從第五個CPU開始，幫定到第五、六、七個CPU上。需要注意的是，AFF_SPROC的取值是在0和（AFF_NPROCS - NUMCPUVPS + 1)這兩個值之間的，不能大於後者。

NUMAIOVPS

引數NUMAIOVPS指定最初產生的AIO VP的數目。如果所在的作業系統不支援核心非同步I/O（KAIO），Online使用AIP VP來處理所有資料庫I/O請求。

推薦的AIP VP數目取決於Online 使用的硬碟個數。如果所在作業系統不支援或沒有使用KAIO，則Informix建議對包含資料庫表的每一個磁碟分配一個AIO VP。可以對Online 頻繁訪問的每六塊增加額外的AIO VP。如果所在的作業系統使用KAIO VP，CPU VP將直接向作業系統發出原始的I/O請求。在這種情況下，可以只配置一個AIO VP，此時AIO VP只處理檔案系統方式的chunk。如果檔案系統方式的chunk有增加時，可以增大AIO VP的數目。

分配AIO VP的目的是要分配足夠的AIO VP以便I/O請求佇列的長度保持很短，即佇列中保持儘可能少的I/O請求。 

OPTCOMPIND

OPTCOMPIND引數幫助最佳化程式為應用選擇合適的訪問方法。 

• 如果OPTCOMPIND等於0，最佳化程式給予現存索引優先權，即使在表掃描比較快時。 

• 如果OPTCOMPIND設定為1，給定查詢的隔離級設定為Repeatable Read時，最佳化程式才使用索引。 

• 如果OPTCOMPIND等於2，最佳化程式選擇基於開銷選擇查詢方式。，即使表掃描可以臨時鎖定整個表。 

NETTYPE

NETTYPE引數為Online例項支援的每個連線型別配置輪詢線索。如果sqlhosts檔案中支援一個以上的介面或協議的連線，就必須對每個連線型別規定獨立的NETTYPE引數。每個與資料庫伺服器名字有關的連線型別都需要單獨指定一個NETTYPE引數。

每個用NETTYPE表項配置或動態加入的輪詢線索在不同的VP上執行，輪詢線索可以在兩類VP上執行：NET VP和CPU VP。為得到最佳效能，Informix建議使用NETTYPE表項為CPU VP類只分配一個輪詢線索，將其餘輪詢線索輪詢線索分配給NET VP。分配給任何一種連線型別的輪詢線索不得超過NUMCPUVPS的取值。

單CPU計算機上每個輪詢線索的最佳連線個數不超過300，多CPU機上可多達350個。但一個輪詢線索最多支援1，024甚至更多的連線。NETTYPE的配置格式如下：

NETTYPE connection_type，poll_threads，c_per_t，vp_class 

• connection_type 標識輪詢線索分配的連線協議。 

• poll_threads 是分配給該連線型別的輪詢線索數目。對任何連線型別，這個值不能超過NUMCPUVPS值。 

• c_per_t 是每個輪詢線索的連線數目。可以用如下公式計算這個值： 

c_per_t   = connections / poll_threads 

connections 是所希望指定的連線型別支援的最大連線數。對於共享記憶體連線（ipcshm)，該值應該加倍以獲得最好的效能。 

• vp_class 是可執行輪詢線索的VP類。如果CPU VP上只執行一個輪詢線索，那麼指定為CPU VP。為了達到最好效能，當要求多個輪詢線索時應該指定為NET VP。

如果c_per_t的值超過了350，而當前連線的輪詢線索數小於NUMCPUVPS，可以增加輪詢線索數目，但不能超過NUMCPUVPS，然後重新計算c_per_t的取值。

注意：每個ipcshm連線需要一個訊號量。當c_per_t的值很大時，對於某些作業系統要相應增加訊號量。 

如何監控系統CPU的使用情況

1. 使用UNIX的監控工具sar或vmstat來監控CPU的使用情況。例：sar   5   10 

%usr %sys %wio %idle 

10:06:22 34 1 0 65 

10:06:27 34 2 0 64 

10:06:32 34 1 0 65 

10:06:37 17 1 0 82 

10:06:47 1 1 0 98 

連續監控%idle來確認CPU沒有超載。如果%sys的值很大則可能應用有問題。

2. 監控CPU vp的方法

onstat   -g   glo 

Individual virtual processors: 

vp pid class usercpu syscpu total 

可以透過該監控看出CPU忙佔用的時間(隔60秒分別監控結果）。如果非常忙，則需要增加CPU VP。 

onstat -g rea 

Ready threads 

tid tcb rstcb prty status vp-class name 

如果有大量的線索在等待佇列中，則說明需要增加CPU VP。 

影響記憶體使用效率的Online配置引數

• SHMVIRTSIZE 

• SHMADD 

• BUFFERS 

• RESIDENT 

• STACKSIZE 

• LOCKS 

• LOGBUFF 

• PHYSBUFF 

SHMVIRSIZE

SHMVIRTSIZE引數規定了初始分配給Online的共享記憶體的虛擬區的大小。共享儲存器的虛擬區儲存與會話、請求有關的資料及其它資訊。雖然Online按處理大型查詢或高峰負荷的需要增加共享記憶體給虛擬區，但共享記憶體的分配增加事務處理的時間，Informix建議設定SHMVIRTSIZE以提供一個滿足一般日常操作需要的虛擬介面。 

SHMADD

SHMADD引數規定Online自動加到虛擬區的共享記憶體增量的大小。在決定該值的大小時有些折中因素。增加共享記憶體要佔用CPU週期：每次的增加量越大，增加次數就越少，留給其它的程式的記憶體也越少。通常採用大增加量，但當記憶體負荷很重時，少量增加使其他程式更好的共享記憶體資源。Informix 有如下建議： 

記憶體大小 SHMADD 

<=256MB 8192KB(default) 

256--512MB 16,384KB 

>=512 32,768KB 

BUFFERS

BUFFERS是可以用於Online的資料緩衝區數。這些緩衝區駐留在駐留區，用來快取主存中的資料庫的資料頁。可用的緩衝區越多，所需的資料頁就越可能用於前一次請求而已經在記憶體裡。這個引數對資料庫I/O和事務處理吞吐量有明顯的影響。但是，分配過多的緩衝區會影響記憶體系統並導致過多的頁面活動。

Informix建議設定BUFFERS為實體記憶體(以MB為單位)的20%到25%。實際BUFFERS的單位為頁，不同作業系統的頁大小是不同的，因此需要計算。使用onstat -p監控讀快取的頻率。這個頻率代表一個查詢請求的資料庫頁已經在共享記憶體裡的百分比。（還沒有存在的頁必須從磁碟複製到記憶體中）。如果此值很低，可增加BUFFERS並重新啟動Online。在增加BUFFERS值時，到達某一點後，增加BUFFERS也不再明顯改善讀快取的頻率，或者達到作業系統共享記憶體分配的上限。 如果讀快取記憶體的比率很高，則應下調BUFFERS並重啟動Online。 

RESIDENT 

RESIDENT 引數規定是否強制共享記憶體駐留作為Online共享記憶體駐留區。這個引數只對支援強制駐留的機器有效。Online中的駐留區，包含用於資料庫讀寫作業的LRU佇列。 

LOCKS 

引數LOCKS設定任意時刻可用的鎖的最大數量。Online中每個鎖需要佔用駐留區段的44個位元組，分配共享記憶體時要考慮鎖所用的資源。一般鎖可以分配的大些，對應用比較忙的系統可以到800萬以上。 

LOGBUFF 

引數LOGBUFF指定為三個用來儲存邏輯日誌記錄的緩衝區分別保留的共享記憶體的數量。這些緩衝區儲存著邏輯日誌記錄，直到它們被重新整理到硬碟上的邏輯日誌檔案。緩衝區的大小決定了它被添滿的頻率，從而決定了它必須被重新整理到硬碟上的邏輯檔案中的頻率。 

PHYSBUFF 

引數PHYSBUFF指定為兩個用來暫時儲存將被修改的資料頁的緩衝區分別保留的共享記憶體的數量。緩衝區的大小決定了它被添滿的頻率，從而也決定了它被寫到硬碟上的物理日誌的頻率。 

如何監控記憶體使用情況

1. 使用onstat -g seg命令監控共享記憶體的segments。 

onstat -g seg 

Segment Summary 

(resident segments are not locked) 

id key    addr      size ovhd class blkused      blkfree 

這裡三行分別代表了駐留記憶體段（class為R)、虛擬記憶體段(class為V)、訊息記憶體段(class為M)。blkused和blkfree 分別代表使用空間和空閒空間。如果虛擬記憶體段的blkused 頻繁增加，則需要將SHMVIRTSIZE和SHMADD相應調大，調整後重新啟動Online。

2. 使用onstat -p 

1）ovlock指出分配的locks的不足量，如果該值持續增長，則需要增大引數 LOCKS的值。 

2）ovbuf指出分配的buffers的不足量，如果該值持續增長，則需要增大引數 BUFFERS的值。 

3）lockwaits/lockreqs * 100應該小於1%，如果這個計算值比較高，則應有如下考慮： 

a. 是否用了太多的page level locks。如果是，可以考慮用row level locks。 

b. 考慮用了table level lock的應用是否可以用其它型別的lock。 

c. 是否有太多的isolation設定為Repeatable Read 和Cursor Stability。確定是否可以使用更多的Dirty Read來替代。 

4）bufreads %cached的值指出buffer讀的百分比，該值建議大於95%，否則增大BUFFERS，bufwrits %cached的值指出buffer寫的百分比，該值建議大於85%，但太大如大於97%則可以將BUFFERS 相應減少些。 

影響I/O的配置引數

• CKPTINTVL 

• PHYSFILE 

• CLEANERS 

• LRUS 

• LRU_MAX_DIRTY 

• LRU_MIN_DIRTY 

CKPINTVL，PHYSFILE

CKPINTVL引數指定檢查點之間的時間間隔。當檢查點間隔到了，則系統執行檢查點操作。但如果這期間的所有資料物理上是一致的，Online可以跳過檢查點操作。另外，一旦物理日誌（PHYSFILE）的75%已滿，檢查點也會發生。透過設定CKPTINTVL為長時間間隔，可以利用物理日誌容量來觸發基於實際資料庫活動而不是任意時間單位的檢查點操作。但是，使用長檢查點間隔回增加失敗事件之後的恢復時間。 

LRUS、LRU_MAX_DIRTY和LRU_MIN_DIRTY

LRUS引數指示共享記憶體緩衝池中設定的最近最少使用（LRU）佇列數目。配置較多的LRU佇列將允許有更多的頁清除器操作，並減少每個LRU佇列的大小。對於單CPU系統，Informix建議設定LRUS引數為最小值4。對於多CPU系統，Informix建議設定LRUS為最小值4和NUMCPUVPS的取值之中較大的一個。 

可以用LRUS和LRU_MAX_DIRTY及LRU_MIN_DIRTY來控制在滿的檢查點之間頁被重新整理到磁碟的頻度。在某些情況下，透過設定這些引數，使得在檢查點發生時需要重新整理的修改的頁數量很少，可以達到高的吞吐量；這樣，檢查點的主要功能是更新物理日誌和邏輯日誌檔案。 

CLEANERS

CLEANERS引數指定執行的頁清除線索的數目。對於少於20磁碟的系統，Informix推薦CLEANERS的取值為磁碟的個數。對於20至100的磁碟的系統，Informix推薦每兩個磁碟分配一個CLEANERS。對於更多的磁碟系統，Informix推薦每四個磁碟分配一個CLEANERS。 

如何監控系統的I/O情況

使用onstat -g ioq，onstat -g iof, onstat -d 監控磁碟的負載情況： 

onstat -g ioq 

AIO I/O queues: 

class/hvp-id len maxlen totalops    dskread    dskwrite dskcopy 

如果aio佇列很大，則可增加一個AIO VP。如果某些class 為gfd 所對應的len 和maxlen 非常大，則需要考慮你的資料分佈是否合理，記住這些gfd 所對應的hvp-id的值，再透過onstat -g iof 查出是那幾個裝置，

onstat -g iof gfd pathname totalops dskread   dskwriteio/s 

這裡gfd的值等於onstat -g ioq 中那幾個hvp-id的值所對應的pathname就是I/O負載較大的裝置。用onstat -d可確定是哪個dbspace。則可以考慮重新分配磁碟或給表分片。