WAIT-SERVICE

Mike Holmans

WAIT-SERVICE
DB2 for OS/390 V5, OS/390 2.10.

We're experiencing intermittent slowdowns on a production subsystem. The
most obvious symptom is that all the threads go into WAIT-SERVICE.

It's not DSMAX. We thought it was that and upped the limit to 4000, when
there are only 3500 ds's in the subsystem, and that gave us some temporary
relief.

It wasn't waiting for the log to offload.

The MVS sysprogs have told me that during this afternoon's slowdown, DB2 was
using most of the expanded storage defined, and the migration age of
expanded storage was down to 1 second. We don't have any hiperpools defined.
This seems like an interesting avenue to explore: what would cause DB2 to
use expanded storage?

And does anyone else have any ideas about what might cause everything to go
into WAIT-SERVICE?

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view



[login to unmask email]

Re: WAIT-SERVICE
(in response to Mike Holmans)
What was CPU utilization? Are you running with WLM? Were the waiting
threads CICS, DBAT, TSO, batch, or some of each? What sort of concurrent
VTAM activity was occurring? In any event you should probably migrate to
DB2 V6.

George



Mike Holmans

Re: WAIT-SERVICE
(in response to truman.g.brown@VERIZON.COM)
CPU utilization seems to be high, but normal - 80% of the box in use.
Nothing obvious in DB2's CPU Usage.

We're in compatibility mode.

Most of the waiting threads were CICS, but the other attachments joined in
within a few minutes.

Don't know about the VTAM. I'll look out for tghat next time it happens.

We'll be moving to V7 this year. This particular image won't be going there
until Q3, so I've got to find something to do about this before then.

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view


>>-----Original Message-----
>>From: [login to unmask email] [mailto:[login to unmask email]
>>Sent: Friday, January 04, 2002 3:40 PM
>>To: [login to unmask email]
>>Subject: Re: [DB2-L] WAIT-SERVICE
>>
>>
>>What was CPU utilization? Are you running with WLM? Were the waiting
>>threads CICS, DBAT, TSO, batch, or some of each? What sort
>>of concurrent
>>VTAM activity was occurring? In any event you should
>>probably migrate to
>>DB2 V6.
>>
>>George
>>
>>
>>To change your subscription options or to cancel your
>>subscription visit the DB2-L webpage at
>>http://www.ryci.com/db2-l. The owners of the list can be
>>
>>



Max Scarpa

Re: WAIT-SERVICE
(in response to Mike Holmans)
Hi ....

What is your NOT-ACCOUNTED value according your monitor (if any) ? Do you
use PREFORMAT ? (I didn't believe it, but sometimes it help a lot).
EDIPROC , VALIDPROC...if any ?

MAx Scarpa



Gerald Brookman

Re: WAIT-SERVICE
(in response to Max Scarpa)
I NOTICED YOU WERE ON OS/390 2.10. PLEASE SEE "MEMORY LEAKS" THREAD STARTING
1/04/02!!! THIS IS "ON POINT".

-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Friday, January 04, 2002 9:03 AM
To: [login to unmask email]
Subject: WAIT-SERVICE


DB2 for OS/390 V5, OS/390 2.10.

We're experiencing intermittent slowdowns on a production subsystem. The
most obvious symptom is that all the threads go into WAIT-SERVICE.

It's not DSMAX. We thought it was that and upped the limit to 4000, when
there are only 3500 ds's in the subsystem, and that gave us some temporary
relief.

It wasn't waiting for the log to offload.

The MVS sysprogs have told me that during this afternoon's slowdown, DB2 was
using most of the expanded storage defined, and the migration age of
expanded storage was down to 1 second. We don't have any hiperpools defined.
This seems like an interesting avenue to explore: what would cause DB2 to
use expanded storage?

And does anyone else have any ideas about what might cause everything to go
into WAIT-SERVICE?

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view





Isaac Yassin

Re: WAIT-SERVICE
(in response to Gerald Brookman)
RE: WAIT-SERVICEHi,
Still investigating...
BTW - Expanded storage usage is going up due to paging too, not only by HP usage, so memory leaks that enlarge your central storage consumption causes expanded storage consumption of your DBM1 to grow up too, this is a real good way to be "friendly" to other users ;-)
We don't have (yet) "thread wait" problems and hope to solve the leakage before it starts ...


Isaac Yassin
DBMS & IT Consultant
IBM Certified Solution Expert
DB2 V7.1 Database Administration for OS/390
[login to unmask email]
----- Original Message -----
From: Brookman, Gerald
Newsgroups: bit.listserv.db2-l
To: [login to unmask email]
Sent: Friday, January 04, 2002 8:49 PM
Subject: Re: WAIT-SERVICE


I NOTICED YOU WERE ON OS/390 2.10. PLEASE SEE "MEMORY LEAKS" THREAD STARTING 1/04/02!!! THIS IS "ON POINT".

-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Friday, January 04, 2002 9:03 AM
To: [login to unmask email]
Subject: WAIT-SERVICE



DB2 for OS/390 V5, OS/390 2.10.

We're experiencing intermittent slowdowns on a production subsystem. The
most obvious symptom is that all the threads go into WAIT-SERVICE.

It's not DSMAX. We thought it was that and upped the limit to 4000, when
there are only 3500 ds's in the subsystem, and that gave us some temporary
relief.

It wasn't waiting for the log to offload.

The MVS sysprogs have told me that during this afternoon's slowdown, DB2 was
using most of the expanded storage defined, and the migration age of
expanded storage was down to 1 second. We don't have any hiperpools defined.
This seems like an interesting avenue to explore: what would cause DB2 to
use expanded storage?

And does anyone else have any ideas about what might cause everything to go
into WAIT-SERVICE?

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view


visit

Mike Holmans

Re: WAIT-SERVICE
(in response to Isaac Yassin)
Hmm.

I wonder why it is only this subsystem which is experiencing these problems,
then. We've been on 2.10 for months, and this is the only subsystem out of
43 which is having this problem.

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view


-----Original Message-----
From: Brookman, Gerald [mailto:[login to unmask email]
Sent: Friday, January 04, 2002 6:49 PM
To: [login to unmask email]
Subject: Re: [DB2-L] WAIT-SERVICE



I NOTICED YOU WERE ON OS/390 2.10. PLEASE SEE "MEMORY LEAKS" THREAD STARTING
1/04/02!!! THIS IS "ON POINT".

-----Original Message-----
From: [login to unmask email] [ mailto:[login to unmask email]
<mailto:[login to unmask email]> ]
Sent: Friday, January 04, 2002 9:03 AM
To: [login to unmask email]
Subject: WAIT-SERVICE


DB2 for OS/390 V5, OS/390 2.10.

We're experiencing intermittent slowdowns on a production subsystem. The
most obvious symptom is that all the threads go into WAIT-SERVICE.

It's not DSMAX. We thought it was that and upped the limit to 4000, when
there are only 3500 ds's in the subsystem, and that gave us some temporary
relief.

It wasn't waiting for the log to offload.

The MVS sysprogs have told me that during this afternoon's slowdown, DB2 was

using most of the expanded storage defined, and the migration age of
expanded storage was down to 1 second. We don't have any hiperpools defined.

This seems like an interesting avenue to explore: what would cause DB2 to
use expanded storage?

And does anyone else have any ideas about what might cause everything to go
into WAIT-SERVICE?

Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view



DB2-L webpage at http://www.ryci.com/db2-l < http://www.ryci.com/db2-l > . The
owners of the list can

Raymond Bell

Re: WAIT-SERVICE
(in response to Mike Holmans)
Sorry Mike, but if this is the only subsystem out of 43 with the problem
it's time to play 'spot the differences'. It's not something as silly as
I/O contention on the volumes the logs are on, is it? Anyway, I guess you
start comparing your problem subsystem with the others on the same LPAR.

Good luck,


Raymond



mike.holmans@B
T.COM To: [login to unmask email]
Sent by: DB2 cc:
Data Base Subject: Re: WAIT-SERVICE
Discussion
List
<[login to unmask email]
M>


06/01/02 03:45
Please respond
to DB2 Data
Base
Discussion
List





Hmm.

I wonder why it is only this subsystem which is experiencing these
problems, then. We've been on 2.10 for months, and this is the only
subsystem out of 43 which is having this problem.



Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]

This post is solely the opinion of its author and does not necessarily
reflect BT's view



-----Original Message-----
From: Brookman, Gerald [mailto:[login to unmask email]
Sent: Friday, January 04, 2002 6:49 PM
To: [login to unmask email]
Subject: Re: [DB2-L] WAIT-SERVICE



I NOTICED YOU WERE ON OS/390 2.10. PLEASE SEE "MEMORY LEAKS" THREAD
STARTING 1/04/02!!! THIS IS "ON POINT".


-----Original Message-----
From: [login to unmask email] [mailto:[login to unmask email]
Sent: Friday, January 04, 2002 9:03 AM
To: [login to unmask email]
Subject: WAIT-SERVICE





DB2 for OS/390 V5, OS/390 2.10.


We're experiencing intermittent slowdowns on a production subsystem. The
most obvious symptom is that all the threads go into WAIT-SERVICE.


It's not DSMAX. We thought it was that and upped the limit to 4000, when
there are only 3500 ds's in the subsystem, and that gave us some temporary

relief.


It wasn't waiting for the log to offload.


The MVS sysprogs have told me that during this afternoon's slowdown, DB2
was
using most of the expanded storage defined, and the migration age of
expanded storage was down to 1 second. We don't have any hiperpools
defined.
This seems like an interesting avenue to explore: what would cause DB2 to
use expanded storage?


And does anyone else have any ideas about what might cause everything to
go
into WAIT-SERVICE?


Mike Holmans
Database Consultant
BT Affinitis Computing Partners
[login to unmask email]


This post is solely the opinion of its author and does not necessarily
reflect BT's view