От по-нататъшни експерименти с това и четене за постоянството на redis, мисля, че могат да се направят следните наблюдения:
- Когато използвате RDB (настройките по подразбиране), redis ще се разклонява всеки път, когато
saveсе задейства операция, която (по подразбиране) е настроена на веднъж на всеки 15 минути като минимум . Когато се извършват повече записи към Redis, записите в RDB са толкова чести, колкото веднъж на всеки 60 секунди . - Всяка вилка ще използва разпределение на паметта „копиране при запис“, което означава, че докато паметта всъщност няма да се удвои – тя ще се появи така в инструменти като
ps,htopи други подобни. - Самата вилка може да бъде доста процесорна операция, особено на базирани на xen виртуални хостове (което използваме в момента).
- Операцията за запис изглежда напълно презаписва съществуващия RDB файл. Той не записва само промените, а по-скоро изхвърля цялото набор от данни на диск.
Така че на скромен виртуален хост с 4Gb RAM и набор от данни от около 750Mb (по времето, когато публикувах въпроса), това започва да става доста "скъпо". Наблюдавахме тези скокове на процесора/паметта, както и увеличен IO, дори при сравнително умерено натоварване/използване на redis.
Така че, за да отговоря на собствения си въпрос – това изглежда е „очакваното“ поведение.
Що се отнася до подобряването на ситуацията, ние избрахме да превключим конфигурацията си, за да използваме комбинация от RDB и AOF. AOF (Append Only File) изглежда записва само промени към диск. Все още можете (и трябва) да конфигурирате AOF файла за презаписване (използвайки auto-aof-rewrite-percentage и auto-aof-rewrite-min-size настройки). Също така е препоръчително да използвате RDB за моментни снимки. В тази конфигурация обаче вероятно можете да правите пълни презаписвания / моментни снимки по-рядко и да поддържате доста добра производителност и още по-добра издръжливост.
