Concurrent Calls Unusual Behavior, Adaptive ODBC and Set(CDR) related?

Hi There community,

I’ve been having issues with multiple concurrent calls (300+), but the hardware resources of my asterisk instance seems to be fine (CPU/RAM)

When checking Verbose logs I’ve seen that most of the calls are stuck at Set(CDR(field)=value) application, so, maybe writing data to the MySQL server is not working properly

When trying to debug if there is any bottleneck i haven’t found yet any restriction on Asterisk, ODBC or MySQL server configurations,

Here are some examples:

odbc.ini
[dsn_<dsn_name>]
Driver = MySQL
Database =
Server = localhost
Port = 3306
#Socket = /var/lib/mysql/mysql.sock
Option = 3

odbcinst.ini
[MySQL]
Description=ODBC for MySQL
Driver=/usr/lib/libmyodbc5.so
Setup=/usr/lib/libodbcmyS.so
Driver64=/usr/lib64/libmyodbc8w.so
#Driver64=/usr/lib64/libmyodbc5.so
Setup64=/usr/lib64/libodbcmyS.so
FileUsage=1

res_odbc.conf
[res_<res_name>]
enabled => yes
dsn => dsn_<dsn_name>
username =>
password =>
pre-connect => yes
max_connections => 100
connect_timeout => 3

cdr_adaptive_odbc
[local]
connection=res_<res_name>
table=<table_name>

alias start => calldate
alias userfield => userfield

I don’t really know what is causing Set(CDR) stuck, maybe is the odbc driver, asterisk method to write data through odbc, physical hardware, or even mysql server global values.
At this point, any advice will be greatly appreciated so do not hesitate to post your thoughts

HW CPU: Xeon X5560
RAM: 32 Gigs

Kind Regards
Diego Espinoza

CDRs are single threaded, meaning that only a single operation on a CDR can occur at a time. This includes use of the CDR() dialplan function. With heavy usage, things will block waiting. Getting a backtrace[1] would likely confirm that is what is going on.

The best performance comes from not using CDRs at all and instead using CEL, and doing post-processing to construct CDRs based on your own business logic.

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

Dear @jcolp ,
Thanks for your reply,
I saw some debug logs and yes, CDRs are being written sequentially, thats why i always saw a single ODBC connection for CDR logging…
Only a good CPU could handle that much “muscle work” of writing a lot of data with low “latency”.

And, about CEL:

The best performance comes from not using CDRs at all and instead using CEL, and doing post-processing to construct CDRs based on your own business logic.

I’m trying to find some information about how to “modelate” custom CEL events, but, so far i just found a single app: CELGenUserEvent

If you have something to share i will really appreciate it
I have some custom fields that i need to write and duration fields as well that aren’t present on the default CEL table.

Kind Regards
Diego Espinoza

I’m not sure what you mean by modelate. What are you trying to achieve?

The “same” data as a CDR, but using the “writing concurrency” of CEL architecture

Date & Time
Callerid(all)
Callerid(num)
Exten
Origination Channel
Destination Channnel
Duration
Billsec
Disposition

Hope you get the idea

CEL doesn’t work like that. It produces events that you can use to produce a record of that information. It’s up to you to interpret/look at the events, and produce your own billing record(s).

Dear jcolp,

Thanks for all your assistance,
I’m closing this topic due cdr behavior confirmation

Have a gr8 day
Kind Regards!

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