The problem/use-case that the feature addresses
I have a program whose architecture is shown in the figure above. Because I am in a start-up company, we are very concerned about the cost. The memory of the machine is 2c4g. At the same time, we set the maximum memory of redis is 3G. In order to ensure the data availability. We started the save configuration. At first, the program worked well. Later, we launched a program to synchronize data. During the synchronization, because the save mechanism was triggered, redis fork a subprocess to save. However, due to the program that synchronizes data changes quickly, the cow mechanism is nearly invalid. And then oom, OS kills redis
So I wanna add a config NOTSAVE, If redis changes too fast, don't save it first. When the change is slower, back up the data
Description of the feature*
Pseudo code
# config
save 60 1000
notsave 60 100000
sp is save config
nsp is notsave config
# logic
server.dirty >= sp->changes && server.unixtime-server.lastsave > sp->seconds
&&
!(server.dirty >= nsp->changes && server.unixtime-server.lastsave > nsp->seconds)
Additional information
I have implement it in my fork branch .... I am not sure it's worth to merge... but it does save some money for me
Comment From: oranagra
I think such a config can be problematic. There's not persistence guarantees at all with it. I.e. On certain deployments save will never happen.
P. S. Did you look into the new oom-score-adjust config?
It'll still have some bgsave overheads, but at least you won't lose the db
Comment From: OhBonsai
P. S. Did you look into the new
oom-score-adjustconfig?
oom-score-adjust sounds good. I would try ... thank you @oranagra