> > > On Mar 9, 2010, at 1:16 PM, Robert Joly wrote: > > > Mardy wrote: > >> > >> > >> On Mar 9, 2010, at 10:07 AM, Robert Joly wrote: > >> > >>> Hi guys, > >>> I have been investigating XX-7634 which reports high CPU > >> utilization > >>> by java processes after an ISO install of the commercial > >> version (SCS) > >>> which uses the IBM JVM. > >>> > >>> Basically, after an ISO install I'm seeing that *all* the > >> java-based > >>> processes chew up between 50% and 100% of one processor and > >> remained > >>> like that for as long as I kept the box up (few hours). > >> The processes > >>> in question are sipXpage, sipXivr, sipXrelay, sipXconfig, > >> sipXrest and > >>> sipXprovision. Using jconsole I was able to find that the > >> hot thread > >>> for each of these services is called 'Attach Handler' > >>> (com.ibm.tools.attach.javaSE.AttachHandler.run()) and I > also found > >>> that I can eliminate the high CPU condition completely on a fresh > >>> install by hand-editing the launch command for each of these java > >>> processes to add the following property: > >>> -Dcom.ibm.tools.attach.enable=no > >>> > >>> If I add this property then all the processes are > >> well-behaved but I > >>> do not understand the fundamental reason why the hot thread > >> is there > >>> in the first place. I'm therefore turning to the Java gods > >> that are > >>> tuned in to this list to see if they had previous > >> encounters with this. > >>> > >>> Thanks in advance, > >>> bob > >> > >> I would like to know why this issue has all of a sudden > shown up on > >> the radar. The Attach API and supporting AttachHandler thread was > >> introduced, as a result of an upgrade to the IBM JVM, back on > >> 2009-11-14 Is it possible that the high CPU utilization has been > >> there since then but no one had noticed it until now? > > > > Refresh my memory, will you? Why are we using IBM in the > first place? > > Initially because it was the only option for supporting one > of our customers. In addition, we have discovered that it > offers some very attractive memory optimization features not > offered by other JVM's that we may need to employ as the > number of Java based services increase. > > > > > I do not know when the high CPU behavior started showing up > but it was > > first reported on 2010-02-10. Also, not every system exhibits the > > behavior. For example, our friends at Qantom can I can > reproduce the > > problem but Al Campbell and Chris Parfitt cannot on their systems. > > I'm using a Dell R300 and Qantom is using Dell Optiplex and > so do Al > > and Chris. I have not identified the ingredient that makes > this hot > > thread appear and as far as I can tell, IBM does not publish the > > source code for their attach implementation. > > > > The thread seems to be looping around waiting for a > semaphore. Please > > see the attached screenshot for visual of the stacktrace. > > > > Is this actually causing a problem or is it just a red > herring? If it is in fact impacting the performance of the > system, then disable it.
Here's a sample of top running on a bad system. This is running on a quad-core machine and 60% of it is spent in the kernel and 17% spent in user space. I'm not sure which way the priorities go but I'm hoping that the processes with lower number have higher priority... Would you agree that this is a problematic case? top - 11:05:46 up 23:09, 5 users, load average: 6.50, 4.77, 2.73 Tasks: 152 total, 1 running, 151 sleeping, 0 stopped, 0 zombie Cpu(s): 16.7%us, 60.0%sy, 0.0%ni, 22.3%id, 0.2%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 3364260k total, 1466508k used, 1897752k free, 263108k buffers Swap: 6289436k total, 0k used, 6289436k free, 695976k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 18381 sipxchan 20 0 572m 38m 6668 S 55 1.2 2:03.52 java.bin 18326 sipxchan 18 0 576m 39m 6740 S 54 1.2 2:09.99 java.bin 17282 sipxchan 18 0 566m 36m 6716 S 53 1.1 2:18.23 java.bin 18024 sipxchan 20 0 582m 52m 6556 S 51 1.6 1:56.34 java.bin 18090 sipxchan 19 0 573m 36m 6508 S 50 1.1 1:48.57 java.bin 18023 sipxchan 18 0 687m 196m 9.8m S 45 6.0 2:15.62 java.bin 17845 sipxchan 15 0 28868 14m 4764 S 1 0.4 0:00.42 freeswitch 17029 sipxchan 15 0 145m 7504 5280 S 0 0.2 0:00.08 sipxsupervisor 17320 sipxchan 15 0 30708 3724 3132 S 0 0.1 0:00.02 sipstatus 17475 sipxchan 15 0 37956 4808 4024 S 0 0.1 0:00.02 sipxrls 17595 sipxchan 15 0 25212 11m 2532 S 0 0.3 0:00.20 sipxconfig-agen 17615 sipxchan 15 0 15340 3964 3452 S 0 0.1 0:00.01 sipxacd 17616 sipxchan 15 0 69780 5048 4120 S 0 0.2 0:00.05 sipxpark 17758 sipxchan 15 0 33816 4736 3992 S 0 0.1 0:00.01 sipxsaa 17806 sipxchan 25 0 12128 10m 1828 S 0 0.3 0:00.16 mrtg 17855 sipxchan 15 0 69416 5148 4008 S 0 0.2 0:00.06 sipxpresence 17911 sipxchan 15 0 26132 12m 2860 S 0 0.4 0:00.21 ruby 18044 sipxchan 15 0 44552 4724 3708 S 0 0.1 0:00.03 sipregistrar 18195 sipxchan 15 0 10120 1980 620 S 0 0.1 0:00.00 httpd 18196 sipxchan 15 0 10120 1980 620 S 0 0.1 0:00.00 httpd 18197 sipxchan 15 0 10120 1980 620 S 0 0.1 0:00.00 httpd 18198 sipxchan 17 0 10120 1980 620 S 0 0.1 0:00.00 httpd 18199 sipxchan 16 0 10120 1980 620 S 0 0.1 0:00.00 httpd 18637 sipxchan 15 0 38652 5676 4388 S 0 0.2 0:00.03 sipXproxy _______________________________________________ sipx-dev mailing list [email protected] List Archive: http://list.sipfoundry.org/archive/sipx-dev Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-dev sipXecs IP PBX -- http://www.sipfoundry.org/
