SQL queue is growing in a peaktime: Difference between revisions
(Created page with "= 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. == 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 i...") |
(Add mysqlstore_max_threads_sip_msg configuration) |
||
| Line 14: | Line 14: | ||
mysqlstore_max_threads_cdr = 4 | mysqlstore_max_threads_cdr = 4 | ||
If you are processing a high volume of SIP OPTIONS, SUBSCRIBE, or NOTIFY messages and see the <code>sip_msg</code> 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. | However, if the database is waiting for storage I/O, increasing the number of threads will not help. | ||
Revision as of 16:45, 4 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.
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.