Files
gvisor/pkg/compressio
Ivan Prisyazhnyy 669726877e state: compressio: don't use flate for some workloads
checkpoint image compression (compressio) implies additional overhead
during its operations. when gvisor restores the kernel state inflate()
algorithm requires:

- CPU to un/compress the data
- Memory blocks to store and un/compress data

memory blocks originate from the bytes.Buffers and the sync.Pool that
tries to reuse them. they are released only when the system decides it
is a good moment:

    pool.go: runtime_registerPoolCleanup(poolCleanup)

in my system (and in production) it takes around 240s to get the related
memory region freed (unmapped()).

during that period of time from the image state is read and the kernel is
loaded till the moment when the `poolCleanup` is called + GC() releasing
buffers gVisor Kernel (sandbox) process holds tens and hundreds of
megabytes of anonymous memory pages (RAM) busy (allocated+reserved).

pretty much often, the memory overhead of using compression can result in x2
memory overhead in production system with checkpoints restore and +100ms
(hundreds) ms of startup latency just to uncompress the image.

our use case does not suffer from having uncompressed images on disk but
suffer from the waste of memory during startup and CPU overhead.

this patch adds flag to disable compression for containers checkpoints.

Signed-off-by: Ivan Prisyazhnyy <john.koepi@gmail.com>
2023-08-10 17:55:40 +02:00
..