WebSphere on iseries 400

I understand that there are not many of us with running WebSphere on iseries 400.

I’m hoping there is someone who might be able to answer a question for me.

I have a dedicated LPAR running WebSphere 5.0.2 and WebSphere 6.0.2.

IBM has mentioned to me that we should have at least 2.5 GB for *BASE and anywhere from 1 to 4 GB of RAM for each application server.

I have 5 application servers on Web 5 (including server1) and 3 application servers on Web 6 (including server1) for a total of 8 application servers.

I have 7GB or ram on my dedicated LPAR and doing the math above, should have at least 10.5.

The CPU is rarely above 10%. I have a model 570 with 4 LPAR’s and am not sure how much cpw is on the LPAR with WebSphere.

I would very much appreciate it if you could let me know what your experience is with RAM. Are you closer to the 1GB per HTML server or 4 GB per HTML server?

Anything you could share would be much appreciated.

Thank-You,

Michael

8.11 - SP1 - 8.96.G1
Planner ESU JJ12489
DS = Windows 2003, SP1, 2GB of RAM and a 3.2ghz processor
ES = iseries 400, OS/400 V5R3
Windows Application server - Windows 2003 - Service pack 1
IBM WebSphere Application Server, 5.0.2.14
Build Number: cf140544.02
Build Date: 10/31/2005

And

IBM WebSphere Application Server - Express, 6.0.2.17
Build Number: cf170648.05
Build Date: 11/28/06

Hi Michael,

We're not alone in the Universe... there are some other
guys out there (like me) enjoying/enduring WAS on iSeries.
After two years of practical experience, I realized that
you'll have better performance running several 1 Gb RAM
JAS instances (on the same box) than having a single
huge instance taking 6 or 8 Gb RAM.
There seems to be a major slowdown from Java Garbage
Collection, a background Java process which cleans up
unused variables, pointers, data structures etc.
Garbage collection is quite a lenghty process, and
its duration increases rapidly when the JVM size is
larger than 1 Gb.
Spreading your users across several JAS instances will
also help you to better distribute workload and reduce
the impact of having a JAS instance falling down.

Regards,