De experimentar mais com isso e ler sobre persistência redis, acho que as seguintes observações podem ser feitas:

• Ao usar RDB (as configurações padrão), o redis bifurca cada vez que um save a operação é acionada, que (por padrão) é definida para uma vez a cada 15 minutos no mínimo . Quando mais gravações no Redis são executadas, as gravações RDB são tão frequentes quanto uma vez a cada 60 segundos .
• Cada fork usará uma alocação de memória "copy-on-write", o que significa que, embora a memória não duplique - ela aparecerá assim em ferramentas como ps , htop e similares.
• A bifurcação em si pode ser uma operação bastante intensiva em CPU, principalmente em hosts virtuais baseados em xen (que é o que estamos usando atualmente).
• A operação de gravação parece substituir completamente o arquivo RDB existente. Ele não grava apenas as alterações, mas despeja o todo conjunto de dados para o disco.

Portanto, em um host virtual modesto com 4Gb de RAM e conjunto de dados de cerca de 750Mb (na época em que postei a pergunta), isso começa a se tornar bastante "caro". Observamos esses picos de CPU/memória, bem como aumento de E/S, mesmo sob uso moderado de carga/redis.

Então, para responder à minha própria pergunta - esse parece ser o comportamento "esperado".

Para melhorar a situação, optamos por mudar nossa configuração para usar uma combinação de RDB e AOF. AOF (Append Only File), parece apenas gravar alterações para disco. Você pode (e deve) configurar o arquivo AOF para reescrever (usando auto-aof-rewrite-percentage e auto-aof-rewrite-min-size definições). Também é aconselhável usar RDB para instantâneos. Nesta configuração, no entanto, você provavelmente pode fazer reescritas/snapshots completos com menos frequência e ainda manter um desempenho muito bom e durabilidade ainda melhor.