|
Frances, I've forgotten to mention: I've used DMPJVM for the dump Dieter On Monday 23 December 2002 04:15, you wrote: > 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
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.