[CRIU] RUNC Checkpoint and Restore Bench-marking

[Gabriel Southern]

On Sun, Jun 12, 2016 at 5:59 AM, Cyrill Gorcunov <gorcunov at gmail.com> wrote:

> On Mon, Jun 06, 2016 at 02:27:38AM +0300, walid ashraf wrote:
> >    Dear All,
> >    I Have implemented some tool to automate and test the performance or
> runc
> >    checkpoint and restore capabilities. and I am in need to get feed this
> >    measures from you.
> >    I used stress test to create the load inside the container with
> different
> >    configurations starting from 1 MB memory to almost 2.5 GB Memory and
> from
> >    1 process to 260.
> >    The Results is Attached and also its chart . The time unit is in
> seconds
> >    and the memory size is in MBs.
> >    Also the code I used to test is here
> https://github.com/washraf/runcbm .
> >    I measured the both checkpoint and restore time with respect to
> number of
> >    processes and memory size.
> >    I am using a OptiPlex (9020) Physical machine of 4 GB Memory and 8
> cores
> >    i7-4790 processor using ubuntu 14.04 and kernel 4.2.0-36-generic.
> >    Does these results make sense to you or I am missing something.
> >    Thanks for your time and efforts,
>
> Hi Walid! I think it worth implementing for sure. Actually it's a bit
> strange that for big number of memory provided the c/r time increases
> so significantly, probably apps start dirtifying the memory.
>

Something I've noticed is that if you create a checkpoint and restore it
soon afterwards the checkpoint data that was written to disk might still be
buffered in memory.  In that case the restore doesn't actually have to read
from disk, so it is much faster than if it did need to read from disk.  If
the checkpoints get large enough then even if you do the same thing they
might require reading from disk.  I don't know if that is the explanation
in this case, but it's something I've observed before and it might be worth
checking to make sure you are actually reading the checkpoints from disk
when benchmarking with small checkpoint sizes.

-Gabriel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20160613/231cf88d/attachment.html>