Abdul, Hi, if you are at 95-100% constantly – that will not be ONAP – even on an 8 vCore you will see a max of 50-90% - if you see 95-100 – then it is https://jira.onap.org/browse/OOM-806 - and if your network is public facing – as Roger says – lock down ports 10249-10255, do a “top” first, hit c and verify you are compromised. Use the port lockdown ACL in the Azure template as a guide below https://gerrit.onap.org/r/#/c/33527/9/install/azure/arm_deploy_ons_sut.json
For the full HD – you should be able to run for weeks - I have a 120G drive. For reference amsterdam will not breach 64G – you should hover between 51 and 55. – Beijing has this issue periodically because the odd container will consume 10G – we are working on limiting the profile for an individual container – out of the box each container thinks it has the whole VM. thank you /michael From: [email protected] [mailto:[email protected]] On Behalf Of Roger Maitland Sent: Monday, March 26, 2018 09:55 To: [email protected]; [email protected] Subject: Re: [onap-discuss] ONAP on Kubernetes I suspect you’ve come across two, possibly three, different issues: * Memory leaks within the containers of (potentially) several projects: There already are several Jira bugs open against suspected memory leaks: SDC-1092<https://jira.onap.org/browse/SDC-1092>, DCAEGEN2-198<https://jira.onap.org/browse/DCAEGEN2-198>, PORTAL-211<https://jira.onap.org/browse/PORTAL-211>, and VID-196<https://jira.onap.org/browse/VID-196>. If you’ve found memory leaks outside of these components please raise a Jira bug against the appropriate project. Note that stability is an important part of the Beijing release and many of the teams have reworked their components so hopefully the leaks have been addressed. Please keep watch as the new code is made available. * Likely log files are consuming all of the available storage. Log rotation needs to be implemented across all of ONAP to ensure that the storage volumes aren’t consumed over time. Again, if you can track the problem down to a specific component please raise a Jira bug. * If your system is available to internet you may find that it is being used to mine bitcoin. Unfortunately, some Kubernetes systems are being attacked this way so you’ll want to watch your system closely. The ONAP team is working to address this issue. Thank you for your observations – this is how we make ONAP production grade. Cheers, Roger From: <[email protected]<mailto:[email protected]>> on behalf of "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Date: Saturday, March 24, 2018 at 5:54 AM To: "[email protected]<mailto:[email protected]>" <[email protected]<mailto:[email protected]>> Subject: [onap-discuss] ONAP on Kubernetes Hi, I deploy a minimum ONAP Amsterdam on Kubernetes, using a 64 GB RAM + 8 vCPU or 16 vCPU. The starting RAM utilization is around 30--40 GB RAM. After one or two days, all the cpu cores reach 100%, and i reboot the VM, to be able to have some responsive feedback. Sometimes, the HDD is full, and i have to reset the VM and redploy from scratch. What is the reason for saturating all the CPU cores, or the RAM ? Is there something I can do to minimize this behaviour ? should I use the Master Branch instead of Amsterdam ? Thanks. A. Seaudi _________________________________________________________________________________________________________________________ Ce message et ses pieces jointes peuvent contenir des informations confidentielles ou privilegiees et ne doivent donc pas etre diffuses, exploites ou copies sans autorisation. Si vous avez recu ce message par erreur, veuillez le signaler a l'expediteur et le detruire ainsi que les pieces jointes. Les messages electroniques etant susceptibles d'alteration, Orange decline toute responsabilite si ce message a ete altere, deforme ou falsifie. Merci. This message and its attachments may contain confidential or privileged information that may be protected by law; they should not be distributed, used or copied without authorisation. If you have received this email in error, please notify the sender and delete this message and its attachments. As emails may be altered, Orange is not liable for messages that have been modified, changed or falsified. Thank you. This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer This message and the information contained herein is proprietary and confidential and subject to the Amdocs policy statement, you may review at https://www.amdocs.com/about/email-disclaimer <https://www.amdocs.com/about/email-disclaimer>
_______________________________________________ onap-discuss mailing list [email protected] https://lists.onap.org/mailman/listinfo/onap-discuss
