Re: Performance tuning memory pools

[Nathan Andelin <nandelin@xxxxxxxxx>]

What makes you think that you have a lot of "small memory footprint" jobs running?  Any job that creates a JVM instance is going to be needing a lot of memory, relatively - even if the job function is relatively minor, the JVM itself takes a lot of memory.

-Nathan.



----- Original Message ----
From: Josh Diggs <JDiggs@xxxxxxxxxxxx>
To: "midrange-l@xxxxxxxxxxxx" <midrange-l@xxxxxxxxxxxx>
Sent: Fri, March 26, 2010 8:02:39 AM
Subject: Performance tuning memory pools

We are seeing very slow response on jobs that run out of the *Base memory pool.  These are java jobs that are part of our ERP package.  From looking at wrksyssts it appears that a good part of the problem may be excessive paging.  When the system is under full load we are seeing an average of a little less then 100 DB faults and about 150 Non-DB faults per second.

I don't have any training in this area, but the obvious problem is that we simply don't have enough memory to accommodate the load we are putting on the server.  Is there a chance that we simply have the max active field set too low because we have a large number of relatively small memory footprint jobs running?  How would I test that hypothesis?

I can narrow down the jobs for which I would most like to increase performance to one subsystem.  Is it fairly straightforward to define a user memory pool constrained for use to that one subsystem?

Thanks for any advice.

Josh Diggs
Information Systems Manager
California Fine Wire