Hi, I don’t think the output you’ve put below shows that there’s only 6% free memory. You want the value in the -/+ buffers/cache (which includes memory that Linux is using for disk caching, but can be taken by applications if they need more memory).
There’s possibly a memory leak somewhere though, as you had 3820636 available after the restart compared to 3630472, but it’s not as severe as you might think. To track down the memory leak, you can run Bono under a profiling tool (we use massif – see http://clearwater.readthedocs.io/en/stable/Debugging_Bono_Sprout_and_Homestead_with_GDB_and_Valgrind.html for more details). Also, it’s worth noting that we wouldn’t typically expect Bono to be used in a production environment. We’d normally deploy Clearwater with Perimeta (http://www.metaswitch.com/perimeta-session-border-controller-sbc) rather than Bono. Ellie From: Clearwater [mailto:[email protected]] On Behalf Of Gerard Ratcliffe Sent: 04 October 2016 03:18 To: [email protected] Cc: Rene Anino; Bill Clemens; Richard Lawrence Subject: [Project Clearwater] ibcf (bono) VM using up a lot of memory Hi, This is my first post on this forum I am also new to Clearwater IMS. In fact I am babysitting our Clearwater IMS while our developer is on leave. We have a manual install of bono/sprout/homestead/ibcf/dns being used as an interface between Voip UE’s and a PSTN, running on 5 VM’s. They are connected via a private virtual switch, and only the bono and ibcf nodes are connected to an external network interface for external sip signalling. This setup is working with no problems. At present we have four of these IMSs setup. Two of them in test sites (one for us one for the customer) and two in production sites. Only one production site is carrying live traffic. Last week I got an alert to say that one of the production ibcf VMs was running out of free memory. Fortunately this was on the production IMS that was not carrying live traffic. My colleague had warned me that the VMs were slowly using up memory and that I should check them periodically to make sure that the free memory was not getting to low. The ibcf free memory was down to less than 6%. I restarted the VM and this sorted out the problem. I also checked the other VMs in the both the production IMSs and they were all above 30%. At this point I thought that the problem had been resolved. However, today we received the same alaert for the ibcf VM. Once again, the VM, was down to less than 6% free memory. [bono]nec@ibcf:~$ free total used free shared buffers cached Mem: 4041496 3809652 231844 224 151596 3247032 -/+ buffers/cache: 411024 3630472 Swap: 2093052 320 2092732 [bono]nec@ibcf:~$ I restarted the VM again and this dropped the free memory back to about 90% [bono]nec@ibcf:~$ free total used free shared buffers cached Mem: 4041496 386116 3655380 444 14528 150728 -/+ buffers/cache: 220860 3820636 Swap: 2093052 0 2093052 [bono]nec@ibcf:~$ I have attached a file with some of the checking that I did before and after the restart. Has anyone else experienced this problem and are there any checks that can be done to try and isolate the leaky process. Regards, Gerard Gerard Ratcliffe Technical Specialist NEC New Zealand Limited NEC House, Level 6, 40 Taranaki Street, PO Box: 1936, Wellington 6011, New Zealand T: 043816235, M: 0275037273, F: +6443811110 [email protected]<mailto:[email protected]> nz.nec.com<http://nz.nec.com> [cid:[email protected]] Please consider the environment before printing this email Attention: The information contained in this message and or attachments is intended only for the person or entity to which it is addressed and may contain confidential and/or privileged material. Any review, retransmission, dissemination, copying or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any system and destroy any copies. NEC has no liability for any act or omission in reliance on the email or any attachment. Before opening this email or any attachment(s), please check them for viruses. NEC is not responsible for any viruses in this email or any attachment(s); any changes made to this email or any attachment(s) after they are sent; or any effects this email or any attachment(s) have on your network or computer system.
_______________________________________________ Clearwater mailing list [email protected] http://lists.projectclearwater.org/mailman/listinfo/clearwater_lists.projectclearwater.org
