Disk Usage Questions


This machine is still a version 3, which it’s disk space is getting filled up.

1 - PDF files:

Under /var/lib/sonata/recordings/backups I see that there is 261778 pdf files (literally the output of ll | wc -l) that uses a 1.2 GB.
What are these files? can we deleted them?

2 - CDR

Their CDR maintenance cleans data after 365 days.

Output from the /usr/share/vitalpbx/scripts/maintenance.php --debug script:

Starting Maintenance for Tenant Yellow PBX...
Setting up timezone: America/New_York
Cleaning CDR (365 days old)...

However, looking here, it seems like the CDR table is 13 GB

[root@yellow ~]# cd /var/lib/mysql/asterisk/
[root@yellow asterisk]# du -sh * | grep G | grep cdr
13G     cdr.ibd
4.0K    cdr.TRG

So we looked in MySQL itself:

[root@yellow ~]# mysql -A asterisk
Welcome to the MariaDB monitor.  Commands end with ; or \g.
Your MariaDB connection id is 70269
Server version: 10.4.13-MariaDB MariaDB Server

Copyright (c) 2000, 2018, Oracle, MariaDB Corporation Ab and others.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

MariaDB [asterisk]> select cdr_id,calldate,clid from cdr limit 5;
| cdr_id | calldate            | clid          |
|      2 | 2020-11-23 20:24:11 | "Test" <101>  |
|     26 | 2020-11-24 17:35:45 | "Test" <test> |
|     27 | 2020-11-24 17:36:53 | "Test" <test> |
|     28 | 2020-11-24 17:37:08 | "Test" <test> |
|     29 | 2020-11-24 17:40:29 | "Test" <test> |
5 rows in set (0.004 sec)

It still, for whatever reason, has some likes from November 2020 (around the timer we set up this PBX)
The maintenance.php is encrypted so we can’t even see what it does. But it does throw the following error at the end:

Clean Voicemail...
SQLSTATE[HY000]: General error: 2006 MySQL server has gone away With Query: select `e4aad8c3c91c192439b4fe69c11cf3b6`.`tenant_id` as `tenant_id`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`name` as `name`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`description` as `description`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`default` as `default`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`path` as `path`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`prefix` as `prefix`,`e4aad8c3c91c192439b4fe69c11cf3b6`.`enabled` as `enabled` from `ombutel`.`ombu_tenants` as `e4aad8c3c91c192439b4fe69c11cf3b6` where `e4aad8c3c91c192439b4fe69c11cf3b6`.`tenant_id` = ?Unexpected exit with signal 1

3 - CEL

It seems like CEL is not included in the maintenance at all. Or am I wrong?

[root@yellow ~]# cd /var/lib/mysql/asterisk/
[root@yellow asterisk]# du -sh * | grep G | grep cel
41G     cel.ibd

So it looks like the cel table is huge… I don’t think there’s anything super useful from CEL. Can we safely disable CEL and truncate the table? Or is there anything in VitalPBX that relies on it?
I mean, technically I would mind having CEL enabled as long as maintenance cleans it up…

Appreciate any pointers.

1 Like

Bump? Anyone from the VitalPBX team can comment on this? At least address #3?

Answering your questions:

  • You can delete the PDF files from the recordings modules; this won’t affect the app’s behavior.
  • Yes, you can truncate the CEL table manually and disable this module from the VitalPBX GUI. Actually, the CEL events comes disabled by default on VitalPBX 4.
1 Like

Thank you very much, @miguel!

Regarding CDR maintenance, can you please check the script to ensure it fully deletes the old logs? Or perhaps if you can share the actual query it does, and we’ll see what’s off here.

According to the above, MySQL is crashing due to the lack of resources for processing the given query. I guess this is why the maintenance add-on is not deleting the PBX CDR data.

Try optimizing the Database settings and executing the maintenance again.

vitalpbx --optimize-mariadb

Remember that the command restarts the MariaDB service, so execute it when the server is not in use.

If the above doesn’t work for you, then you might consider increasing the server resources.

I recall that we already ran this command. How can I tell?
I remember reading what it actually changes, but I can’t find that post now.

edit: I see the below. Does that mean that it has been optimized?

cat /etc/my.cnf.d/vitalpbx.cnf
report_host = master1
innodb_buffer_pool_size = 64M
innodb_flush_log_at_trx_commit = 2
innodb_log_file_size = 64M
innodb_log_buffer_size = 64M
bulk_insert_buffer_size = 64M
max_allowed_packet = 64M

You are using HA, aren’t you?

It us set up to replicate. Correct.

Then, it is not optimized. Running the script to optimize the database will overwrite your database settings.

Ok. Thank you, I’ll try that.