Java does have a garbage collection process and should never consume all physical memory unless there is a leak....of course leaks seem to be the all too common in java apps.
Java does not release the memory it has assigned for heap...but virtual memory used by the jvm should be released with the normal garbage collection process. I'm not sure if we set the Xmx heap size but the defualt was 64MB for a long time. Perhaps sipx is setting the Xmx value so high that it essential is set to consume all your memory. I'd be interested in knowing if we look at a top of the different process and see if screenshot you have is reporting VIRT memory or RES memory. What jvm version do you have? I know there was an known leak in java.io that was recently fixed. -M >>> On 11/23/2010 at 10:33 AM, in message >>> <aanlktimii38dcxkmle2+ytwzlafcjg87a+mjhtklk...@mail.gmail.com>, Tony >>> Graziano <tgrazi...@myitdepartment.net> wrote: that is JAVA, This is considered normal. Java will consule the entire memory available, it never releases it. That is how java functions. Actually, it became so alarming someone took out the MEMORY graphs because it bothered so many people that they had to remove it to stop people from asking the same things over and over. Java, as a "process" never gives up ram once it is consumed. It makes it available to itself as needed. The only time you should "worry" is when you start to consume SWAP. On Tue, Nov 23, 2010 at 10:28 AM, Matthew Kitchin (public/usenet) <mkitchin.pub...@gmail.com> wrote: I'm running I'm running sipXconfig (4.2.1-018971 2010-08-17T02:20:18 build20) 64 bit ISO build. I rebooted last night to resolve a java/CPU issue. There have been several threads started related to the high memory usage in Sipx 4.2.1 . I was looking at the performance graphs for the server since the reboot. I noticed something interesting. Take a look at the attached screenshot. I normally hate screenshots, but I couldn't find a better way to show it in this case. My backups run at midnight. It is very obvious in the CPU, memory, and IO graphs when it runs. The interesting thing to me is, the memory utilization doesn't drop at all after the backup is done. CPU and IO both drop back down to normal, but memory never does. The current TOP output is below. Does anyone else see this behavior? Should it be expected? Thanks, Matthew [r...@nshpbx1 ~]# top top - 09:26:16 up 15:18, 1 user, load average: 0.42, 0.28, 0.22 Tasks: 145 total, 1 running, 144 sleeping, 0 stopped, 0 zombie Cpu0 : 0.3%us, 0.3%sy, 0.0%ni, 99.3%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu1 : 1.3%us, 0.7%sy, 0.0%ni, 97.0%id, 0.3%wa, 0.0%hi, 0.7%si, 0.0%st Mem: 8177072k total, 4201668k used, 3975404k free, 232092k buffers Swap: 6289436k total, 0k used, 6289436k free, 2669936k cached PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND 4168 sipxchan 18 0 2414m 312m 12m S 0.0 3.9 5:33.36 java 4670 sipxchan 18 0 2334m 201m 9720 S 0.0 2.5 0:03.07 java 5041 sipxchan 18 0 2351m 130m 9860 S 0.3 1.6 0:46.81 java 5142 sipxchan 18 0 2339m 120m 9764 S 1.3 1.5 2:39.42 java 4942 sipxchan 20 0 2331m 68m 9792 S 0.0 0.9 0:32.61 java 4633 sipxchan 21 0 2318m 57m 9488 S 0.0 0.7 0:00.89 java 4915 sipxchan 21 0 2324m 50m 11m S 0.0 0.6 0:00.86 java 5452 sipxchan 15 0 277m 42m 5184 S 0.0 0.5 2:39.43 sipXproxy 4787 sipxchan 15 0 103m 23m 3036 S 0.0 0.3 0:07.32 ruby 3786 sipxchan 15 0 99.6m 23m 2724 S 0.0 0.3 0:01.32 sipxconfig-agen 4566 sipxchan 18 0 274m 23m 5360 S 0.0 0.3 0:05.30 freeswitch 4776 sipxchan 15 0 65208 16m 2224 S 0.0 0.2 0:02.22 mrtg 7056 root 34 19 251m 15m 2116 S 0.0 0.2 0:00.41 yum-updatesd 4856 sipxchan 15 0 228m 15m 3240 S 0.0 0.2 0:42.58 sipxrls 13730 postgres 15 0 122m 15m 10m S 0.0 0.2 2:57.91 postmaster 3730 sipxchan 18 0 262m 14m 6188 S 0.0 0.2 0:00.61 sipxsupervisor 13729 postgres 15 0 123m 14m 10m S 0.0 0.2 1:54.23 postmaster 13728 postgres 15 0 122m 13m 9900 S 0.0 0.2 0:23.49 postmaster 6652 root 18 0 48980 13m 1436 S 0.0 0.2 0:00.01 miniserv.pl 4721 sipxchan 18 0 247m 13m 4368 S 0.0 0.2 1:32.57 sipregistrar 7137 postgres 15 0 120m 12m 9m S 0.0 0.2 1:40.42 postmaster 2577 root 15 0 170m 12m 4288 S 0.0 0.2 0:36.86 snmpd 4416 sipxchan 18 0 254m 11m 3932 S 0.0 0.1 1:05.26 sipxpresence 5079 postgres 16 0 119m 11m 9m S 0.0 0.1 6:19.56 postmaster 3915 sipxchan 18 0 275m 11m 4036 S 0.0 0.1 0:18.81 sipxacd 5482 postgres 15 0 118m 11m 9.9m S 0.0 0.1 0:00.71 postmaster 5379 postgres 15 0 118m 11m 9.9m S 0.0 0.1 0:00.28 postmaster 7138 postgres 15 0 120m 10m 7736 S 0.0 0.1 0:01.25 postmaster 4120 sipxchan 18 0 210m 8552 3996 S 0.0 0.1 1:48.15 sipstatus 2705 postgres 15 0 118m 6932 6412 S 0.0 0.1 0:00.04 postmaster 7134 postgres 15 0 119m 6736 4580 S 0.0 0.1 0:00.23 postmaster 2969 root 18 0 115m 5952 2876 S 0.0 0.1 0:00.06 hpsmhd 6638 root 19 0 24936 5788 4752 S 0.0 0.1 0:00.04 vcagentd 4600 sipxchan 18 0 122m 5116 2980 S 0.0 0.1 0:00.50 sipxpark _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/ -- ====================== Tony Graziano, Manager Telephone: 434.984.8430 sip: tgrazi...@voice.myitdepartment.net Fax: 434.326.5325 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 sip: helpd...@voice.myitdepartment.net Helpdesk Contract Customers: http://support.myitdepartment.net Linked-In Profile: http://www.linkedin.com/pub/tony-graziano/14/4a6/7a4
_______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users/
