How To Defend A Shared Database From Noisy Neighbors

Yesterday, I wrote about the problem of defending a single shared database instance from noisy neighbors.

Today, I’m going to talk about one way you might go about doing this.

Our approach is to use a cron job that runs every few minutes and then queries the database for its active processes and kills any long-running queries.

We considered an approach of running the process inside of the database itself. However, the problem with that approach is we wanted more control for additional logic. For example, we’re on AWS, so there are operations that AWS does with their reserved users that we want to ignore.

Right now, the job only kills long-running queries, but we can always add additional logic whenever we need to.

A potential problem with this approach is if somebody locks the database up so much that the job can’t query for processes to kill. But we haven’t had that happen yet.