November 28, 2022 in Technical Problems
I'm getting a large log table error. I have the prune settings set to 7 days. When I look at the logs, I only see 40 or so entries. I feel like it's not getting rid of the old logs, even though they are not visible. I don't know why it would be 9.7gigs otherwise.
Thanks for your help.
Do you have access to phpMyAdmin at your host?
If you do, examine that core_log table with it. Check the table's "Size" and "Overhead" values:
"Size" is the current actual size of the table. If your shows 9.7 GB then that error you see is valid (though pruning should clean that up).
"Overhead" should be zero or "-" as above.
If your core_log table shows 9.x GB of Overhead, then your server is not performing the cleanup of the deleted data, which should happen periodically. This is something your host would need to address.
Does that resolve the issue?
If not please reply with more details as to where you "only see 40 or so entries".
The overhead is showing this. How do I fix this? What do I tell my hosting company?
I clicked into the core_log table, and it shows only 44 records.
When I initially looked within IP Board, the log showed around 40ish logs where I would set the pruning settings:
Using phpMyAdmin, run an optimize on that table. The bigger question for your host however is why it’s not cleaning up after itself in the first place.
Randy is correct on both points, but don't optimize that table. Your host needs to see it in that condition.
Contact your host and tell them something like "automated cleanup of deleted table data doesn't appear to be working, please check that and correct it if so?".
You can show them that screenshot, or they can check via phpMyAdmin as well.
Either way, and assuming you're on a managed server, they are the only ones who can fix this.
It is also worth noting, all tables should ideally be using INNODB and not MyISAM. It would be worth switching those first of all, and seeing if this resolves the issue of it not being cleared properly, as the 2 table types work differently
From that screenshot you also seem to have mixed charset values: utf8_unicode_ci and utf8mb4_unicode_ci. All tables should be using utf8mb4_unicode_ci instead.
Started 2 hours ago
Started 54 minutes ago
Started 4 hours ago