On Wed, Apr 14, 2010 at 3:45 PM, Worley, Dale R (Dale) <[email protected]> wrote: > After the fiasco we had with a Java process core-dumping on scstrial.ca, I've > been thinking about a way to prevent such things from happening again: > > Limit the virtual memory (VSS) of every sipXecs process to, e.g., 10%, of the > RAM on the server. Then, if the process core-dumps, it is prevented from > putting the system into thrashing. > > In order to investigate this, I did a 'ps' of the sipXecs processes on > scstrial.ca to see how large the sipXecs processes are under normal > circumstances. Unfortunately, many of them are over 100Mb. (The results are > attached, and are also available as paradise:/home/Supoprt/dworley/ps.txt.) > The biggest processes are Java: > > VSZ RSS > 717580 321968 java -classpath > /usr/share/java/sipx-jasperreports-deps/jasperreports.jar:... > 653656 134024 java -server -classpath > /opt/openfire/.install4j/i4jruntime.jar:... > 590456 51276 java -cp /usr/share/java/sipXecs/sipXrest/sipxrest.jar:... > 583360 40628 java -cp /usr/share/java/sipXecs/scsimbot/scsimbot.jar:... > 582284 38816 java -cp /usr/share/java/sipXecs/sipXbridge/sipXbridge.jar:... > 579412 35748 java -cp > /usr/share/java/sipXecs/sipXprovision/sipXprovision.jar:... > 575292 31512 java -cp /usr/share/java/sipXecs/sipXivr/sipXivr.jar:... > 574396 27604 java -cp /usr/share/java/sipXecs/sipXpage/sipXpage.jar:... > 569728 24240 java -cp > /usr/share/java/sipXecs/sipXrecording/sipXrecording.jar:... > > But many of the C++ processes seem to be larger than they should be as well: > > 170804 20876 /usr/bin/sipxsupervisor > 152080 97052 /usr/bin/sipregistrar > 132092 68244 /usr/bin/sipXproxy > 107428 49292 /usr/bin/sipxrls > > I suspect that there are memory leaks. > > Comments?
Did you do a periodic memory profiling to see if the memory sizes are stable over time? Java is unfortunately a memory hog but I thought the IBM JVM had some provision for memory sharing of loaded class objects. Obviously, the best thing to do here would be a Java container for Java services but apparently it is no longer a goal of ours to do this. Ranga > > Dale > > _______________________________________________ > 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/ > -- M. Ranganathan _______________________________________________ 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/
