Hi Richard,
If not too much for you, I would really like to see the backtrace - even
under OS stress conditions, OpenSIPS should NOT crash.
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 16.09.2016 13:15, Richard Robson wrote:
Hi Bogdan,
It looks like it was the extra logging we were putting in using xlog.
We'd added them while we were developing the script and left them in.
this was causing systemd-journald to max out the box and would
segfault the opensips, which restarted. journald was using 90% of the
box and opensips 10%
I've taken out the xlogs ( there was about 20 per iteration of the
script) and using sipp i've tested throughput to 250cps and 2000
concurrent calls. (enought to kill the asterisk processing the calls
the other side)
Unfortunately i deleted all the core files as the filled the disk up.
If you still want one I'll be able to reproduce it as I've still got
the script. I seem to remember though that it was the transaction
module that was the culprit
Regards,
Richard
On 14/09/2016 15:28, Bogdan-Andrei Iancu wrote:
Hi Richard,
Have you managed to get a corefile and extract a backtrace ?
Best regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
http://www.opensips-solutions.com
On 06.09.2016 17:07, Richard Robson wrote:
If its any help, I can see packets coming in particularly BYEs that
are not being processes at high call rates and are not getting to
the point in the script where the rtpengine_delete is being
triggered. this then causes the number of concurrent calls on the
RTPengine to grow and fill its allocation of ports. This then stops
calls being made. and the opensips then crashes.
-------- Forwarded Message --------
Subject: 2.2.1 crashing
Date: Tue, 6 Sep 2016 13:45:11 +0100
From: Richard Robson <rrob...@greenlightcrm.com>
Organisation: Greenlight Innovation
To: OpenSIPS users mailling list <users@lists.opensips.org>
During testing we are ramping up sipp to give ~100 CPS between internal
servers and opensips crashes with a seg fault
sipp -sn uac 192.168.36.141:5060 -s 441382250180 -r 1 -rp 1000
-recv_timeout 7500 -send_timeout 7500 -d 5000
the sipp calls are being routed to an asterisk server, which is playing
audio
Calls are going via an RTPengine on a different box
everything is on CENTOS 7.2
I'm using the latest git of 2.2.1 on a virtual host 8 cores and 8GB
its OK up to around 60 CPS (350 calls) but ramping up to 100 CPS (750
concurrent calls) causes the segfault.
we are seeing the systemd-journal being the heaviest CPU user, but not
sure if this is unrelated
here is the backtrace:http://pastebin.com/SjaSJx7w
--
Richard Robson
Greenlight Support
01382 843843
supp...@greenlightcrm.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
--
Richard Robson
Greenlight Support
01382 843843
supp...@greenlightcrm.com
_______________________________________________
Users mailing list
Users@lists.opensips.org
http://lists.opensips.org/cgi-bin/mailman/listinfo/users