[OpenSIPS-Users] Quest to find memory leak
I am using OpenSIPS (2.1.5 (x86_64/linux)) in production. I observed private memory is decreasing constantly for one process mainly and ultimately leading to memory errors and crash. To debug this issue I prepared a test server and compiled opensips as per https://www.opensips.org/Documentation/TroubleShooting-OutOfMem I made only one single call (which was rejected by opensips as it was not authorized user) and I saw private free memory decreased. I was hoping since transaction is done ideally it should release memory and should show me same memory as startup but it did not. I verified this with many call attempts and i see free memory is always decreasing slowly. I used kill -SIGUSR1 to create memory dump. But i am unable to make sense of it. It shows log like ... r 6 07:29:19 Server3021 opensips[13276]: Memory status (pkg): Mar 6 07:29:19 Server3021 opensips[13276]: qm_status (0x7f5b8ebba010): Mar 6 07:29:19 Server3021 opensips[13276]: heap size= 4194304 Mar 6 07:29:19 Server3021 opensips[13276]: used= 346768, used+overhead=848792, free=3345512 Mar 6 07:29:19 Server3021 opensips[13276]: max used (+overhead)= 931920 Mar 6 07:29:19 Server3021 opensips[13276]: dumping all alloc'ed. fragments: Mar 6 07:29:19 Server3021 opensips[13276]: 0. N address=0x7f5b8ebef528 frag=0x7f5b8ebef4f8 size=40 used=1 Mar 6 07:29:19 Server3021 opensips[13276]: alloc'd from script_cb.c: add_callback(60) Mar 6 07:29:19 Server3021 opensips[13276]: start check=f0f0f0f0f0f0f0f0, end check= c0c0c0c0c0c0c0c0, abcdefedabcdefed Mar 6 07:29:19 Server3021 opensips[13276]: 1. N address=0x7f5b8ebef5b0 I pasted only few lines in this mail. What should be my next step?...How can i really trace what is wrong in my script or any other memory leak? ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +
+1 Thank you El 05/03/2017 a las 06:32, DanB escribió: Hi Jeff, Although it is a slippery ground, in order to have the question answered, I can claim having experience with both systems (we used to install CDRTool for customers and still have today installs running since like 8 years without issues). CDRTool (CDR rating system): * Written in php, works closely with db (eg: relies on it's query speed with some caching for parts of the rates) * Mature implementation, not much development changing the code over the years (other than bug fixes). * Simple rating definition and implementation. * Web interface for rates management as well as CDRs. * Designed around rating CDRs and maintaining account balance. CGRateS (OCS - online charging system): * Written in Go, caches almost all information in process, database agnostic (abstracts databases into interfaces), database speed does not influence the speed of calculations, built on micro-services with full asynchronous processing. * Still in Release Candidate when it comes to architecture, evolved a lot over the years, master should be always stable in terms of functionality since it runs in production environments (architecture part is not yet declared stable - you can expect it to still evolve). * Complex rating (rates voice calls, data streams, sms, etc) and accounting (unlimited number of balances/bundles and failover between them during a call). * API (JSON) driven management (full set) with no official web interface available yet. * Additional functionality: fraud detection with automatic mitigation (3 layers: accounts, CDR stats, resources usage), CDR logging with support for interim records, QoS LCR and LCR over bundels, real-time (complete in memory) call statistics with pattern monitoring and triggers/web hooks towards external systems, derive charging (session emulation - reseller/distributor scenarios, customer/supplier parallel calculations), performance optimized (one CGRateS instance should be able to handle 5k requests per second in terms of rating calculations), built-in high availability for Diameter setups. So these being said, it is all about the need vs price (time investment) you are ready to pay for it by using one system or another (considering both systems are opensource and you can extend yourself in one way or another). If you don't have complex rating requirements nor the need of increased CPS, I trust CDRTool will do the job just fine since it did it for us over the years (you get the advantage as said of simple management and architecture stability, quick learning curve). CGRateS on the other hand should be there if you decide you need more functionality/speed and you are also ready to offer it more time and efforts. I hope this helps someone! DanB ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
Re: [OpenSIPS-Users] CDRtool vs CGRATES for Opensips 2.2 +
Hi Jeff, Although it is a slippery ground, in order to have the question answered, I can claim having experience with both systems (we used to install CDRTool for customers and still have today installs running since like 8 years without issues). CDRTool (CDR rating system): * Written in php, works closely with db (eg: relies on it's query speed with some caching for parts of the rates) * Mature implementation, not much development changing the code over the years (other than bug fixes). * Simple rating definition and implementation. * Web interface for rates management as well as CDRs. * Designed around rating CDRs and maintaining account balance. CGRateS (OCS - online charging system): * Written in Go, caches almost all information in process, database agnostic (abstracts databases into interfaces), database speed does not influence the speed of calculations, built on micro-services with full asynchronous processing. * Still in Release Candidate when it comes to architecture, evolved a lot over the years, master should be always stable in terms of functionality since it runs in production environments (architecture part is not yet declared stable - you can expect it to still evolve). * Complex rating (rates voice calls, data streams, sms, etc) and accounting (unlimited number of balances/bundles and failover between them during a call). * API (JSON) driven management (full set) with no official web interface available yet. * Additional functionality: fraud detection with automatic mitigation (3 layers: accounts, CDR stats, resources usage), CDR logging with support for interim records, QoS LCR and LCR over bundels, real-time (complete in memory) call statistics with pattern monitoring and triggers/web hooks towards external systems, derive charging (session emulation - reseller/distributor scenarios, customer/supplier parallel calculations), performance optimized (one CGRateS instance should be able to handle 5k requests per second in terms of rating calculations), built-in high availability for Diameter setups. So these being said, it is all about the need vs price (time investment) you are ready to pay for it by using one system or another (considering both systems are opensource and you can extend yourself in one way or another). If you don't have complex rating requirements nor the need of increased CPS, I trust CDRTool will do the job just fine since it did it for us over the years (you get the advantage as said of simple management and architecture stability, quick learning curve). CGRateS on the other hand should be there if you decide you need more functionality/speed and you are also ready to offer it more time and efforts. I hope this helps someone! DanB ___ Users mailing list Users@lists.opensips.org http://lists.opensips.org/cgi-bin/mailman/listinfo/users
