"Pete" <
[email protected]> ha scritto nel messaggio
First of all, I have to say that I'm not an OS400 expert.. I have to work
with iSeries, but my experience it's mainly with Java. So, my answers may
not be the best one you can obtain... Anyway:
The app is a basic war file, JTOpen to the client database, and it's
been tested / is stable on other servers and platforms os's, but not
WebSphere on iSeries.
Ok, I suggest you to use the native Toolbox (not the free source JTOpen,
that's very good on linux or windows WAS). In IBM's documentation, you
should find out a lot of suggestions...
We get sluggish performance, but on doing a multiple run load test,
the performance gets a bit better as time goes on.
I was told that OS400 assigns different "resource slices" to programs, based
upon using time... that may be the reason for this behaviour.
Tried all different heap sizes, profiled the app, verbose gc'd it, but
always around the same user mark the used RAM flies through the roof
and the system hangs for upto a 15mins. The app is running on a
seperate partition with a 2gig pool (even gone upto 6gig on shared
pool).
Your iSeries is really powerfull... can I ask which model ? Anyway 2 gig are
usually a huge amount for J2ee apps.
As for garbage collection, it goes ok, but at some point the live
objects exceeds collected objects, but then gets better. Sometime, we
get GC no (say 22) kicking off when GC 21 is just starting. GC 21
takes control, the live objects goes to 15 million (normally is 3
million), and then after GC 22 comes back. It then takes a few cycles
to get down to 6 million, but this whole time the collected objects
are 1-2 million, compared with a mass of live objects. When this
happens, the performance goes massively downhill (from being rubbish
anyway).
Well, if you had 6 million of object in use, it means your system is heavily
loaded... how many request does it serve ?
This morning, I've increased the max thread count to 120, min to 50,
and the test run performs better, but still bad. I noticed in the Web
Container / Threads counter that the threads go up, then at some point
they do an "upside down bathtub", i.e. hitting 50-55 active threads
for a while then shooting back down to 0-10, then back up again. Is
this normal under continued load ????
How can I see if threads are backing up ?
Any help is appreciated.
Thread policy is totally managed by WAS; apart of some settings, there's not
much more you can do... Even if this behaviour were not normal (I don't know
if it's normal or not, sorry), you can't do nothing about thread....
Do you use EJB ? If so, these thread may be in a "ready state" and waiting
to be assigned to request....
I'm afraid to have been not a great help...
Scorpio
