Bug: WordPress object-cache redis writes a full RDB dump every five minutes, which turned out to be my biggest disk I/O contributor

[imc67]

Following up on my old topic about high disk I/O (14639, which @nebulon split into 15206, 15207 and 15211) : there is one more contributor, and on one of my servers it is bigger than everything we found back then.

Measured over a quiet hour on a server with 14 WordPress apps: 13.8 GB written in 60 minutes, of which mysql accounts for 4.1 GB and the per-app redis containers for 5.1 GB together. The object caches write more than the database does.

It comes from the default save policy. An app's redis runs with save 900 1 300 10 60 10000, and a WordPress object cache always changes more than 10 keys within 300 seconds, so it dumps its entire dataset every five minutes. One site here has 323k keys and a 63 MB dump.rdb, which is 12 x 63 MB = 756 MB/hour predicted against 743 MB/hour measured.

I set CONFIG SET save "" on one of them and left a comparable site untouched as a control. Over ten minutes the first wrote 0.0 MB and the control 125.4 MB. Nothing was lost: same key count, same memory use, site fine. The dataset lives in memory either way, the dump is only a copy on disk.

To be clear, this isn't an argument for turning redis off on WordPress. Those caches are doing real work: across 22 WordPress sites here they serve about 4.7 million object lookups a day, with hit rates between 45% and 99%. It is the persistence that looks pointless for a cache, and a backup doesn't seem to depend on it either, since the box asks the redis service for a fresh dump at backup time rather than picking up the periodically written file.

Would it make sense to turn off RDB persistence for app redis instances, or to make the save policy configurable per app?