Fra at eksperimentere yderligere med dette og læse om redis persistens, tror jeg, at følgende observationer kan gøres:
- Når du bruger RDB (standardindstillingerne), vil redis forgrene sig hver gang en
saveoperation udløses, som (som standard) er indstillet til én gang hvert 15. minut som minimum . Når der udføres flere skrivninger til Redis, er RDB-skrivninger så hyppige som én gang hvert 60 sekund . - Hver gaffel vil bruge en "copy-on-write" hukommelsestildeling, hvilket betyder, at selvom hukommelsen faktisk ikke fordobles - vil den vises på værktøjer som
ps,htopog lignende. - Gaflen i sig selv kan være ret CPU-intensiv operation, især på xen-baserede virtuelle værter (hvilket er det, vi bruger i øjeblikket).
- Skriveoperationen ser ud til at overskrive fuldstændigt den eksisterende RDB-fil. Den skriver ikke kun ændringerne, men dumper snarere hele datasæt til disk.
Så på en beskeden virtuel vært med 4Gb RAM og datasæt på omkring 750Mb (på det tidspunkt, jeg postede spørgsmålet), begynder dette at blive ret "dyrt". Vi observerede disse CPU/hukommelsesspidser samt øget IO, selv under forholdsvis moderat belastning/genopladning.
Så for at besvare mit eget spørgsmål - det ser ud til at være den "forventede" adfærd.
Med hensyn til at forbedre situationen valgte vi at ændre vores konfiguration til at bruge en kombination af RDB og AOF. AOF (Append Only File), ser ud til kun at skrive ændringer til disk. Du kan (og bør) stadig konfigurere AOF-filen til at omskrive (ved at bruge auto-aof-rewrite-percentage og auto-aof-rewrite-min-size indstillinger). Det er også tilrådeligt stadig at bruge RDB til snapshots. I denne konfiguration kan du dog sandsynligvis lave fulde omskrivninger/snapshots sjældnere og stadig bevare en ret god ydeevne og endnu bedre holdbarhed.