The answer here isn't black or white. It depends alot on what you're
running in the web servers and whether QUSRWRK is running lots of ODBC
and JDBC query support. We've found that database works very poorly in
constrained memory pools shared by lots of jobs over large datasets with
large result sets. If you are using embedded SQL in CGI programs
database will run within the memory pool associated with the QHTTPSVR
subsystem. If that is a large pool database will use large chunks of
memory and produce results very quickly. If it is in a small pool with a
large max active setting, database will use small memory chunks and take
a very long time to work over a large dataset. When you are using java,
you need to be aware of the memory requirements of the jvm and all the
objects that may be active in memory. JVM may overcommit memory but
frequent garbage collection is going to keep those pages faulting back
in. Java runs best when its entire heap can remain resident in memory.
Apache instances serving static web pages aren't going to take a lot of
memory. If that's all you're doing with QHTTPSVR, you could run that in
a constrained pool very effecively. If you're doing a lot of Net.Data
database access with that QHTTPSVR, you need to consider the database
memory factors. If you're running a Tomcat instance attached to Apache,
you need to factor the JVM requirements. QWAS6 is usually dedicated to a
single instance of WAS; that is a single JVM. That JVM instance is
probably accessing database through JDBC which might mean it is starting
QZDASOINIT jobs in your QUSRWRK subsystem. In this configuration, you
isolate the JVM in the QWAS6 subsystem pool and let the database use the
pool in QUSRWRK.
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Christen, Duane J.
Sent: Thursday, February 05, 2009 8:12 AM
To: 'Midrange Systems Technical Discussion'
Subject: RE: Storage pools and QHTTPSVR and QUSRWRK subsystems
Tom;
That is what I have always understood also, and the way I have my box
set up at home but here I am just a lowly developer and the admin staff
don't have a clue. We are having performance problems with our web
services on a 12 way 570-MMA where I am running a 170 at home with no
performance problems.
I double checked my box set up last night and I have QWAS6, QHTTPSVR,
and QUSRWRK in a shared pool so my spidie sense was wrong. Now I get to
have fun convincing admin to modify the development box to prove the
viability of making the modifications before I can convince them to do
it in production.
Thanks
Duane Chriten
-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx
[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Tom Liotta
Sent: Wednesday, February 04, 2009 9:19 PM
To: midrange-l@xxxxxxxxxxxx
Subject: Re: Storage pools and QHTTPSVR and QUSRWRK subsystems
Christen, Duane J. wrote:
We currently have subsystem QWAS6 (Websphere 6.0 server) in its own
storage pool, which has seemed to improved the performance of our web
interactions. I would like to move subsystems QHTTPSVR and QUSRWRK to
the same pool as QWAS6, but in the back of my mind is a warning that
QHTTPSVR should stay in the *BASE pool.
Duane:
Unless you have QWAS6 running a private, rather than shared, memory
pool, I can't think of any reason why you should have any work at all
running in *BASE. QHTTPSVR and QUSRWRK, and others, doing active work in
*BASE only makes things harder for any performance adjustments to
happen.
IMO, the first thing to do on any system where performance monitoring
will be done is to stop using *BASE for jobs. All jobs.
Let the system decide when *BASE should be used, e.g., perhaps via
QTSEPOOL. But don't route them there yourself without _expecting_
general performance to suffer with no good explanation.
(Routing to *BASE "yourself" means not changing IBM's default subsystem
descriptions for pools and routing entries and prestart
entries.)
As usual, here's hoping someone adds something authoritative. My opinion
is purely from reading over the years about work management and
performance maintenance.
Tom Liotta
--
Tom Liotta
The PowerTech Group, Inc.
19426 68th Avenue South
Kent, WA 98032
Phone 253-872-7788 x313
253-479-1416
Fax 253-872-7904
http://www.powertech.com
--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing
list To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe,
unsubscribe, or change list options,
visit:
http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at
http://archive.midrange.com/midrange-l.
midrange.com
