× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



We had this same issue on our R&D partition today.
At this point, I'm not convinced it is a single job, or maybe a combination of jobs.
Also not sure QYPSJSVR is the only culprit, maybe one of culprits.
I went back two weeks in perf data, and QSYPSJSVR job had high thread count back then, really hasn't changed.
QSYPSJVR job with increasing thread count is a secondary issue, job needs to be recycled, weekly.


From: Steinmetz, Paul
Sent: Friday, May 24, 2013 6:39 PM
To: 'Midrange Systems Technical Discussion'
Subject: RE: CPF0908 Machine ineligible condition threshold reached, followdby CPF0909 Ineligible condition threshold reached for pool 02.


Management Central job, QYPSJSVR, has a known cleanup issue, need to recycle this as needed.

We have no monitors running, inventory collection once a day.

Below is the KB doc.

Thanks everyone who contributed.

IBM Software
Technical Document

Document Number: 488586839
____________________________________________________________
Functional Area: Basic System Environment Functions (BSEF)
SubFunctional Area: System Management Monitoring
SubSubFunctional Area: Management Central
____________________________________________________________
Product: I5/OS (5761SS100); OS/400 BASE (5722SS100)
Release: 6.1; V5R3M0; V5R4M0; V6R1M0

Classification: Entitled/Advanced

Keywords:
____________________________________________________________
Document Title:Management Central and Threads
Document Description:
A user noticed an increasing number of QYPSJSVR threads. The number of QYPSJSVR threads increase by about three threads each time one displays Collecting Service menu by iSeries(r) Navigator (iNav).

Example:
Display Collecting Service: Increasing 9-10 threads
Close iNav: Decreasing 5-7 threads

Test results:
1.

Start QYPSJSVR
Threads: 25-27

2.

Display Collecting Service by iNav
Threads: 43-45

3.

Close iNav
Threads: 38-40

4.

Display Collecting Service by iNav
Threads: 47-50

5.

Close iNav
Threads: 43-45

6.

Display Collecting Service by iNav
Threads: 53-56

7.

Close iNav
Threads: 48-51



The user was worried about increasing threads because the user noticed that the number of QYPSJSVR threads was over 1,000. This customer rarely does IPL; therefore, MGTC rarely restarts, and it causes too many threads.

Questions and Answers regarding Management Central and Threads

Q1. Why doesn't QYPSJSVR decrease threads rather than increase when closing iNav?
A1. Because iNav is closed, there are some functions/tasks that continue running on the server; therefore, some threads are still needed. For example, if a monitor is running, it continues running and getting data. In this case, similar to collection services being used by several functions, some threads remain there waiting for notifications or requests.

Q2. Does this phenomenon have a bad influence?

A2. No, it does not. The threads are not consuming so much CPU; however, if they consume a considerable
amount of CPU, we could consider it as a problem and we could check it.

Q3. Should we restart MGTC regularly to decrease threads?

A3. Yes, It is recommended to restart MGTC once every month to decrease threads and avoid connection problems.




This document and many others can be found in the Software Knowledge Base at the following URL:

http://www.ibm.com/systems/electronic/support/s_dir/slkbase.nsf/slkbase

Additional resources that may be of interest to you:
Fix Central: http://www.ibm.com/support/fixcentral
Recommended Fixes: http://www.ibm.com/systems/electronic/support/s_dir/slkbase.nsf/recommendedfixes



-----Original Message-----
From: midrange-l-bounces@xxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxx> [mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Scott Mildenberger
Sent: Friday, May 24, 2013 6:00 PM
To: Midrange Systems Technical Discussion
Subject: RE: CPF0908 Machine ineligible condition threshold reached, followdby CPF0909 Ineligible condition threshold reached for pool 02.



It looks like that job is related to Management Central. My guess is somebody is doing something in there causing an issue, maybe they are trying to monitor too many jobs or something like that. If there is any info in the job log indicating which user is connected to it then maybe that would help track it down.



Scott





-----Original Message-----

From: midrange-l-bounces@xxxxxxxxxxxx<mailto:midrange-l-bounces@xxxxxxxxxxxx>

[mailto:midrange-l-bounces@xxxxxxxxxxxx] On Behalf Of Steinmetz, Paul

Sent: Friday, May 24, 2013 3:29 PM

To: 'Midrange Systems Technical Discussion'

Subject: RE: CPF0908 Machine ineligible condition threshold reached, followdby CPF0909 Ineligible condition threshold reached for pool 02.



I found the job but I don't why.

QYPSJSVR server job went to 3400 threads.



From: Steinmetz, Paul

Sent: Friday, May 24, 2013 3:27 PM

To: 'Midrange Systems Technical Discussion'

Subject: CPF0908 Machine ineligible condition threshold reached, followd by CPF0909 Ineligible condition threshold reached for pool 02.





Has anyone ever discovered how to determine which job or jobs may have caused the below condition. I get this once or twice a year.



I know its related to machine ineligible threshold, set at IPL to 255, the condition causes this to increase to 32,767.



I also know its related to jobs that may have many or spawn many threads.



You can't look at this value, internal only.







CPF0908 Machine ineligible condition threshold reached.



CPF0909 Ineligible condition threshold reached for pool 02.



http://www-912.ibm.com/s_dir/SLKBase.nsf/1ac66549a21402188625680b0002037

e/bd09e63c51bda91d86256d6c00698f3c?OpenDocument







Thank You



_____



Paul Steinmetz



IBM i Systems Administrator







Pencor Services, Inc.



471 Delaware Ave



Palmerton Pa 18071







610-826-9117 work



610-826-9188 fax



610-349-0913 cell



610-377-6012 home







psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx<mailto:psteinmetz@xxxxxxxxxx%3cmailto:psteinmetz@xxxxxxxxxx>>



http://www.pencor.com/





--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.





--

This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list To post a message email: MIDRANGE-L@xxxxxxxxxxxx<mailto: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<mailto:MIDRANGE-L-request@xxxxxxxxxxxx> Before posting, please take a moment to review the archives at http://archive.midrange.com/midrange-l.



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.