VoIP Mailing List Archives
Mailing list archives for the VoIP community |
|
| View previous topic :: View next topic |
| Author |
Message |
viljoens at verishare....
Guest
|
 Posted: Wed Dec 09, 2015 7:32 am Post subject: [asterisk-users] CEL entries over ODBC several hours late |
 |
|
Hi guys
I'm running 1.8.32.3 with CEL logging over ODBC to MariaDB 5.5.41 on the
same Centos 7 machine.
I've noticed that the CDR entries made are all in-time, e. g. the call will
take place and the CDR entry is immediately written into the CDR table in
the MariaDB database.
However, CEL events for that CDR (which I need to process for a realtime
display feature in my dialer software) are always several hours after the
fact. E. g. I will make a call at 09:30, see the call immediate pop up in
the MariaDB CDR table, but only at about 15:15 that afternoon will I see
that call's CEL events come into the CEL table, from Asterisk.... I have
examined the `show processlist` in MariaDB exhaustively to establish this
fact.
The system doesn't appear loaded, load average is about 1.1 - it's a
quad-coare HT Intel Xeon E3-1225 with 8GB of DRAM running on an SSD for main
storage.
The system processes about 30 000 calls every 8 hour day, and services 90
SIP phones.
I can stop and restart the MariaDB instance for several minutes, when I
restart it it immediately picks up on the "slow" CELs from where it was
interrupted - more evidence that Asterisk is very slowly streaming the CELs
through. I thought MariaDB was the bottleneck, but apparently not?
If I make test inserts from a script into the CEL table, all of them
complete so quickly a time indication does not even register for the query
in MariaDB. Simple test queries on the CEL table are also instant, not even
counting in the internal MariaDB query duration timer.
Can anybody explain why this is that the CELs asterisk emits over ODBC are
so delayed? Are CELs intended NOT to be realtime?
So, logically, Asterisk appears to be caching CELs to the tune of hundreds
of thousands of them at any given time - meaning if it is stopped (either
killed, or core stop gracefully'ed, or just "core stop now") potentially
hundreds of thousands of CELs will just evaporate irretrivably.
What can I do to mitigate this extremely slow populating of CELs over ODBC?
Thanks
--
_____________________________________________________________________
-- Bandwidth and Colocation Provided by http://www.api-digital.com --
New to Asterisk? Join us for a live introductory webinar every Thurs:
http://www.asterisk.org/hello
asterisk-users mailing list
To UNSUBSCRIBE or update options visit:
http://lists.digium.com/mailman/listinfo/asterisk-users |
|
| Back to top |
|
 |
mjordan at digium.com
Guest
|
| Posted: Wed Dec 09, 2015 11:31 am Post subject: [asterisk-users] CEL entries over ODBC several hours late |
|
|
On Wed, Dec 9, 2015 at 6:32 AM, Stefan Viljoen <viljoens@verishare.co.za (viljoens@verishare.co.za)> wrote:
| Quote: | Hi guys
I'm running 1.8.32.3 with CEL logging over ODBC to MariaDB 5.5.41 on the
same Centos 7 machine.
I've noticed that the CDR entries made are all in-time, e. g. the call will
take place and the CDR entry is immediately written into the CDR table in
the MariaDB database.
However, CEL events for that CDR (which I need to process for a realtime
display feature in my dialer software) are always several hours after the
fact. E. g. I will make a call at 09:30, see the call immediate pop up in
the MariaDB CDR table, but only at about 15:15 that afternoon will I see
that call's CEL events come into the CEL table, from Asterisk.... I have
examined the `show processlist` in MariaDB exhaustively to establish this
fact.
The system doesn't appear loaded, load average is about 1.1 - it's a
quad-coare HT Intel Xeon E3-1225 with 8GB of DRAM running on an SSD for main
storage.
The system processes about 30 000 calls every 8 hour day, and services 90
SIP phones.
I can stop and restart the MariaDB instance for several minutes, when I
restart it it immediately picks up on the "slow" CELs from where it was
interrupted - more evidence that Asterisk is very slowly streaming the CELs
through. I thought MariaDB was the bottleneck, but apparently not?
If I make test inserts from a script into the CEL table, all of them
complete so quickly a time indication does not even register for the query
in MariaDB. Simple test queries on the CEL table are also instant, not even
counting in the internal MariaDB query duration timer.
Can anybody explain why this is that the CELs asterisk emits over ODBC are
so delayed? Are CELs intended NOT to be realtime?
So, logically, Asterisk appears to be caching CELs to the tune of hundreds
of thousands of them at any given time - meaning if it is stopped (either
killed, or core stop gracefully'ed, or just "core stop now") potentially
hundreds of thousands of CELs will just evaporate irretrivably.
What can I do to mitigate this extremely slow populating of CELs over ODBC?
|
Asterisk does not buffer CEL entries. If anything, it pushes the entries out to ODBC much more aggressively than what you would get with CDRs.
An event is generated in Asterisk that corresponds to the CEL entry. That entry is pushed over a message bus (the 'event' message bus in 1.8 - 11; 'stasis' in 12+) and is picked up by the CEL core. The events are immediately sent to the registered backends, who also immediately write it out to the backend they support. In the case of ODBC, this immediately does an INSERT into the appropriate table.
In Asterisk 1.8, you can look for a verbose level 11 message that will show when this occurs:
ast_verb(11, "[%s]\n", ast_str_buffer(sql));
In later versions, this was turned into a debug level 3 message (as anything over a verbose 5/debug 5 was cleaned up).
If you see that message, then that will tell you when Asterisk *believes* it has written the CEL entry. If that doesn't show up in the database, then it is either in the ODBC driver or the Maria database.
If you don't see that message, then something is preventing those events from getting delivered inside of Asterisk, which would only occur if you had some other serious call related issues occurring.
Matt
--
Matthew Jordan
Digium, Inc. | Director of Technology
445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
Check us out at: http://digium.com & http://asterisk.org |
|
| Back to top |
|
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
Powered by phpBB © 2001, 2005 phpBB Group
|
Search
