Door hier verder mee te experimenteren en te lezen over de persistentie van redis, denk ik dat de volgende opmerkingen kunnen worden gemaakt:
- Bij gebruik van RDB (de standaardinstellingen), zal redis elke keer een
saveforken bewerking wordt geactiveerd, die (standaard) is ingesteld op eenmaal per 15 minuten minimaal . Als er meer schrijfacties naar Redis worden uitgevoerd, zijn RDB-schrijfacties zo vaak als eens in de 60 seconden . - Elke vork zal een "copy-on-write" geheugentoewijzing gebruiken, wat betekent dat hoewel het geheugen niet echt zal verdubbelen - het zo zal verschijnen op tools zoals
ps,htopen dergelijke. - De fork zelf kan een behoorlijk cpu-intensieve operatie zijn, vooral op xen-gebaseerde virtuele hosts (wat we momenteel gebruiken).
- De schrijfbewerking lijkt volledig te overschrijven het bestaande RDB-bestand. Het schrijft niet alleen de wijzigingen, maar dumpt eerder de gehele dataset naar schijf.
Dus op een bescheiden virtuele host met 4Gb RAM en een dataset van rond de 750Mb (toen ik de vraag postte), begint dit nogal "duur" te worden. We hebben die CPU-/geheugenpieken waargenomen, evenals een verhoogde IO, zelfs bij redelijk matige belasting / opnieuw gebruik.
Dus om mijn eigen vraag te beantwoorden - dit lijkt het "verwachte" gedrag te zijn.
Om de situatie te verbeteren, hebben we ervoor gekozen om onze configuratie om te schakelen naar een combinatie van RDB en AOF. AOF (Append Only File), lijkt alleen wijzigingen te schrijven naar schijf. U kunt (en moet) het AOF-bestand nog steeds configureren om te herschrijven (met behulp van auto-aof-rewrite-percentage en auto-aof-rewrite-min-size instellingen). Het is ook aan te raden om RDB nog steeds te gebruiken voor snapshots. In deze configuratie kunt u waarschijnlijk minder vaak volledige herschrijvingen/snapshots maken en toch vrij goede prestaties en een nog betere duurzaamheid behouden.