Тоже такое видел (OpenShift 3.11). Читаешь файл - растет mem usage. Где-то в тех же тредах совет выставлять mem request = mem limit. Частота oom’ов снизилась, но не ушли совсем. 100% фикса я не знаю

То, что mem usage растет при чтении – не новость. Страницы, прочтенные с диска, кешируются в памяти, но они высвобождаются по первому требованию и потому никакой погоды не делают. Тут же похоже на то, что при записи на диск память засирается страницами, ожидающими сброса на диск, а поскольку на диск они сбрасываются медленно, то у контейнера не остается страниц, которые можно было бы заиспользовать повторно => приходит пушистый oomk. Выглядит, как бред какой-то.

btw

тип инстанса: r5a.4xlarge версия ядра: 4.4.0-1111-aws

Вот тут интересное чтиво https://github.com/kubernetes/kubernetes/issues/43916

Огонь!

Вот самое интересное оттуда:

https://github.com/kubernetes/kubernetes/issues/43916#issuecomment-637379553

Remaining problem here appears to be vm.dirty_bytes configuration in kernel. This isn’t the read caches which are problematic (any more), it’s the write back cache.

Memory is allocated into the writeback cache pool and attributed to a cgroup. However, that cache is only flushed once the system wide limits are exceeded. Per default 10% of total system RAM before write out begins asynchronously, 20% before write operations would even start blocking. All in expectation that disk access costs can be reduced by write-combining, so it does make at least some sense.

2009 there had been attempts to bring per-cgroup dirty limits into the kernel, but the discussion around the patch sets derailed into treating it as a performance (non-)optimization and the patch set was discarded.

Hard workaround: Explicitly set vm.dirty_bytes to a significantly lower value, such that vm.dirty_bytes + working set < per cgroup limit.

You should then also decrement vm.dirty_background_bytes to 1/2 or 1/4 of vm.dirty_bytes, and decrement vm.dirty_writeback_centisecs significantly to ensure that vm.dirty_background_bytes is checked often enough, and async writeback remains common case despite smaller buffers.

Worst case, each cgroup can allocate all of vm.dirty_bytes during a burst write, on top of the regular working set. It’s essential that the vm.dirty_bytes quota must fit within the cgroup quota, or write back will never be throttled, resulting in OOM before stall.

Be careful if you are relying on mmap() syscalls anywhere though, they are also allocated from vm.dirty_bytes quota. If you are in that unlucky situation, the only option left is to perform file writes from any context with bursts explicitly bypassing or flushing the write back cache (using O_DIRECT, O_DSYNC or spamming fsync() etc.).

Root cause is a design fault in the dirty page tracking in cgroups 2. It makes perfect sense to limit dirty pages locked in memory via explicit mmap() and alike (as they can’t be freed), but it makes no sense to maintain the attribution after the process has already released the memory. Pressuring the kernel into prioritizing write back got it all backwards.

OOM killer срабатывает на кэш диска?

Кого сбрасывает? Киллер ничего не сбрасывает.

Срабатывает киллер в группе когда memory.current пытается превысить memory.max. Сомневаюсь что что-то сбрасывается. Растет поптребление памяти, и киллер приходит. Все логично.

Все логично.

Ъ - логика.

Победа!

Проблема исчезла после установки sysctl:

vm.dirty_bytes = 104857600
vm.dirty_background_bytes = 104857600

До этого были установлены

vm.dirty_bytes_ratio = 10
vm.dirty_background_bytes_ratio = 10

Из этого всего можно сделать осторожный вывод, что vm.dirty*_bytes_ratio в ядре 4.4 работает глобально, хотя должны – для каждой cgroup.