Från att experimentera vidare med detta och läsa om redis persistens tror jag att följande observationer kan göras:
- När du använder RDB (standardinställningarna), delar redis sig varje gång en
saveoperationen utlöses, som (som standard) är inställd på en gång var 15:e minut som ett minimum . När fler skrivningar till Redis utförs, är RDB-skrivningar så frekventa som en gång var 60:e sekund . - Varje gaffel kommer att använda en "copy-on-write"-minnestilldelning, vilket innebär att även om minnet faktiskt inte kommer att fördubblas - kommer det att visas på verktyg som
ps,htopoch liknande. - Gaffeln i sig kan vara ganska cpu-intensiv operation, särskilt på xen-baserade virtuella värdar (vilket är vad vi använder för närvarande).
- Skrivoperationen verkar helt överskriva den befintliga RDB-filen. Den skriver inte bara ändringarna, utan dumpar snarare hela dataset till disk.
Så på en blygsam virtuell värd med 4Gb RAM och datamängd på runt 750Mb (när jag postade frågan) börjar detta bli ganska "dyrt". Vi observerade dessa CPU-/minnespikar, såväl som ökad IO, även under ganska måttlig belastning/återupplösning.
Så för att svara på min egen fråga - detta verkar vara det "förväntade" beteendet.
När det gäller att förbättra situationen valde vi att ändra vår konfiguration för att använda en kombination av RDB och AOF. AOF (Append Only File), verkar bara skriva ändringar till disk. Du kan (och bör) fortfarande konfigurera AOF-filen för att skriva om (med auto-aof-rewrite-percentage och auto-aof-rewrite-min-size inställningar). Det är också tillrådligt att fortfarande använda RDB för ögonblicksbilder. I den här konfigurationen kan du dock förmodligen göra fullständiga omskrivningar / ögonblicksbilder mer sällan och ändå behålla ganska bra prestanda och ännu bättre hållbarhet.