Re: Prestart job problem

Point taken, although you can tune shared pools quite reasonably if you understand them and how the parameters work and both Java and SQL can be made to behave quite well.

That said: I have never really been a fan of the autotune function in the OS (and dislike the OEM tuning products equally) because the granularity is not there to manage the environement. Auto tune is like driving a car down the freeway at 65MPH by looking into the rear view mirror. You _can_ keep the car in the lane successfully but your always reacting to what _/was/_ in front of you, not was_/is /_in front of you.

Autotune functions are the same way, they can only react to what was, and apply an algorithm that levels out historical data to make the settings. The reason is works for the most part is most customers environments don't change all that much so over time it tends to settle in on a reasonable configuration. Manual tuning is much more efficient once the administrator understands the environment.

Using a private pool as you suggest, unless it is really needed, defeats IBM i's ability to manage memory between jobs and tasks and takes you back to the System/38 days of performance management. Private pools can also increase the need for memory on the machine by quite a bit because the intelligent paging cannot be used. Rather, use shared pools. Put jobs of like type in a single shared pool and let the OS do it's thing. Just turn the auto tune function off and manage it yourself. That will avoid the problem you point out which is not only a Java JVM issue but also affects SQL performance.

The unfortunate thing is this all requires a competent administrator to run the system and most companies won't invest in one for IBM i. They'll build an army for the Microsoft servers, but not for IBM i.

Jim Oberholtzer
Chief Technical Architect
Agile Technology Architects


On 10/17/2011 7:07 AM, Joe Pluta wrote:

On 10/17/2011 5:40 AM, Jim Oberholtzer wrote:

> Richard,
>
> You don't really need another subsystem. What you need to do is add
> another subsystem memory pool. Steps are:
> CHGSHRPOOL POOL(*SHRPOOL12)
> SIZE(3000)
> ACTLVL(10)
> PAGING(*CALC)
> TEXT('For my Java Jobs')
> Pick a shared pool, size, and activity level (number of jobs that will
> be active at once) that makes sense to you.
> Add the memory to the subsystem in question. I picked QBATCH, use the
> correct one for you.
>

Jim, the only issue I've had with shared pools is that the system wants
to tune them. I fI want a completely autonomous pool, I tend to add it
to the subsystem itself, like this:

CHGSBSD SBSD(JVMSBS) POOLS((1 128000 10))

The system won't try to change the size on me. I'm not sure this is the
best approach for the OP, but I find that especially in the case of Java
it really helps to segregate the paging. JVMs and IBM i paging don't
coexist very well, it seems.
--