В нескольких контекстах я видел поведение в системах Linux, в котором большие объемы операций записи файловой системы (например, много гигабайт записи, очень быстро) будут переполнять память, очевидно ожидая завершения операций ввода-вывода и буферизации данных (это был записан) для сброса на диск, чтобы освободить память для последующих записей. Когда возникает это обстоятельство, если я смотрю на "vmstat -s", я вижу, что объем свободной памяти становится все меньше и меньше, пока не достигнет нуля. Я чаще всего сталкиваюсь с этой проблемой при записи на очень медленные диски (например, внешние USB-накопители, на которых есть файловая система), но я также видел это с более «обычными» дисками SATA, когда большие объемы данных записываются очень сильно. быстро. В лучшем случае это, кажется, приводит к тому, что операции записи в конечном итоге блокируются в ожидании освобождения памяти. В худшем случае, если после того, как система находится в этом состоянии, продолжает происходить большой объем операций записи, нагрузка на память становится настолько большой, что запускается OOM Killer и случайным образом завершает процессы, чтобы освободить память. Очевидно, для этого даже не нужно, чтобы несколько пользователей выполняли запись, поскольку я сам создал эту ситуацию (даже без того, чтобы кто-либо еще использовал систему), когда пытался очень быстро записать очень большие объемы данных в файловую систему.
Мое предположение (и я подчеркиваю, это только лучшее предположение) заключается в том, что система не особенно агрессивна в сбрасывании буферизованного вывода на диск и освобождении связанной памяти. Но я не уверен, что я могу настроить или хотя бы посмотреть, чтобы определить, действительно ли это так, и, возможно, сделать очистку буферов записи более агрессивной.
На правильном ли я здесь пути, насколько я понимаю, что происходит? Если да, могу ли я что-нибудь настроить, чтобы попытаться заставить систему более агрессивно сбрасывать ожидающие операции ввода-вывода на диск и освобождать буферную память?
Это звучит как хорошо известная тема (например, см. Пагубная проблема с задержкой USB-накопителя и К менее раздражающей обратной записи в фоновом режиме на LWN), но, к сожалению, вы не сообщили нам о версиях программного обеспечения в вашей системе (например, о версии ядра), поэтому будет сложно сказать что-то слишком конкретное для ваших обстоятельств. Я никогда не слышал, чтобы чрезмерная обратная запись вызывала OOM (скорее, это приводило к плохой реакции для меня). Чтобы проверить, действительно ли все это связано с обратной записью (в отличие от кэшированной памяти, которую можно легко удалить в ситуации OOM), вам нужно будет отслеживать строки Dirty и Writeback в /proc/meminfo и внимательно посмотрите на состояние памяти, показанное в заставке OOM.
Как правило, это не должно вызывать проблем с новыми (на момент написания) ядрами, потому что меры были введены для выполнения динамического регулирования обратной записи в 4.10 (но обратите внимание регулирование обратной записи отключено по умолчанию, если вы используете планировщик ввода-вывода CFQ на 4.12+).
Что касается ручного управления, Крис Зибенманн обнаружил, что настройка dirty_background_bytes и dirty_bytes сохраняет свою машину отзывчивой при записи на USB-накопители. Эти ценности живут в /proc/sys/vm и упомянуты вместе с другими в упомянутой ранее статье о LWN USB-накопителе (см. также ответы на Ограничьте фоновую очистку Linux (грязные страницы) для обсуждения этой техники). Однако будьте осторожны: неправильная установка этих значений может снизить пропускную способность.