從Oracle官方文檔中看來,CACHEMGR參數主要用於控制存放未提交事務的虛擬內存(virtual memory應該是指的swap/paging space空間)和臨時磁盤空間。所有的數據存放在叫做global cache(在報告中顯示的是super pool)的虛擬內存池中,當數據庫接收到commit/rollback之後這些cache裏面的內容纔會寫到trail文件中。global cache中包含以下子虛擬池(詳細內容見統計內容分析):
每個sub-pool中都有用於存放事務信息的buffer,原話:Within each sub-pool, individual buffers are allocated from the globalcache. Each buffer contains information that is relative to a transaction that is being processed by Oracle GoldenGate.1).一個虛擬池用於存放BLOB等大對象的池子;2).每個log reader thread一個虛擬池用於存放其他事務數據.
官方文檔中多次提到進程使用的內存不是由OGG自己控制的,而是由操作系統進行控制的,它具有的特點和和限制有:
1).Goldengate的cache manager是內部自動控制和調整的,一般不需要人爲調整;2).Goldengate合理調用操作系統內存管理函數,儘量回收old buffer而不將內存page out到磁盤,如果必須要page out的時候也將很少用到的buffer交換到磁盤;3).Goldengate只會在soft limit(cachesize)內按需劃分虛擬內存(不會劃分物理內存,但是實際測試效果是消耗的物理內存,所以想控制GG消耗的內存可以從此入手),且System calls to increase the cache size are made only as a last resort and, when used, are always followed by the release of virtual memory back to the system(意思:提升cache size往往是最終的一種手段,並且在用完之後會及時還到操作系統)。4).如果系統層面有相關的資源限制,cachemgr設置的值同樣會受到系統配置的限制;5).GG中page out的規則是:當使用的CACHE超過CACHESIZE時會將超過CACHEPAGEOUTSIZE的事務調換到磁盤,但是當這些事務都被調到磁盤後CACHE使用量還超過CACHESIZEMAX的話,其他任何需要繼續申請資源的事務都會調到磁盤。只有當CACHESIZE掉到比CACHESIZEMAX小之後CACHEPAGEOUTSIZE才生效。
計算前我們需要查看goldengate的report文件,檢查系統當前運行的報告用於作爲計算所需虛擬內存的參考。但是從實際上來看,在未設置CACHEMGR參數時所獲取到的值是基於操作系統總資源的一個固定值,不具有參考價值。例如:
某客戶的ext進程的rpt文件CACHEMGR virtual memory values (may have been adjusted)
CACHESIZE: 64G(實際系統內存就120GB,cache可用的軟限制)
CACHEPAGEOUTSIZE (normal): 8M(當實際CACHE超過CACHESIZE時超過8M的事務會在需要page out到磁盤時優先被page out)
PROCESS VM AVAIL FROM OS (min): 128G(進程可從OS獲取的最大VM,系統內存和SWAP經過一定計算後獲取)
CACHESIZEMAX (strict force to disk): 96G(由CACHESIZE和PROCESS VM AVAIL FROM OS計算得來的,表示CACHE中最多存放的事務數據量,超過該值則所有申請空間事務寫到tmp文件)同一GG實例上datapump進程的rpt文件CACHEMGR virtual memory values (may have been adjusted)
CACHEBUFFERSIZE: 64K
CACHESIZE: 8G
CACHEBUFFERSIZE (soft max): 4M
CACHEPAGEOUTSIZE (normal): 4M
PROCESS VM AVAIL FROM OS (min): 16G
CACHESIZEMAX (strict force to disk): 13.99G
但是按照官方的說法我們應該按照如下步驟去計算系統所需交換空間的大小:
1).通過GGSCI 中 view report查看GG實例中所有進程的PROCESS VM AVAIL FROM OS (min)並對其進行進行取到下個GB級別的值,如1.7GB取值爲2GB2).將上面的值乘以該類進程的數量,對值進行求和後得到所需的SWAP空間(實際我們應該認爲它是內存空間):(<PROCESS VM> x <n_Extracts>) + (<PROCESS VM> x <n_Replicats>)+(<swap for other processes>) = Max swap space on system
當我們的goldengate系統出現性能上的瓶頸或佔用過多(虛擬)內存的時候,我們需要獲取CACHE MANAGER的統計信息進行分析。看我們的系統是否需要調整cachesize的大小和file caching的配置。但是如果系統配置了limits限制進程資源的消耗,那麼我們調整CACHEMGR的配置不會有效果,GG一樣會將很多信息cache到文件中。以下是獲取統計信息的方式和詳細的統計信息
GGSCI (node100) 10> send extshs, cachemgr cachestats
通過以上命令查看該進程的cache統計信息
Sending CACHEMGR request to EXTRACT EXTSHS ...
CACHE OBJECT MANAGER statistics
CACHE MANAGER VM USAGE
vm current = 64K vm anon queues = 64K當前消耗的虛擬內存
vm anon in use = 0 vm file = 0
vm used max = 64K ==> CACHE BALANCED
虛擬內存消耗最大值
CACHE CONFIGURATION
cache size = 64G cache force paging = 96G
buffer min = 64K buffer highwater = 8M
pageout eligible size = 8M
================================================================================
RUNTIME STATS FOR SUPERPOOL
Global CACHE的運行時統計信息
CACHE Transaction Stats
trans active = 0 max concurrent = 5
non-zero total = 22 trans total = 423
CACHE File Caching
disk current = 0 disk total = 0
disk caching = 0 file cached = 0
file retrieves = 0
CACHE MANAGEMENT
buffer links = 0 anon gets = 0
forced unmaps = 0 cnnbl try = 0
cached out = 0 force out = 0
Allocation Request Distribution
< 128B: 0
128B: 0 22 | 512B: 0 1
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
Cached Transaction Size Distribution
0: 401
< 4K: 22
4K: 0 0 | 16K: 0 0
64K: 0 0 | 256K: 0 0
1M: 0 0 | 4M: 0 0
16M: 0 0 | 64M: 0 0
256M: 0 0 | 1G: 0 0
4G: 0 0 | 16G: 0 0
64G: 0 0 | 256G: 0 0
1T: 0 0 | 4T: 0 0
16T: 0 0 | 64T: 0 0
256T: 0 0 |1024T: 0 0
================================================================================
CUMULATIVE STATS FOR SUPERPOOL
Global CACHE的累計統計信息
CACHE Transaction Stats
trans active = 0 max concurrent = 4
non-zero total = 141 trans total = 9.25K
CACHE File Caching
disk current = 0 disk total = 0
disk caching = 0 file cached = 0
file retrieves = 0
CACHE MANAGEMENT
buffer links = 0 anon gets = 0
forced unmaps = 0 cnnbl try = 0
cached out = 0 force out = 0
Allocation Request Distribution
< 128B: 0
128B: 1 142 | 512B: 4 62
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
Cached Transaction Size Distribution
0: 9.11K
< 4K: 141
4K: 0 0 | 16K: 0 0
64K: 0 0 | 256K: 0 0
1M: 0 0 | 4M: 0 0
16M: 0 0 | 64M: 0 0
256M: 0 0 | 1G: 0 0
4G: 0 0 | 16G: 0 0
64G: 0 0 | 256G: 0 0
1T: 0 0 | 4T: 0 0
16T: 0 0 | 64T: 0 0
256T: 0 0 |1024T: 0 0
QUEUE Statistics:
num queues = 15 default index = 0
cur len = 0 max len = 0
q vm current = 0 vm max = 0
q hits = 21 q misses = 1
queue size q hits curlen maxlen cannibalized
0 64K 21 1 1 0
1 128K 0 0 0 0
2 256K 0 0 0 0
3 512K 0 0 0 0
4 1M 0 0 0 0
5 2M 0 0 0 0
6 4M 0 0 0 0
7 8M 0 0 0 0
8 16M 0 0 0 0
9 32M 0 0 0 0
10 64M 0 0 0 0
11 128M 0 0 0 0
12 256M 0 0 0 0
13 512M 0 0 0 0
14 1G 0 0 0 0
================================================================================
RUNTIME STATS FOR CACHE POOL #0
POOL INFO group: extshs id: p2509_BLOB instance: 0 tid: (nil)
trans active = 0 trans concurrent (max) = 0
trans total = 0 (0 )
flag = 0x00000030
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 0 0 | 512B: 0 0
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
================================================================================
CUMULATIVE STATS FOR CACHE POOL #0
POOL INFO group: extshs id: p2509_BLOB instance: 0 tid: (nil)
trans active = 0 trans concurrent (max) = 0
trans total = 0 (0 )
flag = 0x00000030
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 0 0 | 512B: 0 0
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
================================================================================
RUNTIME STATS FOR CACHE POOL #1
POOL INFO group: extshs id: p2509_ORA-LOB-MEMPOOL instance: 0 tid: (nil)
trans active = 0 trans concurrent (max) = 0
trans total = 0 (0 )
flag = 0x00000279
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 0 0 | 512B: 0 0
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
================================================================================
CUMULATIVE STATS FOR CACHE POOL #1
POOL INFO group: extshs id: p2509_ORA-LOB-MEMPOOL instance: 0 tid: (nil)
trans active = 0 trans concurrent (max) = 0
trans total = 0 (0 )
flag = 0x00000279
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 0 0 | 512B: 0 0
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
================================================================================
RUNTIME STATS FOR CACHE POOL #2(存放其他數據的POOL)
POOL INFO group: extshs id: p2509_extr instance: 1 tid: 0x2ba5bd619910
trans active = 0 trans concurrent (max) = 5
trans total = 423 (423 )
flag = 0x00000235
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 0 22 | 512B: 0 1
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
================================================================================
CUMULATIVE STATS FOR CACHE POOL #2
POOL INFO group: extshs id: p2509_extr instance: 1 tid: 0x2ba5bd619910
trans active = 0 trans concurrent (max) = 4
trans total = 9.25K (9467 )
flag = 0x00000235
last error = (0=<none>)
Allocation Request Distribution
< 128B: 0
128B: 1 142 | 512B: 4 62
2K: 0 0 | 8K: 0 0
32K: 0 0 | 128K: 0 0
512K: 0 0 | 2M: 0 0
8M: 0 0 | 32M: 0 0
128M: 0 0 | 512M: 0 0
2G: 0 0 | 8G: 0
默認情況下GG的temp disk在./dirtmp下面,如果磁盤空間不足或者性能影響時我們可以考慮使用CACHEMGR參數進行調整。使用CACHEMGR參數需要注意的事項有:
語法及各個選項的意義如下:1).對z/OS上的DB2和NonStop上的SQL/MX外的所有數據庫的GG進程有效;2).一個參數文件只能有一個CACHEMGR參數且各個選項沒有先後順序;
CACHEMGR {
[, CACHESIZE <size>]
[, CACHEDIRECTORY <path> [<size>] [, ...]]
[, CACHEPAGEOUTSIZE <size>]
}
選項 含義 CACHESIZE 可用CACHE的軟限制,64位系統默認64GB/32位系統GG自動根據實際進行調整,64位系統建議手工設 CACHEDIRECTORY 指定swap出來的文件放哪兒 CACHEPAGEOUTSIZE 指定page出來的事務大小閾值。