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?

[girish]

With some help from AI , I found many apps use redis only in caching mode. I guess we can disable persistence for these apps entirely. The backup logic anyway dumps the redis database when needed. So, worst case, the cache is totally invalidated. it's fine I guess.

wordpress-developer-app Object cache plugin (WP_REDIS_* / object-cache.php)
nextcloud-app memcache.locking only (APCu for local cache)
grafana-app [remote_cache] type = redis
directus-app CACHE_STORE + RATE_LIMITER_STORE
castopod-app cache.handler="redis" only
apache-answer-app Redis cache plugin
docker-registry-app Optional blobdescriptor cache
umami-app Optional cache
kutt-app Cache / rate-limit
openwebui-app Websocket pub/sub only

I will add the persistent flag to redis.

[imc67]

Thanks, that was fast.

One thing I couldn't tell: do the app packages have to opt into this, and if so, do existing installs pick it up on an app update — or does it only apply to new installs?

[girish]

The Cloudron 10 update will reconfigure all the redis and the apps that have that field with get redis configured appropriately. In essence, it will get fixed automatically and doesn't require user intervention.