|
Well, that could be irritating. When you dump the process are you using SST (STRSST, and subsequent options)? Also doing wrkactjob, finding job, option 5 and then option 20 and then option 10 on thread running shows nothing (is that what you were saying below with "impossible to show the thread info...")? Is there other activity on the system - perhaps activity which runs at a better priority that WAS (WAS runs at priority 25 by default) at the time or just prior to when the CPU usage spikes? Maybe large database activity form the app server itself? Anything in the WAS log files at the time of CPU usage spike? Have you noticed if the number of threads decreases to 2 (one, the main/first thread, waiting and a second thread running), when you do the endjob? Are you up to date on all other PTFs (3.5.6 is of course the latest level of WAS)? Frances Stewart WebSphere Application Server for iSeries 400 IBM Rochester Dieter.Bender@t-o nline.de (Dieter To: java400-l@midrange.com Bender) cc: Sent by: Subject: Re: Infinite loop? java400-l-admin@m idrange.com 12/22/2002 02:52 PM Please respond to java400-l Frances, On Sunday 22 December 2002 15:29, you wrote: > Ito might be that the garbage collector has kicked in for some reason (such > as alot of stuff to collect) and is trying to cleanup. I have seen sone > case where the job appeared like it would not end, but in actuality it took > to 14 hours, because the collector was returning heap to the system (that > is the simplified form of what was happening). > > A process dump of all the threads (or the single thread) when the job is > consuming the CPU would show whether it was the garbage collector or not, > and also would show the stack for the thread in question. Have done a the dump fails with timeout and it's impossible to show the thread information with the same problem. > WRKSYSSTS to see if storage is being returned (i.e. percent used is going > down) or if there is an inordinate amount of paging etc. going on in the > storage pool in which WAS runs? no paging, no consumption of storage. > > What I would recommend ideally is that you talk to IBM Support about the > problem and get things setup so that when the problem occurs (hopefully > during normal working hours), IBM Support can get on the system and debug > the problem. And here starts my problem, we are in germany and ibm support tells that there must be a problem with the application and WAS performs fine. And they are telling we should write a little program wich makes the problem reproducable. Dieter > > Frances Stewart > WebSphere Application Server for iSeries 400 > IBM Rochester > > > > > Dieter.Bender@t-o > nline.de (Dieter To: > java400-l@midrange.com Bender) cc: > Sent by: Subject: Infinite loop? > java400-l-admin@m > idrange.com > > > 12/22/2002 04:39 > AM > Please respond to > java400-l > > > > > > Hi, > > we use WebSphere 3.5.6 running on as400 V5R1; > from time to time CPU usage reaches near 100% all used by one thread of the > application server. Nobody is working with the application and only > PWRDWNSYS > *immed brings down WebSphere. It's impossible to end the server from the > WepSphere console, or to stop it in another way. Neither endjob, normal or > abnormal, nor endsbs kills WebsFear. > It looks like an infinite loop, maybe in the JIT compile. CRTJVAPGM to > clearify this is a little bit complicated, beacause we use JSPs and it is > running hours to days. > The problem doesn't occur running WebSphere on another box (NT). > > any ideas? -- mfG Dieter Bender DV-Beratung Dieter Bender Wetzlarerstr. 25 35435 Wettenberg Tel. +49 641 9805855 Fax +49 641 9805856 www.bender-dv.de _______________________________________________ This is the Java Programming on and around the iSeries / AS400 (JAVA400-L) mailing list To post a message email: JAVA400-L@midrange.com To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/cgi-bin/listinfo/java400-l or email: JAVA400-L-request@midrange.com Before posting, please take a moment to review the archives at http://archive.midrange.com/java400-l.
As an Amazon Associate we earn from qualifying purchases.
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.