Limitations of asterisk Mini HTTP web server

Asterisk Asterisk WebRTC
1

Using asterisk 16.20 on a debian 10 machine with 8cpu’s and 16GB of memory we are experiencing frequent crashes of asterisk.

We tried to enable the “Don’t Optimize” , “Compile-Double” to have core dumps however we saw a very high cpu usage with very low load of calls and after a while asterisk crashes. So we had to revert everything again.

We are suspecting the mini HTTP web server since we have now more and more WebRTC connections added day by day. and before we did not have this issue.

Is there a limit / suggested (other than sessionlimit) of connections the internal web server can have in terms of number of connections or load it can handle ? Can this cause asterisk to crash completely ?

2

Noone has stress tested it, but there haven’t been any crash reports relating to the HTTP server. It’s all fairly small and simple.

Any code that has an issue in Asterisk can cause a crash. You have to actually examine the backtrace[1] in order to see where it is crashing.

[1] Getting a Backtrace - Asterisk Project - Asterisk Project Wiki

3

We tried to get a core dump by enabling the options “Don’t Optimize” , “Compile-Double” and “Dumpcore” but when we do this, asterisk consumes a lot of CPU even under low load and eventually crashes.

4

I don’t know what “Dumpcore” means. That’s not an option. Without a backtrace you can continue guessing.

5

dumpcore = yes ; Dump core on crash (same as -g at startup).
The option is located in asterisk.conf file

6

Ah. Well, without an actual backtrace then I can’t really help you I’m afraid.

7

Yes I clearly understand we are going blind in here, we will try again but the problem is the high consumption of cpu when we enable these options to have the core dumps.

8

COMPILE_DOUBLE was new to me, but it looks like the net effect on the code produced, and therefore run time performance, is the same as DONT_OPTIMISE, so you can ignore it here. It seems to be there for better compile time, not run time, diagnostics.

If you rapidly exceed CPU capacity with DONT_OPTIMISE, you were already running too close to the performance envelope, as I don’t think the Asterisk code benefits that greatly from optimisation.

Enabling core dumps shouldn’t really have any impact on normal run time processing.

Nonetheless, a core dump without DONT_OPTIMISE may still give some clues as to the general nature of the fault, even if it is impossible to debug in detail.

1 Like
9

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.