<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Martin Welgemoed <<a href="mailto:martin.welgemoed@commercetools.com">martin.welgemoed@commercetools.com</a>> schrieb am Fr., 15. Nov. 2024, 16:55:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hey Anton,<br>
<br>
> To keep restore time low, we mmap image pages, o first access will require load<br>
> the content first. You can try this before executing restore command:<br>
><br>
> export CRAC_CRIU_OPTS=--no-mmap-page-image<br>
><br>
> Now the decision is done by integration with CRIU.It i should make images pages<br>
> available right away.<br>
<br>
Thanks for the suggestion. This did help a little bit (the process<br>
after restore has slightly more physical memory in use) but<br>
unfortunately the problem is a bit more involved:<br>
<br>
* We start the Java application with a few gigabytes of RAM as Xms and<br>
with AlwaysPretouch<br>
* This causes many gigabytes of RAM to be physically mapped into the process<br>
* A CRaC snapshot is taken<br>
* CRaC in "crac::checkpoint" does a full GC that explicitly ignores<br>
Xms. This is a good thing, because otherwise it'd dump gigabytes of<br>
empty heap to disk.<br>
* The heap is shrunk significantly by this, way below Xms<br>
* CRIU dumps this much smaller heap to disk<br>
* The snapshot is restored with this much smaller heap<br>
* The "G1HeapSizingPolicy::full_collection_resize_amount" does not<br>
check if "capacity_after_gc" is below MinHeapSize (because this is an<br>
invariant for G1GC)<br>
* As the application takes on full load requests trigger heap growth<br>
which causes worse tail latencies until it reaches normal operating<br>
heap size<br>
<br>
Essentially after the snapshot restore I'd like the application to be<br>
in the same position as before, that is with gigabytes of heap already<br>
committed and mapped to physical memory.<br>
<br>
Given the generic heap interface available to crac::checkpoint I don't<br>
see a clean way to work around this in the forked OpenJDK during a<br>
restore. Patching G1HeapSizingPolicy to work around this is fairly<br>
trivial but I'm not sure if that's desirable.<br>
<br>
Until now the best workaround I've found is still just allocating a<br>
giant blob of memory after the restore to grow the heap and then<br>
immediately freeing it. This does work because once the heap is past<br>
MinHeapSize the G1GC won't let it shrink below it again. But it feels<br>
a bit hacky.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">You could do the allocation in the beforeCheckpoint() hook and immediately free it in the afterRestore() hook. But that would considerably increase the image size.</div><div dir="auto"><br></div><div dir="auto">I think it would also be possible to implement a CRaC version of AlwaysPretouch which pretouches the complete heap on restore. This would keep your image small and only increase the restore time.</div><div dir="auto"><br></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Kind regards,<br>
-- <br>
Martin Welgemoed<br>
Scala Engineer<br>
<br>
<a href="mailto:martin.welgemoed@commercetools.com" target="_blank" rel="noreferrer">martin.welgemoed@commercetools.com</a><br>
T. +49 (89) 99 82 996-0<br>
commercetools B.V. | Prins Bernhardplein 200 | 1097 JB Amsterdam<br>
<br>
-- <br>
<br>
<br>
<br>
<br>
<br>
commercetools B.V.<br>
Prins Bernhardplein 200, 1097 JB Amsterdam | <br>
Netherlands<br>
<a href="http://www.commercetools.com" rel="noreferrer noreferrer" target="_blank">www.commercetools.com</a> <<a href="http://www.commercetools.com/" rel="noreferrer noreferrer" target="_blank">http://www.commercetools.com/</a>><br>
<br>
</blockquote></div></div></div>