Sperimentando ulteriormente con questo e leggendo sulla persistenza di redis, penso che si possano fare le seguenti osservazioni:
- Quando si utilizza RDB (le impostazioni predefinite), redis eseguirà il fork ogni volta che viene eseguito un
saveviene attivata l'operazione, che (per impostazione predefinita) è impostata su una volta ogni 15 minuti come minimo . Quando vengono eseguite più scritture su Redis, le scritture RDB sono frequenti come una volta ogni 60 secondi . - Ogni fork utilizzerà un'allocazione di memoria "copy-on-write", il che significa che sebbene la memoria non raddoppierà effettivamente, apparirà così su strumenti come
ps,htope simili. - Il fork stesso può essere un'operazione ad alta intensità di CPU, in particolare su host virtuali basati su xen (che è quello che stiamo usando attualmente).
- L'operazione di scrittura sembra sovrascrivere completamente il file RDB esistente. Non scrive solo le modifiche, ma esegue il dump dell'intero set di dati su disco.
Quindi su un modesto host virtuale con 4 Gb di RAM e set di dati di circa 750 Mb (al momento in cui ho postato la domanda), questo inizia a diventare piuttosto "costoso". Abbiamo osservato quei picchi di CPU/memoria, nonché un aumento dell'IO, anche con un carico/ridistribuzione abbastanza moderato.
Quindi, per rispondere alla mia stessa domanda, questo sembra essere il comportamento "previsto".
Per quanto riguarda il miglioramento della situazione, abbiamo deciso di cambiare la nostra configurazione per utilizzare una combinazione di RDB e AOF. AOF (Append Only File), sembra scrivere solo modifiche su disco. Puoi (e dovresti) ancora configurare il file AOF da riscrivere (usando auto-aof-rewrite-percentage e auto-aof-rewrite-min-size impostazioni). È inoltre consigliabile utilizzare ancora RDB per gli snapshot. In questa configurazione, tuttavia, puoi probabilmente eseguire riscritture/istantanee complete meno frequentemente e mantenere comunque prestazioni piuttosto buone e una durata ancora migliore.
