Po dalszych eksperymentach z tym i czytaniu o trwałości redis, myślę, że można poczynić następujące obserwacje:
- W przypadku korzystania z RDB (ustawienia domyślne), redis rozwidla się za każdym razem, gdy
saveuruchamiana jest operacja, która (domyślnie) jest ustawiona na raz na 15 minut jako minimum . Gdy wykonywanych jest więcej zapisów do Redis, zapisy RDB są tak częste, jak raz na 60 sekund . - Każdy widelec użyje alokacji pamięci „kopiuj przy zapisie”, co oznacza, że chociaż pamięć nie podwaja się - będzie tak wyglądać w narzędziach takich jak
ps,htopi tym podobne. - Sam fork może być operacją dość intensywną dla procesora, szczególnie na hostach wirtualnych opartych na xen (którego obecnie używamy).
- Wydaje się, że operacja zapisu całkowicie nadpisuje istniejący plik RDB. Nie zapisuje tylko zmian, ale raczej zrzuca całość zestaw danych na dysk.
Tak więc na skromnym wirtualnym hoście z 4 GB pamięci RAM i zestawem danych około 750 MB (w momencie, gdy pisałem pytanie), zaczyna to być dość „drogie”. Zaobserwowaliśmy te skoki procesora/pamięci, a także zwiększone IO, nawet przy dość umiarkowanym obciążeniu/obciążeniu redis.
Odpowiadając na moje własne pytanie – wydaje się, że jest to „oczekiwane” zachowanie.
Jeśli chodzi o poprawę sytuacji, zdecydowaliśmy się zmienić naszą konfigurację na połączenie RDB i AOF. AOF (Dołącz tylko plik), wydaje się, że zapisuje tylko zmiany na dysk. Możesz (i powinieneś) nadal skonfigurować plik AOF do przepisywania (używając auto-aof-rewrite-percentage i auto-aof-rewrite-min-size ustawienia). Wskazane jest również, aby nadal używać RDB do migawek. Jednak w tej konfiguracji prawdopodobnie będziesz mógł rzadziej wykonywać pełne przepisywanie / zrzuty obrazu i nadal utrzymywać całkiem dobrą wydajność i jeszcze lepszą trwałość.
