SQL queue is growing in a peaktime: Difference between revisions

From VoIPmonitor.org
(Add mysqlstore_max_threads_sip_msg configuration)
(Add symptoms of database delays including 'Crontab log is too old' warning (ticket #82237))
Line 1: Line 1:
= Delay between active call and cdr view =
= Delay between active call and cdr view =
The Active Calls view in the GUI displays the timestart of a calls(INVITEs) obtained from the VoIPmonitor sniffer service, whereas the CDR view shows the stored CDRs (after the call ends) from the database.
The Active Calls view in the GUI displays the timestart of a calls(INVITEs) obtained from the VoIPmonitor sniffer service, whereas the CDR view shows the stored CDRs (after the call ends) from the database.
== Symptoms of Database Delays ==
When the database cannot keep up with CDR insertion rates, you may experience:
* '''Slow CDR appearance in GUI''' - New calls take minutes to appear after they end
* '''"Crontab log is too old" warning''' - The cron job runs slowly (every 5-10 minutes or more) instead of every minute due to database overload
* '''Lag between call end and reporting''' - Daily reports and alerts process outdated data
To diagnose cron-related delays specifically, see [[Alerts#Crontab_Log_is_Too_Old_Warning_-_Database_Performance_Issues|"Crontab log is too old" troubleshooting]].
== SQLq/SQLf ==
== SQLq/SQLf ==
In the service status (expanded status, status line) under GUI -> Settings -> Sensors : status, the SQLq/SQLf values represent the size of the queue before the CDRs are pushed to the database. When SQLq/SQLf is high, it usually indicates that the database is unable to process requests in a timely manner, causing them to queue.
In the service status (expanded status, status line) under GUI -> Settings -> Sensors : status, the SQLq/SQLf values represent the size of the queue before the CDRs are pushed to the database. When SQLq/SQLf is high, it usually indicates that the database is unable to process requests in a timely manner, causing them to queue.

Revision as of 04:58, 6 January 2026

Delay between active call and cdr view

The Active Calls view in the GUI displays the timestart of a calls(INVITEs) obtained from the VoIPmonitor sniffer service, whereas the CDR view shows the stored CDRs (after the call ends) from the database.

Symptoms of Database Delays

When the database cannot keep up with CDR insertion rates, you may experience:

  • Slow CDR appearance in GUI - New calls take minutes to appear after they end
  • "Crontab log is too old" warning - The cron job runs slowly (every 5-10 minutes or more) instead of every minute due to database overload
  • Lag between call end and reporting - Daily reports and alerts process outdated data

To diagnose cron-related delays specifically, see "Crontab log is too old" troubleshooting.

SQLq/SQLf

In the service status (expanded status, status line) under GUI -> Settings -> Sensors : status, the SQLq/SQLf values represent the size of the queue before the CDRs are pushed to the database. When SQLq/SQLf is high, it usually indicates that the database is unable to process requests in a timely manner, causing them to queue. Logging#SQLq/SQLf

Make sure that db config is not causing io overhead

If the MySQL configuration already follows the recommendations from the scaling section of our documentation (especially innodb_flush_log_at_trx_commit and innodb_buffer_pool_size):

https://www.voipmonitor.org/doc/Scaling#SSDs

More threads/connections to a db

you can also increase the number of threads used for connection to a db for particular use like CDRs - the VoIPmonitor sniffer service in /etc/voipmonitor.conf uses the option

mysqlstore_max_threads_cdr = 4

If you are processing a high volume of SIP OPTIONS, SUBSCRIBE, or NOTIFY messages and see the sip_msg queue growing, you can increase threads specifically for those messages:

mysqlstore_max_threads_sip_msg = 4

However, if the database is waiting for storage I/O, increasing the number of threads will not help.