The problem/use-case that the feature addresses

Redis [NEW] NOTSAVE config

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-adjust config?

oom-score-adjust sounds good. I would try ... thank you @oranagra