memory pools

Hello,

In an all-in-one DB and Enterprise server box (web clients only) and all BSFNs running on the enterprise server, we are keeping (using common sense) the JDE811 subsystem in a separate shared memory pool.

JDENET and CO kernels connect to the database via EDRSQL and JDBC JAS servers connect via QZDASOINIT jobs, which along with the database core needs, use the Base memory pool.

It seems like with each increase of memory needs (determined by fault rate and # of threads) in my CO kernel pool, I have a subsequent demand to expand the Base (database) pool, which makes sense, as CO kernels and JAS clients that use them need database transactions when busy.

I know it is counterintuitive, but instead of letting mempry pool tuning change the size like a yo-yo and figure out the right timing of these adjustments, am I not better off keeping the JDE811 subsysem in the base pool, with the database server and I/O processes?

Anyone know and willing to share the timing/conflict relationship between the CO kernels and database use of memory and their own approach?

Thank you in advance.

AS/400 gurus, please help me out.

With JDE811 running in its own shared pool, the demand for memory seems to oscilate -- when kernels need memory, base pool and database processes seem idle and the other way around? I have enough memory and I have put limits on the pools, so it all runs fine. But, my little brain thinks that I would be better off with everything together in the base pool. Where am I wrong? Thanks.

[ QUOTE ]
... am I not better off keeping the JDE811 subsysem in the base pool, with the database server and I/O processes?


[/ QUOTE ]

You might want to split out the QZDASOINIT into their own memory pool. Having everything in the base pool means that any one group of jobs can eat up all the memory which would effect other jobs. By segregating them out to multiple pools, their effect on memory can be isolated as they only have a set amount of memory to work with.

I have it set up this way, but also have that yo-yo effect as you describe where memory is constantly being shifted from one pool to another as needed. I've read and been told that once you know how much memory each pool needs on average, to turn off auto tuning but i haven't gone ahead because i've had no problems with auto tuning on.

Thanks DEA,

No visible problems here either, but the yo-yo values I am seeing make me anxious. I agree with you, once my go-live settles, it is best to turn the auto-tuning off, but this may be months and years away...
Also, a follow up, most of my DB connectivity seems not to be in QZDASOINIT, but EDRSQL (CO kernels to database). I don't even see these jobs.
Anyway to control their memory use?

I agree with the previous, separate pools for pre-starts and E1. E1 does not play nicely with autotune. It is generally accepted practice to have it on during benchmarking, then set the pools and turn it off. The IBM Redbook for E1 has the tuning recommendations, including batch pool settings, the prestart job pool, and E1 pools.

Thank you all for your comments I am convinced too. I will be turnng off auto-tuning shortly (we are 3 weeks into our go-live), as soon as I get an idea of how much memory each portion actually needs...