Huge size of _wsal_metadata table

Hey Charlélie!

I’m really sorry to hear that you’ve had this experience with our plugin.

To get to the bottom of this potential retention period hiccup, let’s start by checking out the Activity Log page. Could you take a peek and see if there are any logs hanging around that are older than 6 months? (check the very last page by using pagination in the top right corner – that would be the easiest approach).

This will indicate for sure if there is/was indeed a problem with the retention period cleanup or not.

Another helpful step would be to search for Event ID “6000” in the Activity log. Our plugin should report this each time it clears out events older than the specified date. Can you spot any of these events in your system? If so, can you figure out when the last one was reported?

If you’re up for trying something different, you could manually purge the old data based on the retention period. You can give it a try from our plugin’s Settings -> Activity Log Viewer tab. Here’s a quick snapshot for reference: https://prnt.sc/kxysoVoN5UJB

Give it a shot, and let me know if it does the trick!

I’m looking forward to hearing back from you on how everything goes!

Thanks!

Hello, thanks for the reply.

For the first question, nothing is older than 6 months, I already try to purge the old data. It’s only from the 2 april until today !

The logs are huge, 240?663 entries for that period…

When I click on purge the old data, they confirm to old data is found. That’s mean the logs data on the small period is really huge

Thank you so much for providing these answers and clarifications, Charlélie!

Now that we’ve confirmed the functionality of the plugin’s retention feature, there are a few alternative approaches we can explore to address the issue of high data volume. Here’s a breakdown:

1. Disk Space Management: If space is the primary concern, you could consider ensuring that the disk size is adequate to accommodate the large amount of logs your sites generate. Particularly for high-traffic websites, this can be crucial and I think that’s the case here as well.
2. Adjusting Retention Period: Another option is to configure a shorter retention period for the logs. Perhaps consider reducing it to days or weeks, depending on your specific needs and storage capacity (if that cannot be extended by any reason).
3. Additionally, I recommend taking a look at the guide we’ve prepared specifically for situations like this. It offers valuable tricks and tips for better managing logs: Activity Log Storage: Common Misconceptions

I genuinely hope these suggestions prove helpful to you. Feel free to reach out if you have any further questions or need additional assistance!

Ok I have a lot of things to try. First I was using “geek” mode pour type of log information saved, I come back to basic and see how it goes. If I still have trouble in the futur weeks I’ll come back here. Thanks for the reply.

Thank you for the update Charlélie.

I am glad we’ve been of help. Please do keep us posted. We’d like to leran what were the most common events in your activity log, since it is not the norm to have so many events within such a short period of time.

Looking forward to hearing from you.

Ok it’s not solve at all, after less than one week, _postmeta database is again with 1?992,5 Gio size. it’s huge. I really need some help, soon the automatic back-up save gonna be disable again… I just realise It’s not the same database, isn’t it ?

• This reply was modified 7 months, 2 weeks ago by Charlélie.

Hello Charlélie, the table _postmeta has got nothing to do with our plugin,. That is a WordPress table in which post metadata is stored. For ea better overview of the WordPress database, please refer to the WordPress database guide and explanation.

Please let us know if you need any additional assistance.

Ok thanks