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 <[email protected]> on behalf of Bogdan-Andrei Iancu <[email protected]> Reply-To: OpenSIPS users mailling list <[email protected]> Date: Thursday, April 23, 2020 at 10:55 AM To: OpenSIPS users mailling list <[email protected]>, Alex A <[email protected]> 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 [email protected]<mailto:[email protected]> http://lists.opensips.org/cgi-bin/mailman/listinfo/users<http://lists.opensips.org/cgi-bin/mailman/listinfo/users>
_______________________________________________ Users mailing list [email protected] http://lists.opensips.org/cgi-bin/mailman/listinfo/users
