vicidial.org

hello , we have ViciBox_v8_1.x86_64-8.1.2:
Asterisk Version: 13.21.1-vici
Version: 2.14b0.5
DB Schema Version: 1564
running on vultr vps :
CPU: 4 vCore
RAM: 8192 MB
Storage: 160 GB SSD
and lately we have been facing a lot of probolems System delay, manuel call are not working, agent shows multiple times in Real-Time Main Report
https://drive.google.com/file/d/1BCDOJl ... sp=sharing

i already check slow query logs and all of them are simulaire to this one

Code: Select all

SET timestamp=1624016970;
SELECT lead_id FROM vicidial_list where vendor_lead_code="4673A"  order by modify_date desc LIMIT 1;
# Time: 210618 14:22:02
# Thread_id: 579973  Schema: asterisk  QC_hit: No
# Query_time: 24.793336  Lock_time: 0.000028  Rows_sent: 1  Rows_examined: 7314291
# Rows_affected: 0
# Full_scan: Yes  Full_join: No  Tmp_table: No  Tmp_table_on_disk: No
# Filesort: Yes  Filesort_on_disk: No  Merge_passes: 0  Priority_queue: Yes
#
# explain: id   select_type   table   type   possible_keys   key   key_len   ref   rows   r_rows   filtered   r_filtered   Extra
# explain: 1   SIMPLE   vicidial_list   ALL   NULL   NULL   NULL   NULL   7314290   1.00   100.00   100.00   Using where; Using filesort
#
SET timestamp=1624018922;
SELECT lead_id FROM vicidial_list where vendor_lead_code="4673A"  order by modify_date desc LIMIT 1;


database size is 15GB and almost 6Gb of them are logs.
additionally, we face sound cut , we hear the client but he is not able to hear us.

That is one of the major problems of using Virtual servers. I suggest moving to bare metal.

carpenox wrote:That is one of the major problems of using Virtual servers. I suggest moving to bare metal.

in the last 2 years there was no problem

There is often a database size tipping point after which problems start. We've seen this happen with many clients. I would suggest removing unused leads, setting up log archiving and running a database performance tuning script to see what my.cnf changes your system might benefit from.