Default ODBC Connections

We see that after hanging up hundreds of calls that Asterisk is having a hard time writing to the CDR Database and has a hard time processing any calls afterwards until it is done writing to CDR.

Looking in the asterisk console odbc show all it seems that VitalPBX is configured to use only one connection. So we followed this guide and increased to 5 connections. However, Asterisk still keeps only one connection.

I logged into another popular GUI for Asterisk, and I see that it constantly uses 2 connections and when processing lots of data it increases the connections.

What is preventing it from increasing the connections?

What file did you alter? Did you do a reload of the driver “res_odbc.so” after changing the file?

Did a core reload and then ran odbc show all and saw

Number of active connections: 1 (out of 5)

What did you expect to see? I suppose the number of active connections will increase depending on the system usage.

I expected this. But it doesn’t do so.

I even created 2000 concurrent channels (1k calls) but it still only used 1 connection, resulting Asterisk is not being able to accept new calls until it was finished writing to CDR.

Friendly bump on this one

I guess you should open a case with Asterisk. Probably they have some kind of patch or this is not working anymore.

This server is a VitalPBX3, which means that it is behind on the latest Asterisk versions.

I tested on a server that has Asterisk 18.15.1 and it works fine.

OK. It seems that the CDR logic inside of Asterisk was done very poorly and is not designed for high usage, thus, if the CDR DB connection is congested then Asterisk will “hang”.

It seems like the temporary solution is to enable batch mode.

However, the correct solution would be a post processing handler.

See thread: DB Connection Issues - Asterisk General - Asterisk Community

According to the Asterisk information, the batch mode might lead you to lose some CDR information if Asterisk is abruptly closed.

Yes, because here’s how batch mode works.
You set a buffer size, lets say 100. And then you set a time, let’s set 300 (5 minutes)
The CDR gets stored in the buffer, if the buffer reached 100, it will write the data from the buffer to MySQL. Otherwise, it will write the data every 5 minutes to MySQL. So whichever happens first.

So… if Asterisk was restarted unexpectedly, all the data that was stored in the buffer will be lost. Obviously.

I personally think, that it is rather to potentially lose up to 5 minutes CDR than having a dysfunctional system. Meaning, if you have unexpected crashes, you should investigate it!!!
IMO, losing a bit of CDR when a unexpected shutdown happens is totally acceptable.

However, if you do a normal reboot, then enabling scheduleronly=no should prevent loosing the data in the buffer.

With that being said:
See the last posts in the thread I linked how to properly handle storing CDR data with high volume of traffic.

The real solution would be that Asterisk provides a more reliable storing method for the CDR.

Per Josh Colp from Asterisk, this is not going to happen so fast as it requires to rewrite almost the entire CDR logic.

However, some people in that thread have said how they used.

  • CDR to a txt file and then parsed to DB
  • A non-blocking AGI that logs each step of the call to the CDR. (The user who did this said that his system handled 20k calls a day)
  • Store each step in channel variables, then in the hangup context store the variable data either with a direct script or AGI.
1 Like

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