warm restart

2019-11-30 Thread David Karlsen
Reading https://github.com/memcached/memcached/wiki/WarmRestart it is a bit 
unclear to me if the mount *has* to be tmpfs backed, or it can be a normal 
fileystem like xfs.
We are looking into running memcached through Kubernetes/containers - and 
as a tmpfs volume would be wiped on pod-recreation

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com.


Re: warm restart

2019-11-30 Thread Roberto Spadim
it's a file system, tem point about warm restart is reset server and load
previous data, and how to do this? kill the proess with the proper signal


Em sáb., 30 de nov. de 2019 às 15:03, David Karlsen 
escreveu:

> Reading https://github.com/memcached/memcached/wiki/WarmRestart it is a
> bit unclear to me if the mount *has* to be tmpfs backed, or it can be a
> normal fileystem like xfs.
> We are looking into running memcached through Kubernetes/containers - and
> as a tmpfs volume would be wiped on pod-recreation
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com
> 
> .
>


-- 
Roberto Spadim

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/CAH3kUhG-%3DR0_XU9V9ERFjMYCTFKtDGmAAeuAPySGgXzNkDpKqQ%40mail.gmail.com.


Re: warm restart

2019-11-30 Thread Roberto Spadim
https://github.com/memcached/memcached/blob/master/restart.c#L283

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/CAH3kUhH50u_x2YDXQcEEXwUKvAWCZvne1t2zvGOtdif3PcJkjg%40mail.gmail.com.


Re: warm restart

2019-11-30 Thread dormando
Hey,

It's only guaranteed to work in a ram disk. It will "work" on anything
else, but you'll lose deterministic performance. Worst case it'll burn out
whatever device is underlying because it's not optimized for anything but
RAM.

So, two options for this situation:

1) I'd hope there's some way to bind mount an underlying tmpfs. With
almost all container systems there's some method of exposing an underlying
path, though I have a low opinion of Kube so manybe not.

2) It does just create two normal files: the path you give it + .meta file
that appears during graceful shutdown. After shutdown you can copy these
(perhaps with pigz or something) to a filesystem then restore to in-pod
tmpfs before starting up again. It'll increase the downtime but it'll
work.

I guess.. 3) For completeness it also works on a DCPMM dax mount, which
survive reboots and act as "filesystems". You'd need to have the right
system and memory and etc.

-Dormando

On Sat, 30 Nov 2019, David Karlsen wrote:

> Reading https://github.com/memcached/memcached/wiki/WarmRestart it is a bit 
> unclear to me if the mount *has* to be tmpfs backed, or it can be a normal 
> fileystem like xfs.
> We are looking into running memcached through Kubernetes/containers - and as 
> a tmpfs volume would be wiped on pod-recreation
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301854320.5300%40dskull.


Re: warm restart

2019-11-30 Thread David Karlsen
Won’t the cache be written to file at shutdown and not contionously while
running?

søn. 1. des. 2019 kl. 03:58 skrev dormando :

> Hey,
>
> It's only guaranteed to work in a ram disk. It will "work" on anything
> else, but you'll lose deterministic performance. Worst case it'll burn out
> whatever device is underlying because it's not optimized for anything but
> RAM.
>
> So, two options for this situation:
>
> 1) I'd hope there's some way to bind mount an underlying tmpfs. With
> almost all container systems there's some method of exposing an underlying
> path, though I have a low opinion of Kube so manybe not.
>
> 2) It does just create two normal files: the path you give it + .meta file
> that appears during graceful shutdown. After shutdown you can copy these
> (perhaps with pigz or something) to a filesystem then restore to in-pod
> tmpfs before starting up again. It'll increase the downtime but it'll
> work.
>
> I guess.. 3) For completeness it also works on a DCPMM dax mount, which
> survive reboots and act as "filesystems". You'd need to have the right
> system and memory and etc.
>
> -Dormando
>
> On Sat, 30 Nov 2019, David Karlsen wrote:
>
> > Reading https://github.com/memcached/memcached/wiki/WarmRestart it is a
> bit unclear to me if the mount *has* to be tmpfs backed, or it can be a
> normal fileystem like xfs.
> > We are looking into running memcached through Kubernetes/containers -
> and as a tmpfs volume would be wiped on pod-recreation
> >
> > --
> >
> > ---
> > You received this message because you are subscribed to the Google
> Groups "memcached" group.
> > To unsubscribe from this group and stop receiving emails from it, send
> an email to memcached+unsubscr...@googlegroups.com.
> > To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com
> .
> >
> >
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301854320.5300%40dskull
> .
>
-- 
--
David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/CAGO7Ob36THu%2BJTo3uxFMW6t6RV4BUQ38WMuUVUetY9TqGwDP7w%40mail.gmail.com.


Re: warm restart

2019-11-30 Thread dormando
The disk file is memory mapped; that is the actual memory, now external to
memcached. There's no flush at shutdown, it just gracefully stops all
in-flight actions and then does a fast data fixup on restart.

So it does continually read/write to that file. As I said earlier you can
create an "equivalent" to writing the file at shutdown by moving the file
after shutdown :)

On Sun, 1 Dec 2019, David Karlsen wrote:

> Won’t the cache be written to file at shutdown and not contionously while 
> running?
>
> søn. 1. des. 2019 kl. 03:58 skrev dormando :
>   Hey,
>
>   It's only guaranteed to work in a ram disk. It will "work" on anything
>   else, but you'll lose deterministic performance. Worst case it'll burn 
> out
>   whatever device is underlying because it's not optimized for anything 
> but
>   RAM.
>
>   So, two options for this situation:
>
>   1) I'd hope there's some way to bind mount an underlying tmpfs. With
>   almost all container systems there's some method of exposing an 
> underlying
>   path, though I have a low opinion of Kube so manybe not.
>
>   2) It does just create two normal files: the path you give it + .meta 
> file
>   that appears during graceful shutdown. After shutdown you can copy these
>   (perhaps with pigz or something) to a filesystem then restore to in-pod
>   tmpfs before starting up again. It'll increase the downtime but it'll
>   work.
>
>   I guess.. 3) For completeness it also works on a DCPMM dax mount, which
>   survive reboots and act as "filesystems". You'd need to have the right
>   system and memory and etc.
>
>   -Dormando
>
>   On Sat, 30 Nov 2019, David Karlsen wrote:
>
>   > Reading https://github.com/memcached/memcached/wiki/WarmRestart it is 
> a bit unclear to me if the mount *has* to be tmpfs backed, or it can be a 
> normal fileystem
>   like xfs.
>   > We are looking into running memcached through Kubernetes/containers - 
> and as a tmpfs volume would be wiped on pod-recreation
>   >
>   > --
>   >
>   > ---
>   > You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>   > To unsubscribe from this group and stop receiving emails from it, 
> send an email to memcached+unsubscr...@googlegroups.com.
>   > To view this discussion on the web visit 
> https://groups.google.com/d/msgid/memcached/2ed07578-4aff-4704-83b1-3cd7d56de59f%40googlegroups.com.
>   >
>   >
>
>   --
>
>   ---
>   You received this message because you are subscribed to the Google 
> Groups "memcached" group.
>   To unsubscribe from this group and stop receiving emails from it, send 
> an email to memcached+unsubscr...@googlegroups.com.
>   To view this discussion on the web visit 
> https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301854320.5300%40dskull.
>
> --
> --
> David J. M. Karlsen - http://www.linkedin.com/in/davidkarlsen
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups 
> "memcached" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to memcached+unsubscr...@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/memcached/CAGO7Ob36THu%2BJTo3uxFMW6t6RV4BUQ38WMuUVUetY9TqGwDP7w%40mail.gmail.com.
>
>

-- 

--- 
You received this message because you are subscribed to the Google Groups 
"memcached" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to memcached+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/memcached/alpine.DEB.2.21.1911301923260.5300%40dskull.