hotel booking / wp_mphb_sync_logs

Just a random post about a WordPress plugin (hotel booking).

For the site in question, I have a script running which alerts me to any long running (>600s) MySQL queries (or causes of deadlock) and attempts to kill them. When it does this it emails me….

So, the site/MySQL was trying to run queries like this :

DELETE FROM wp_mphb_sync_logs WHERE queue_id IN (SELECT queue_id FROM wp_mphb_sync_queue WHERE queue_name < '1639573980');

which I did an explain, it showed there were > 5 million rows to examine (none of which are actually deleted by the query, so I assume the 5 million rows are all for now invalid queue_id entries).

Adding an index on the wp_mphb_sync_logs.queue_id field didn’t really help speed up the delete … and googling around and checking the plugin’s source code, led me to think it was safe (enough) to do a ‘TRUNCATE wp_mphb_sync_logs‘.

Now that’s done the table has remained empty 12 hours later; so I think everything’s fine.

This post is mostly because the plugin’s forum requires a paid membership to contribute; and I’m not paying $400 just to post “doing this worked for me”.

Recompressing BTRFS files

Ages ago, I reconfigured my postfix/dovecot mail server to use BTRFS for it’s mail store; thinking that the mail files would compress fairly well so it’d be an efficient use of disk space.

I’d just mounted the volume with compress=lzo and not thought anything else about it.

Yesterday, Icinga/Nagios started nagging me that the disk was 80% full…..

So I thought I’d see if changing the compression algorithm to zstd would make any difference.

btrfs filesystem defrag -czstd -r /srv/mail -v

Result – disk usage went from 80% (40Gb) to 57% (28Gb) of a 50Gb volume.