Detector - CPU increase and system slow down

[Anon Anon]

I upgraded Detector from R16 to R18 this past Sunday. Since then, the system seems to use much more CPU (compared to R16) and application packages are running slow. Anybody have any tuning tips?

 

This happens only when the data collection is on and we collect data for 20 mins in the morning, 20 mins at noon and 20 mins in the evening.

[Keith Sessions]

Hi There,

  So just to make it clear, are you saying you start a collection for 20 minutes in the morning then stop it, Then 20 mins at Noon then stop it then 20 minutes in the evening then stop it?

You say the system is using much more CPU, roughly as a percentage how much more?

What DB2 Version are you on?

 

Thanks Keith   

[Anon Anon]

Hello Keith,

 

You are right about the collection timings.

 

I upgraded it on Sunday night. So I've the data for only 3 days. During the collection interval, Detector used to use 5 - 6 MIPS, now it seems to be using 8 - 10 MIPS.

 

We're on DB2 V10 NFM.

[Jeff.Gross]

The root cause of this behavior is the new r17 default parameter of LATCH(Y).  Changing the PDT and PSA parmlib members to have a LATCH (N) parameter should solve this higher CPU.  A corrective PTF is on the way.

[Chris Hoelscher]

We experienced this problem earlier this year – applying LATCH(Y) did indeed solve this problem!

 

Chris hoelscher

Technology Architect

Database Infrastructure Services

Technology Solution Services

 

123 East Main Street

Louisville, KY 40202

[e-mail]<mailto:[e-mail]>

Humana.com

[phone]

[phone]

[Anon Anon]

Same here, that fixed the problem for us too. However, the COMMITs and SQLs reported seems to be way less than normal. For now, we are not concerned about it, as the data that we are looking for in these collections seems to be intact.

Moreover, we don't have much time to collect data required to investigate this issue. Our main concern was CPU increase. Since that issue is resolved, we're back on track.

[Chris Hoelscher]

Correction – it was setting LATCH(N) in the PDT and PSA members in parmlib that corrected the problem

 

Chris hoelscher

Technology Architect

Database Infrastructure Services

Technology Solution Services

 

123 East Main Street

Louisville, KY 40202

[e-mail]<mailto:[e-mail]>

Humana.com

[phone]

[phone]

[Jeff.Gross]

Chris,

 

Thanks for confirming the LATCH(N) was your solution too.

 

Jeff

[Jeff.Gross]

Kumaresh,

 

I saw this case a few weeks ago and had the development team review the symptoms.  The change to LATCH(N) could not affect any collection stats, so this is a mystery why you would see this.   I am curious how you noticed the change and if you want to pursue, we can go back to the case management system.

 

Thanks,

 

Jeff