When you start having swap space you need to understand the difference between "available" and "in use".
I've always understood that when swap becomes "in use", you would begin to experience performance degradation related to the percentage "in use". Hope that your changes work out for you, looks interesting. Nice that it shows no swap in use. ============================ Tony Graziano, Manager Telephone: 434.984.8430 Fax: 434.984.8431 Email: tgrazi...@myitdepartment.net LAN/Telephony/Security and Control Systems Helpdesk: Telephone: 434.984.8426 Fax: 434.984.8427 Helpdesk Contract Customers: http://www.myitdepartment.net/gethelp/ ----- Original Message ----- From: Robert B <d...@spudland.com> To: Tony Graziano <tgrazi...@myitdepartment.net> Cc: sipx-users@list.sipfoundry.org <sipx-users@list.sipfoundry.org> Sent: Sat Nov 21 12:07:42 2009 Subject: Re: [sipx-users] Question regarding resource usage... Tony, Okay -- working theory here. The thing in my environment which is "different" is that I am using OpenVZ. I started running into issues with *fresh* installs immediately failing on service start-up. All kinds of Java JVM memory allocation errors. First of all, with Sun's java is executed, if it sees more than 2GB of resources it will run in "server" mode instead of "client" mode, allocating all kinds of memory it doesn't need -- and will start to throw up if it can't allocate memory. If the sipXecs Wiki is easily editable, I am going to add this because it could be valuable. To fix this first issue, change your jvm.cfg file as shown. You'll comment the first line which tells java to assume server mode IF_SERVER_CLASS is true. After that, you'll add a new line that just says that client mode is client mode, don't switch to server mode. Leave the rest of the file as-is. #-client IF_SERVER_CLASS -server -client KNOWN -server KNOWN -hotspot ALIASED_TO -client -classic WARN -native ERROR -green ERROR Second issue, and this is related to OpenVZ... Since it's a container "virtualization" platform, there are some things it can and cannot do. One of those being swap space. A container does not have its own swap space. Everything appears as "real" memory in top and free: total used free shared buffers cached Mem: 2097152 1868740 228412 0 0 0 Swap: 0 0 0 But because the java processes appear to have both VIRT and RES memory allocated, all of this is winding up real memory! The java processes' VIRT memory alone are using 1.5GB. Astounding if true. So to get around this weirdness (obviously I can't run multiple sipXecs installs if every one of them needs 2gb of physical RAM without the price going up rapidly), with OpenVZ I can provide it with physical RAM and swap space on the host system. This, in turn, gets presented as physical RAM to the container. I've successfully got sipXecs running with 256mb of RAM plus 1792mb of swap, making the sipXecs container thing it has 2048mb of physical RAM. So far, everything works fine. Now, I am not an expert with this stuff so everything I wrote above is probably totally wrong... :) Please correct me if that's the case, I really want this to work and am anxious to learn more. -- Robert Tony Graziano wrote: > The voicemail/media server aspect can be very heavy from a resources > standpoint. Work is ongoing in 4.1 to replace the current voicemail > system (will then utilize freeswitch), which should provide lighter > resource usage "I think". > _______________________________________________ sipx-users mailing list sipx-users@list.sipfoundry.org List Archive: http://list.sipfoundry.org/archive/sipx-users Unsubscribe: http://list.sipfoundry.org/mailman/listinfo/sipx-users sipXecs IP PBX -- http://www.sipfoundry.org/
