SQL queue is growing in a peaktime
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.