XF 1.5 Xenforo uses a lot of space

[KevinEssence]

So over the years our xenforo has been taking a ton of space. Is there any way we can clean things up to lighten the amount it uses without messing with the forum itself, pms, threads, ect.? Seems like mysql backups take more and more time everytime we do backups.

 

[Chris D]

If you check PhpMyAdmin you should be able to see how much disk space each individual table uses.

Which tables are using the most?

 

[Paul B]

Disable the bb code parse cache option if you have it enabled.

 

[KevinEssence]

If you check PhpMyAdmin you should be able to see how much disk space each individual table uses.

Which tables are using the most?

https://gyazo.com/63d0c9de228edb35292e23e610adeba6

 

[KevinEssence]

Disable the bb code parse cache option if you have it enabled.

Would that be under board options? Thank you!

 

[Chris D]

Judging by your screenshot, I'd say the bb code parse cache is disabled - it would usually be roughly the same size as the xf_post table if it was enabled.

Ultimately, I don't think there's much you can do here, though there is a slight anomaly in my opinion...

Your largest table is the xf_search table. This generally should be pruned daily. So, either your users are performing a lot of searches, or this pruning isn't happening.

 

[KevinEssence]

Judging by your screenshot, I'd say the bb code parse cache is disabled - it would usually be roughly the same size as the xf_post table if it was enabled.

Ultimately, I don't think there's much you can do here, though there is a slight anomaly in my opinion...

Your largest table is the xf_search table. This generally should be pruned daily. So, either your users are performing a lot of searches, or this pruning isn't happening.

Roger that. Appreciate the information. Will def. take a look

 

[Paul B]

I have seen bots cause a large search table - 1.2GB to be precise.

Disabling search for guests would help, if it is actual search queries that are being run.
You could also prevent guests from viewing profiles, which would stop the recent profile posts from being accessed.

Guests would still be able to access the recent posts link though.

 

[KevinEssence]

I have seen bots cause a large search table - 1.2GB to be precise.

Disabling search for guests would help, if it is actual search queries that are being run.
You could also prevent guests from viewing profiles, which would stop the recent profile posts from being accessed.

Guests would still be able to access the recent posts link though.

That is actually a great idea. We do get tend to get a lot of bots, I'll definitely disable it for guest and see how things turn out. Would't hurt nonetheless

 

[Chris D]

What is the date of the first record in that table? That would help identify whether it's semi-legitimate searches or some other under lying issue.

 

[KevinEssence]

What is the date of the first record in that table? That would help identify whether it's semi-legitimate searches or some other under lying issue.

Would that be the search date? https://gyazo.com/75f5f6df17b5dbf331bffd74a87d9155

 

[Chris D]

Yeah, looks like the first search was today.

With that in mind, the size of that table is merely due to the number of searches being performed. One thing you could consider is scheduling the backup to run after the daily cleanup cron has completed - it's at that time of the day which your database is likely to be smallest, though really only around 100-200MB.

Aside from that, your database should be expected to grow over time.