Just note that RMQ may be lighter than SQL DBs, but much slower than
db_flatstore.
Regards,
Bogdan-Andrei Iancu
OpenSIPS Founder and Developer
https://www.opensips-solutions.com
On 4/24/20 1:42 AM, Alex A wrote:
Thank you
I try it out via rabbitMQ event subscription
On Apr 23, 2020, at 10:53 AM, Bogdan-Andrei Iancu <[email protected]
<mailto:[email protected]>> 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
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
_______________________________________________
Users mailing list
[email protected]
http://lists.opensips.org/cgi-bin/mailman/listinfo/users
