<div dir="ltr">Sorry for the probably obvious question, but it's better to cover all bases.<div><br></div><div>The DBMS is running on the same box as Asterisk is? If that's the case then maybe the DBMS is using too much CPU and starving Asterisk?</div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-12-10 12:57 GMT-02:00 Stefan Viljoen <span dir="ltr"><<a href="mailto:viljoens@verishare.co.za" target="_blank">viljoens@verishare.co.za</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi Matthew<br>
<br>
Thank you very much for the reply.<br>
<br>
I must have something seriously wrong somewhere else then - I retested now<br>
and the "apparent" effect is as  I describe but your info definitely<br>
contradicts that. But you're obviously correct.<br>
<br>
One more question - I've noted that if I run a combination of queries in the<br>
CEL backing DB (MariaDB) and the CEL table is locked, this severely affects<br>
the Asterisk instance - thousands of occurrences of<br>
<br>
chan_sip.c:4057 __sip_autodestruct: Autodestruct on dialog<br>
'<a href="http://6a9f5d3543b619655e07c81437373a32@172.17.12.3:5060" rel="noreferrer" target="_blank">6a9f5d3543b619655e07c81437373a32@172.17.12.3:5060</a>' with owner<br>
SIP/3034-000207c8 in place (Method: BYE). Rescheduling destruction for 10000<br>
ms<br>
<br>
appear in the CLI and users complain that if they hang up then they cannot<br>
make another call on the same SIP handset for several minutes.<br>
<br>
This is obviously because the dialplan gets delayed in the H extension, and<br>
cannot write to the CEL table, waiting for the MariaDB instance to clear the<br>
locks so it can write again. The above apparently comes from a watchdog<br>
process that watches how "fast" the H extension is and if it takes "too<br>
long" it forces the channels closed.<br>
<br>
Is this assumption correct?<br>
<br>
Addtionally, it seems that the writing of CEL in Asterisk is NOT async? E.g.<br>
it appears the thread that was running the conversation ALSO does the CEL<br>
writing / pushing to the CEL core as you describe in a synchronous manner.<br>
<br>
For 1.8, is this correct that CELs are synchronous, and do newer Asterisk<br>
versions do it async?<br>
<br>
E. g. my point being if there are major DB issues, it is quite a bit<br>
kryptonite to have that "spill back" into Asterisk and start blocking off<br>
users from calling out - wouldn't it be much better to simply have failed<br>
CEL writes just die in a distal thread instead of the main call thread for<br>
the channels running on that handset.<br>
<br>
Or am I completely misunderstanding things?<br>
<br>
Anyway, thanks for the reply. :)<br>
<br>
Kind regards,<br>
<br>
> Hi guys<br>
><br>
> I'm running 1.8.32.3 with CEL logging over ODBC to MariaDB 5.5.41 on the<br>
> same Centos 7 machine.<br>
><br>
> I've noticed that the CDR entries made are all in-time, e. g. the call<br>
will<br>
> take place and the CDR entry is immediately written into the CDR table in<br>
> the MariaDB database.<br>
><br>
> However, CEL events for that CDR (which I need to process for a realtime<br>
> display feature in my dialer software) are always several hours after the<br>
> fact. E. g. I will make a call at 09:30, see the call immediate pop up in<br>
> the MariaDB CDR table, but only at about 15:15 that afternoon will I see<br>
> that call's CEL events come into the CEL table, from Asterisk.... I have<br>
> examined the `show processlist` in MariaDB exhaustively to establish this<br>
> fact.<br>
><br>
> The system doesn't appear loaded, load average is about 1.1 - it's a<br>
> quad-coare HT Intel Xeon E3-1225 with 8GB of DRAM running on an SSD for<br>
> main<br>
> storage.<br>
><br>
> The system processes about 30 000 calls every 8 hour day, and services 90<br>
> SIP phones.<br>
><br>
> I can stop and restart the MariaDB instance for several minutes, when I<br>
> restart it it immediately picks up on the "slow" CELs from where it was<br>
> interrupted - more evidence that Asterisk is very slowly streaming the<br>
CELs<br>
> through. I thought MariaDB was the bottleneck, but apparently not?<br>
><br>
> If I make test inserts from a script into the CEL table, all of them<br>
> complete so quickly a time indication does not even register for the query<br>
> in MariaDB. Simple test queries on the CEL table are also instant, not<br>
even<br>
> counting in the internal MariaDB query duration timer.<br>
><br>
> Can anybody explain why this is that the CELs asterisk emits over ODBC are<br>
> so delayed? Are CELs intended NOT to be realtime?<br>
><br>
> So, logically, Asterisk appears to be caching CELs to the tune of hundreds<br>
> of thousands of them at any given time - meaning if it is stopped (either<br>
> killed, or core stop gracefully'ed, or just "core stop now")  potentially<br>
> hundreds of thousands of CELs will just evaporate irretrivably.<br>
><br>
> What can I do to mitigate this extremely slow populating of CELs over<br>
ODBC?<br>
><br>
><br>
Asterisk does not buffer CEL entries. If anything, it pushes the entries<br>
out to ODBC much more aggressively than what you would get with CDRs.<br>
<br>
An event is generated in Asterisk that corresponds to the CEL entry. That<br>
entry is pushed over a message bus (the 'event' message bus in 1.8 - 11;<br>
'stasis' in 12+) and is picked up by the CEL core. The events are<br>
immediately sent to the registered backends, who also immediately write it<br>
out to the backend they support. In the case of ODBC, this immediately does<br>
an INSERT into the appropriate table.<br>
<br>
In Asterisk 1.8, you can look for a verbose level 11 message that will show<br>
when this occurs:<br>
<br>
        ast_verb(11, "[%s]\n", ast_str_buffer(sql));<br>
<br>
In later versions, this was turned into a debug level 3 message (as<br>
anything over a verbose 5/debug 5 was cleaned up).<br>
<br>
If you see that message, then that will tell you when Asterisk *believes*<br>
it has written the CEL entry. If that doesn't show up in the database, then<br>
it is either in the ODBC driver or the Maria database.<br>
<br>
If you don't see that message, then something is preventing those events<br>
from getting delivered inside of Asterisk, which would only occur if you<br>
had some other serious call related issues occurring.<br>
<br>
Matt<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
_____________________________________________________________________<br>
-- Bandwidth and Colocation Provided by <a href="http://www.api-digital.com" rel="noreferrer" target="_blank">http://www.api-digital.com</a> --<br>
New to Asterisk? Join us for a live introductory webinar every Thurs:<br>
               <a href="http://www.asterisk.org/hello" rel="noreferrer" target="_blank">http://www.asterisk.org/hello</a><br>
<br>
asterisk-users mailing list<br>
To UNSUBSCRIBE or update options visit:<br>
   <a href="http://lists.digium.com/mailman/listinfo/asterisk-users" rel="noreferrer" target="_blank">http://lists.digium.com/mailman/listinfo/asterisk-users</a><br>
</font></span></blockquote></div><br></div>