Re: Runaway Java Processes
Ken Schweigert <[email protected]> Thu, 27 Jul 2006 13:27:13 -0400
| Newsgroups | gmane.comp.web.webobjects.admin |
|---|---|
| Message-ID | <[email protected]> |
On Jul 27, 2006, at 11:52 AM, Sacha Michel Mallais wrote: > On Jul 27, 2006, at 8:33 AM, Ken Schweigert wrote: > >> We are having a problem with one of our WO applications. I'm >> hoping someone will have some guidance as to what to do. I have a >> lot of symptoms, but no real idea where to go next. >> >> The machine is running on MacOSX-10.3.5 with WO-5.2. We run 5 >> instances of it and about 3 or 4 weeks the application becomes >> unresponsive. We also host a few other applications that never >> seem to have this problem. When is 'ssh' in to the machine and do >> 'top' I see: > > I was just talking about this in another thread: it is normal to > regularly schedule your apps to restart or a regular basis. You > might start with that. I've tried scheduling the instances to restart, but usually get a case where something in the instances "hangs" and the instance stays in a state of "refuse new instances" and then all of them are like that and then the application is unreachable. I would schedule each instance a couple of hours apart hoping that by the time next next instance restarts, the previous one would've closed down and restarted. > > >> While reading the 'top' documentation I see that when the '#TH' >> column has a '>>' that it has more than 99 threads and when >> '#PRTS' has a '>>>' that there are more than 999 ports. I find >> this a little excessive seeing that none of the other applications >> use this many resources. > > It is excessive. You should only see that under two conditions: > 1) your app is being hit that many times at the same time > 2) worker threads are getting locked up so that WO has to spawn > more of them > > Assuming its #2, one way to determine where the deadlock is > occurring is to send the process a QUIT signal, as in "kill -QUIT > <pid>". This will tell java to spew out a stack trace. > Unfortunately, this stack trace is sent to /dev/null by default, so > you'll have to edit the startup script SpawnOfWotaskd as described > under "Where's my stderr" on this page: http://en.wikibooks.org/ > wiki/Programming:WebObjects/Web_Applications/Deployment/ > Common_Pitfalls_and_Troubleshooting. Great tip! I just modified that startup script and am in the process of restarting the application's instances. I'm sure I'll be able to 'kill' and instance soon. > > >> I can also verify that each of the java processes with a '>>>' is >> a process of the same application. I used 'lsof -i -n -P | grep >> java | less' and can see that associated tcp port with the one set >> in the application. Also scattered throughout the runaway >> process's output I see quite a few of these lines: >> >> COMMAND PID USER FD TYPE DEVICE SIZE/OFF NODE NAME >> <snip> >> java 19994 root 181u IPv6 0t0 TCP can't >> read in6pcb at 0x00000000 >> java 19994 root 182u IPv6 0t0 TCP can't >> read in6pcb at 0x00000000 >> >> Another thing that also concerns me is the 'VSIZE' column having >> one instances with 1.12GB and another with 942MB. > > Probably related to the number of worker threads. Just killed an instance and noticed that the free memory shot way up. -- Ken Schweigert, Network Administrator Byte Productions, LLC