[OpenSIPS-Users] High Volume Accouting backend options

Alex A alex.a at gtanetworkconsulting.com
Thu Apr 23 22:42:41 EST 2020


Thank you

I try it out via rabbitMQ event subscription



On Apr 23, 2020, 10:53 AM, at 10:53 AM, Bogdan-Andrei Iancu <bogdan at opensips.org> wrote:
>Hi Alex,
>
>Typical approach in this case is to do the accounting via a very fast 
>backend (like db_flatstore, into a text file) and import the files 
>off-sync into db (like every 5 mins).
>
>Regards,
>
>Bogdan-Andrei Iancu
>
>OpenSIPS Founder and Developer
>   https://www.opensips-solutions.com
>
>On 4/23/20 4:37 PM, Alex A wrote:
>> Hi,
>>
>>
>>     We are looking to deploy accounting/homer integration on Opensips
>>     3.0.2.
>>     As the first step deployed acc module with pgsql backend.
>>
>>     The config seem to be pretty straight-forward - see attached.
>>
>>     It appears that as soon as volume hits about 30-35k in_use
>>     transactions - the server stops replying to new requests (or give
>>     408 Timeout) and syslog gets filled with:
>>
>>     Apr 22 10:19:38 opensip1 opensips: Apr 22 10:19:38 [19258]
>>     CRITICAL:tm:set_timer: set_timer for 1 list called on a
>"detached"
>>     timer -- ignoring: 0x7fb63b993cf8
>>     Apr 22 10:19:40 opensip1 opensips: Apr 22 10:19:40 [19255]
>>     CRITICAL:tm:set_timer: set_timer for 1 list called on a
>"detached"
>>     timer -- ignoring: 0x7fb638cf9a40
>>     Apr 22 10:19:40 opensip1 opensips: Apr 22 10:19:40 [19260]
>>     CRITICAL:tm:set_timer: set_timer for 1 list called on a
>"detached"
>>     timer -- ignoring: 0x7fb63f3b23c8
>>     Apr 22 10:19:49 opensip1 opensips: Apr 22 10:19:49 [19258]
>>     CRITICAL:tm:set_timer: set_timer for 1 list called on a
>"detached"
>>     timer -- ignoring: 0x7fb63eb93a80
>>     Apr 22 10:20:01 opensip1 opensips: Apr 22 10:20:01 [19267]
>>     CRITICAL:tm:set_timer: set_timer for 1 list called on a
>"detached"
>>     timer -- ignoring: 0x7fb5de690700
>>
>>
>>     Although, the remote Postgres service is on SSD with relatively
>>     small network latency, it appears to be the bottleneck.
>>     The initial assumption was the Opensips acc uses no-blocking SQL
>>     calls (since cdrs are not real-time).
>>
>>
>>     Another observation:
>>     opensips only opens 20 SQL connections to postgres via tcp 5432. 
>>     I have tried playing with db_max_async_connections, however to no
>>     avail.
>>
>>
>>     Any suggestions to troubleshoot ? or any alternatives for
>>     accounting in high volume applications would be greatly
>appreciated.
>>
>>
>>     Thank you.
>>
>>
>>
>>
>>
>>
>>
>>
>>
>> _______________________________________________
>> Users mailing list
>> Users at lists.opensips.org
>> http://lists.opensips.org/cgi-bin/mailman/listinfo/users
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.opensips.org/pipermail/users/attachments/20200423/34bbddd6/attachment-0001.html>


More information about the Users mailing list