Too large number of QZDASOINIT jobs running under QUSRWRK subsystem
CENTRINO
We are having problems with a large number of QZDASOINIT jobs running under
QUSRWRK subsystem.
OS version is V5R4M0
We have a web site running a web aplication that uses DB2/400 as its
database and we are experiencig some several problems with QZDASOINIT jobs.
- They take too much time to start.
- When the connection is closed the QZDASOINIT does not ends.
- So, after a few hours of web server running we well may have some 100 or
more QZDASOINIT jobs running
A few questions:
Should QZDASOINIT jobs end when connection is closed?
If they do not end, should they be re-used by another web server
session?
How could we improve startup time and overall performance for those
jobs?
Thanks in advance.
Peter H. Coffin
> Hi
>
> We are having problems with a large number of QZDASOINIT jobs running under
> QUSRWRK subsystem.
> OS version is V5R4M0
>
> We have a web site running a web aplication that uses DB2/400 as its
> database and we are experiencig some several problems with QZDASOINIT jobs.
>
> - They take too much time to start.
Can't help you there...
> - When the connection is closed the QZDASOINIT does not ends.
Right. They hang around to serve other requests after starting.
>
> - So, after a few hours of web server running we well may have some 100 or
> more QZDASOINIT jobs running
What is the maximum number of QZDASOINIT jobs that the QUSRWRK is
configured to keep around?
DSPSBSD SBSD(QUSRWRK)
- Option 10 - Display Prestart Job Entries
- Option 5 - Display details on QZDASOINIT
In there, there's a value for the maximum number that are spawned and
each connection request will spawn a new job until that maximum is
reached. At that point, they start dying off after a number of uses to
free up stale resources.
> A few questions:
>
> Should QZDASOINIT jobs end when connection is closed?
No. It should hang around for the number of uses that are configured in
the same place as the maximum number of jobs, then end of its own
accord. This is a Good Thing, since (as you noted) starting the things
from scratch isn't free.
> If they do not end, should they be re-used by another web server
> session?
Yup.
> How could we improve startup time and overall performance for those
> jobs?
Tune the number of them and how long they run to meet the performance
demands of your ODBC and JDBC connections.
--
34. I will not turn into a snake. It never helps.
--Peter Anspach's list of things to do as an Evil Overlord
CENTRINO
Is there any way to shutdown QZDASOINIT job by timeout?
I mean if there is not a request made by a client open session during a
given number of minutes, the job should end, that's in order to prevent
object locks.
"Peter H. Coffin" <hel...@ninehells.com> escribió en el mensaje
news:slrnieabgd....@abyss.ninehells.com...
Klaus Moedinger
> We have a web site running a web aplication that uses DB2/400 as its
> database and we are experiencig some several problems with QZDASOINIT jobs.
>
> - They take too much time to start.
>
> - When the connection is closed the QZDASOINIT does not ends.
>
> - So, after a few hours of web server running we well may have some 100 or
> more QZDASOINIT jobs running
Looks like the web application is badly designed. A "good" web
application would use connection pooling with an initial and maximum
pool size (where pool size equals number of QZDASOINIT-Jobs).
> Should QZDASOINIT jobs end when connection is closed?
It depends. If connection pooling is used - no, at least not instantly.
If not, yes.
Best regards,
Klaus
Kent Milligan
What types of object lock conflicts are you encountering? Most of the "soft"
locks maintained by a QZDASOINIT job should not conflict or prevent other activity.
--
Kent Milligan
ISV Enablement - System i
km...@us.eye-bee-m.com (spam trick) GO HAWKEYES!!
>>> ibm.com/iseries/db2
(opinions stated are not necessarily those of my employer)