Hello,
I've a extractor with a configuration of cache of this:
CACHEMGR CACHESIZE 128M
The process is up since:
Last Started 2017-05-22 08:47 Status RUNNING
About 5
If we see cache statistics:
send extract EXT_E0 CACHEMGR CACHESTATS
Sending CACHEMGR request to EXTRACT EXT_E0 ...
CACHE OBJECT MANAGER statistics
CACHE MANAGER VM USAGE
vm current = 3.57M vm anon queues = 3.57M
vm anon in use = 0 vm file = 0
vm used max = 148.13M ==> CACHE BALANCED
CACHE CONFIGURATION
cache size = 128M cache force paging = 209M
buffer min = 64K buffer max (soft) = 1M
pageout eligible size = 1M
================================================================================
RUNTIME STATS FOR SUPERPOOL
CACHE Transaction Stats
trans active = 0 max concurrent = 22
non-zero total = 50.12M trans total = 51.66M
CACHE File Caching
filecache rqsts = 10.100K bytes to disk = 278.40G
file retrieves = 283.68K objs filecached = 96
queue entries = 10.81K queue processed = 17.17K
queue entry not needed = 190 queue not signaled = 45
fc requesting obj = 0
CACHE MANAGEMENT
buffer links = 308.95K anon gets = 0
forced unmaps = 4.65K cnnbl try = 16.13K
cached out = 6.78K
Because I see Cache file caching activity:
Filecache rqsts = 10.100K bytes to disk = 278.40G
This means, that from the start to up, the extract accessed 10.100K time to disk and write 278.40 GB. !
With these statistics I can already know that there have been a number of times that the extractor has dumped transactions from the cache to the disk, due to the memory pressure.
Then increase the cache will reduce I/O to disks.
however, it is possible to know more information about the nature of the transactions that have caused the disk dump. For example, maximum size of the transaction, duration etc., if the write was done for a a large transacction, o BR interval.
Which is you opinion?
Thanks
Arturo