RE: QMAXACTLVL and system performance

I'm sure that there are people out there who will argue with me, but on
any box less than 10 years old I would set QMAXACTLVL to *NOMAX.

What you really need to weigh in your environment is the impact of too
few threads vs. the impact of to many threads running at once.  If you
truly need to throttle your threads down I would do it at the subsystem
or pool level.

Regards,
 
Scott Ingvaldson
iSeries System Administrator
GuideOne Insurance Group


-----Original Message-----
date: Tue, 6 Dec 2005 15:04:43 +0000
from: Martin Rowe <dbg400.net@xxxxxxxxx>
subject: QMAXACTLVL and system performance

Hi folks

We've just had a repeat of an interesting problem - our production
iSeries[1] partition 'froze' for about 15 minutes, then carried on as
if nothing had been the matter. We had this two weeks ago (but a bit
earlier in the day) and from gaps in logs & response times analysis it
has happened at other times too. We couldn't find anything obvious
last time, and IBM just suggested we try to get into DST to force a
storage dump. Except that when the system is frozen not even the
console works.

This time I noticed a CPF0908 - 'Machine ineligible condition
threshold reached' in QSYSOPR's messages which refers to QMAXACTLVL.
The value on our system (140) has been migrated during the previous
upgrade (and probably several prior to that). Other partitions (for
WebSphere, mirroring, thin primary etc) that were created from scratch
all have the default *NOMAX.

>From IBM's documentation it seems that this is probably too low, but
it would (?) have been set for a reason (at some time in the dim &
distant past). I can't see any downside to making this *NOMAX - are
there any? We've upped it to 500 pending further discussion.

On our development partition that runs WebSphere it was set down to 50
and changing to *NOMAX has improved performance; anecdotally at least.

Oddly enough not everything was frozen. NFS shares to my Linux box
worked fine but NetServer shares to Windows stopped. I'm wondering if
part of the problem was the system TCP/IP server also suffering from
the low thread setting (NFS is UDP based, as are pings which worked as
well).

Regards, Martin
[1] i825, V5R2, up to date on PTFs


DISCLAIMER:
This message and accompanying documents are covered by the Electronic 
Communications Privacy Act, 18 U.S.C. ?? 2510-2521, and contains information 
intended for the specified individual(s) only. This information is 
confidential. If you are not the intended recipient or an agent responsible for 
delivering it to the intended recipient, you are hereby notified that you have 
received this document in error and that any review, dissemination, copying, or 
the taking of any action based on the contents of this information is strictly 
prohibited. If you have received this communication in error, please notify us 
immediately by e-mail, and delete the original message.