Почему являются приложения в ограниченном памятью контейнере LXC записью больших файлов к диску, уничтожаемому OOM?

Изменить: я сохраню свой исходный ответ ниже, но я попытаюсь объяснить, что здесь происходит, и предоставить вам общее решение.

Изменить 2: предоставлен другой вариант.

Проблема, с которой вы столкнулись, связана с тем, как ядро ​​управляет вводом-выводом. Когда вы делаете запись в файловую систему, эта запись не фиксируется сразу на диск; это было бы невероятно неэффективно. Вместо этого записи кэшируются в области памяти, называемой кешем страниц, и периодически записываются фрагментами на диск. «Грязный» раздел вашего журнала описывает размер этого страничного кеша, который еще не был записан на диск:

dirty:123816kB

Итак, что очищает этот грязный кеш? Почему он не выполняет свою работу?

«Flush» в Linux отвечает за запись грязных страниц на диск. Это' sa, который периодически просыпается, чтобы определить, требуется ли запись на диск, и, если да, выполняет их. Если вы парень C-типа, начните здесь . Флеш невероятно эффективен; он отлично справляется с сбросом данных на диск, когда это необходимо. И он работает именно так, как должен.

Flush запускается вне вашего контейнера LXC, поскольку ваш контейнер LXC не имеет собственного ядра. Контейнеры LXC существуют как конструкция вокруг cgroups , которая является функцией ядра Linux, которая позволяет лучше ограничивать и изолировать группы процессов, но не собственное ядро ​​или демон сброса.

Поскольку ваш LXC имеет предел памяти ниже, чем объем памяти, доступной ядру, происходят странные вещи. Flush предполагает, что у него есть полная память хоста для записи в кэш. Программа в вашем LXC начинает писать большой файл, буферизует ... буферизует ... и в конечном итоге достигает своего жесткого предела и начинает вызывать диспетчер OOM. Это не отказ какого-либо конкретного компонента; это ожидаемое поведение. Вид. Такого рода вещи должны обрабатываться cgroups, но похоже, что это не так.

Это полностью объясняет поведение, которое вы видите между размерами экземпляров. Вы начнете сбрасывать данные на диск гораздо раньше на микро-экземпляре (с 512 МБ ОЗУ), чем на большом экземпляре

. Хорошо, это имеет смысл. Но это бесполезно. Мне все еще нужно написать мне большой файл.

Что ж, flush не знает вашего лимита LXC. Поэтому вместо исправления ядра здесь есть несколько вариантов того, что вы можете попробовать настроить:

/proc/sys/vm/dirty_expire_centiseconds

Это контролирует, как долго страница может храниться в грязном кэше и записываться на диск. По умолчанию это 30 секунд; попробуйте установить его ниже, чтобы ускорить выталкивание.

/proc/sys/vm/dirty_background_ratio

Этот параметр определяет, какой процент активного сброса памяти разрешается заполнять, прежде чем он начнет принудительную запись. Здесь нужно немного возиться, чтобы отсортировать точное общее количество , но самое простое объяснение - просто посмотреть на вашу общую память. По умолчанию это 10% (в некоторых дистрибутивах 5%). Установите это ниже; он заставит записывать на диск раньше и может помешать LXC выйти за допустимые пределы.

Могу я просто немного испортить файловую систему?

Ну, да. Но не забудьте проверить это ... вы можете повлиять на производительность. На ваших монтировках в / etc / fstab, куда вы будете писать это, добавьте параметр монтирования « sync ».

Исходный ответ:

Попробуйте уменьшить размер блока, используемый DD:

Вы можете записывать только один сектор за раз (512 байт на старых жестких дисках, 4096 на новее). Если DD отправляет запись на диск быстрее, чем диск может примите их, он начнет кэшировать записи в памяти. Вот почему ваш файловый кеш растет.