idea: "durable VM"
Tim Lossen
i want to propose a new persistence mode for redis, which is
only available when virtual memory (VM) is enabled.
it works as follows: when "durable VM" is switched on, redis
initializes itself from the swap file on startup. to make
this work, the VM swap file is enhanced to contain an index
of all keys. to keep the swap file reasonably up-to-date,
keys in memory will automatically be flushed to disk every x
seconds (configurable) -- a sensible default setting might
be something like 300 (= 5 minutes).
motivation: we need to store data for 5 million users in
redis, of which less than 1% will be online at any given
time. we have configured VM as follows:
vm-max-memory 6gb
vm-pages 50304000
vm-page-size 8kb
(which works out to a 384 GB swap file)
to create a backup dump, redis currently has to swap all
data into memory, only to write it out to disk again. this
seems crazy, given that most of the data is already safely
on disk to begin with. the same applies for using AOF, when
doing a background rewrite of the AOF log.
with "durable VM" on the other hand, we could simply take a
filesystem snapshot of the swap file periodically. of
course, the snapshot would not contain any data which has
not been flushed to disk yet -- but this is configurable and
can be traded off against heavier disk io, and anyway better
than a dump which might be several hours old.
what do you think? any hidden gotchas? salvatore, how hard
would it be to implement this?
cheers
tim
Tim Lossen
what do you think about this idea -- is a "durable VM" mode
feasible? any chance it might get implemented?
tim
ps: maybe i should not have posted this on an italian holiday ;)
Begin forwarded message:
> --
> You received this message because you are subscribed to the Google Groups "Redis DB" group.
> To post to this group, send email to redi...@googlegroups.com.
> To unsubscribe from this group, send email to redis-db+u...@googlegroups.com.
> For more options, visit this group at http://groups.google.com/group/redis-db?hl=en.
>
Salvatore Sanfilippo
sorry for not replying faster, I'm trying to reply in a moment where I
can provide some detail as actually there was a lot of brainstorming
about durable VM.
I'll reply ASAP with some detail, but indeed the current state of
affairs is sub-optimal.
As a first step we should at least just perform a trivial copy from
.rdb to swap file and the other way around, instead of encoding /
re-encoding.
Another thing to explore is the reverse approach, that when VM is
enabled Redis is actually more similar to an on-disk store where the
swap is actually a b-tree, and often accessed objects are taken into
memory instead.
Saving in this context just means forcing all the dirty objects to be
synched into disk.
I think the latter could provide huge advantages in the case what
matters most is not speed but the ability to store large datasets even
if the access time will be more similar to a typical disk-backed DB.
Cheers,
Salvatore
--
Salvatore 'antirez' Sanfilippo
http://invece.org
"We are what we repeatedly do. Excellence, therefore, is not an act,
but a habit." -- Aristotele
Tim Lossen
thanks for your answer. yes, the "reverse approach" is what
i had in mind. although if we stick with the current VM
semantics -- that is, keeping most recently (not most often)
accessed keys in memory -- i do not think the access time
will be much worse, assuming that the workload is suited for
VM at all (= small number of 'hot' keys at any given time).
cheers,
tim