[OpenSIPS-Users] High Volume Accouting backend options

[Ben Newlin]

As far as I know, the db_postgres module does not implement async support. So the CDR calls to DB *will* be blocking and the max_async parameter has no effect. This is one of the reasons we use Bogdan’s suggested approach; it makes the write of the CDR local and very fast and they can then be moved off asynchronously.

The actual number of connections open to the DB will be one per each OpenSIPS process that uses the DB. Often this is only the listener processes, so if you have 20 DB connections open consistently I’m guessing you are running with 20 children/listeners?

Ben Newlin

From: Users <users-bounces at lists.opensips.org> on behalf of Bogdan-Andrei Iancu <bogdan at opensips.org>
Reply-To: OpenSIPS users mailling list <users at lists.opensips.org>
Date: Thursday, April 23, 2020 at 10:55 AM
To: OpenSIPS users mailling list <users at lists.opensips.org>, Alex A <alex.a at gtanetworkconsulting.com>
Subject: Re: [OpenSIPS-Users] High Volume Accouting backend options

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<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<mailto:Users at lists.opensips.org>

http://lists.opensips.org/cgi-bin/mailman/listinfo/users<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/06b5b0cb/attachment-0001.html>