Thanks, this gives us a much clearer picture.
I do not think this is a Bot Guard cleanup failure. Cleanup is making progress, and moving XenForo jobs to server-based cron was the right change. The CloudWatch data, though, points very strongly to database capacity pressure.
The current RDS instance is a db.t3.small, which is a small burstable instance with only 2 GB RAM. The database is showing:
- very low free memory;
- persistent swap usage;
- elevated disk queue depth;
- elevated read/write latency;
- CPU running above the sustainable baseline often enough that credits are declining;
- max_used_connections very close to max_connections;
- only about 768 MiB of InnoDB buffer pool.
In plain English, MySQL is being asked to serve live forum traffic, write Bot Guard event/detail/reason rows, maintain indexes, and prune old rows at the same time, while already short on memory and I/O headroom.
That is why cleanup is slow. It is trying to serve a buffet with a teaspoon.
Moving to db.t3.medium should help, especially because it doubles memory from 2 GB to 4 GB. That may allow a larger InnoDB buffer pool, reduce swap, and reduce disk churn/read latency if the current instance is constantly being forced back to disk. So yes, I do think it is a worthwhile improvement over db.t3.small.
However, I would treat db.t3.medium as a short-term relief step, not the final target.
Especially if the bots never give up. It is still a burstable 2 vCPU instance. In the same anecdote, this is more like upgrading from a teaspoon to a tablespoon, not moving to a properly sized kitchen.
Given the current write volume and cleanup backlog, my stronger recommendation would be a non-burstable general-purpose or memory-optimised class, ideally:
- db.r7g.large / db.r8g.large, if available for your engine and region;
- otherwise db.r6g.large, db.r7i.large, or db.r6i.large;
- at minimum, a db.m7g.large, db.m8g.large, or db.m6g.large class.
The reason I lean toward R-class is that this workload is clearly memory-sensitive. More RAM means a much larger InnoDB buffer pool and less reliance on slow disk reads while cleanup and live traffic are competing.
If you do move to db.t3.medium first, I would avoid committing to a long reservation until it has proven itself under this workload. After the resize, I would watch these metrics for 24–48 hours:
- CPUCreditBalance / surplus credits;
- FreeableMemory;
- SwapUsage;
- DiskQueueDepth;
- ReadLatency / WriteLatency;
- DatabaseConnections;
- Bot Guard health/status, especially “Last cleanup run”.
If swap remains non-trivial, CPU credits keep falling, disk queue depth stays elevated, or cleanup still barely advances, then the instance is still undersized.
Once the instance is resized, it is also worth reviewing the MySQL/RDS parameter group. RDS defaults are generic; they are not tuned specifically for XenForo plus a high-volume Bot Guard audit workload. In particular, the InnoDB buffer pool, max connections, and PHP/web concurrency should be reviewed together so the new resources are actually used well.
That tuning probably cannot rescue the current db.t3.small, but it can make a meaningful difference once the database is on an instance with enough headroom.
It also suggested sending you:
