Можете ли вы установить минимальный размер буфера для Linux?

У меня довольно старая машина Linux с 2 ГБ оперативной памяти, без подкачки, и она работает очень хорошо, система использует каждый неиспользуемый фрагмент памяти для кеширования с большим эффектом.

Однако, когда я близок к нагрузке на память (например, выделено> 1950 МБ), она замедляется до ползания; Я подозреваю, что это потому, что не осталось дисковых буферов. Я знаю, что OOM Killer скоро вступит в силу, но обычно этого не происходит - он становится настолько медленным, что загружает до 30-40, ни один процесс не делает никакого прогресса (таким образом, не выделяет больше памяти), и Я должен перезапустить его.

Когда я пытаюсь просто убить один процесс, чтобы заставить машину реагировать, например, перейдя в консоль (через Alt-F1, войдя в систему и просто выполнив killall badprocess), он обычно работает, за исключением того, что мне приходится ждать ~ 10 минут между пользователем и паролем и получением приглашения - все, пока есть активность на диске.

Опять же, нет никакого обмена, так что это не обмен - он просто работает, потому что у него не осталось буферов.

У меня было бы около 100 МБ или около того, выделенных исключительно для дисковых буферов, которые раньше вызывали бы OOM killer (в конце концов, меньше памяти для программ), но, с другой стороны, машина всегда была бы отзывчивой.

Есть способ сделать это? Мне не удалось найти запись в / proc / kernel или / sys / vm, которая делает подобные вещи.

linux cache

— HopelessN00b
источник

У меня тоже есть такая же проблема, и, к сожалению, ни один из ответов на эту дату не поможет в этом вопросе.

— Кришьянис Несенбергс

Ответы:

Посмотрите на / proc / sys / vm / min_free_kbytes . Это предел свободного килобайта, который запускает убийцу бомб. Также было бы неплохо проверить в логах ключевое слово oom-killer, чтобы узнать, что именно убивается {вероятно, вы не хотите убивать ssh , вам лучше взять его в аренду }

— Николайдис Фотис
источник

Спасибо. Я увеличил его, но это, похоже, не решило проблему - как только физическая память была близка к исчерпанию, буферной памяти не осталось, и машина замедлилась до ползучести.

Здесь тоже ничего не поделаешь, система по-прежнему полностью не отвечает.

— Tronic

Это действительно помогло мне, у меня также есть 2 ГБ оперативной памяти, и я установил это значение почти на 500 МБ - пока нет замедлений / зависаний

— Krišjānis Nesenbergs

В настоящее время я тестирую этот параметр на моей рабочей станции. У меня 8 ГБ ОЗУ, и большую часть времени я не использую больше 5 ... за исключением случаев, когда по какой-то причине мне нужно запустить виртуальную машину Windows, которая требует около 4 ГБ ОЗУ. Я установил ZRAM на моей операционной системе, потому что мой жесткий диск механический, но он все еще становится довольно медленным с почти полной оперативной памятью именно из-за нехватки ОЗУ для буферов и кешей файловой системы Я просто использовал vm.min_free_kbytes, чтобы убедиться, что у меня всегда есть по крайней мере 2 ГБ свободного места, а остальная часть перенесена в сжатую оперативную память (что намного быстрее, чем обычное пространство подкачки). Выложу позже с результатами.

— РАКК

Ожидание того, чтобы о-убийца освободил память, похоже на ожидание остановки двигателя на вашем автомобиле, чтобы сообщить вам, когда пора заполнить бензобак. Ужасный убийца - это мощный инструмент последней инстанции и отчаяние для истощенной ресурсами машины. Он убивает следующую касающуюся программу, не обращая внимания на то, как это повлияет на ваше приложение, достижимость, надежность и так далее. При вызове oom-killer ваш сервер задыхается и находится в критическом состоянии.

Вместо этого вам гораздо лучше использовать активный подход к управлению использованием памяти в среде вашего приложения. Вы можете отслеживать проблемы в / proc / meminfo, предпринимать соответствующие действия и снижать нагрузку до того, как серьезная ситуация станет уродливой.

— tylerl
источник

Ситуация, которую я обнаружил, - это как раз то время, когда мой сервер задыхается и находится в критическом состоянии. От полностью отзывчивого компьютера требуется менее 20 секунд до 1 минуты, чтобы ответить на Ctrl-Alt-F1 (переключение с X на консоль). И вход невозможен, потому что через 1 минуту он отключается даже без запроса пароля. Это машина, на которой запущено много процессов; каждый из них самостоятельно НЕ является проблемой. Кроме того, это просто проблема с памятью - с процессором все в порядке, а с диском все в порядке, если осталось около 50 МБ дисковых буферов.

Что делать, если вы используете Ulimit и приложение использует порог для выполнения действия?

— Николайдис Фотис

Проблема в сумме всех заявок; 20 или около того, каждый с выделенным 20-100 МБ. Он прекрасно работает в течение нескольких недель, даже месяцев, но когда все хотят выделить ~ 100 МБ одновременно, все падает и горит; Я бы предпочел, чтобы oom_killer убил одного из них, чем самому, чтобы перезагрузить машину. Во всяком случае, я включил своп на данный момент - большинство приложений не используют всю свою память все время, поэтому машина остается стабильной даже при нагрузке до конца физической памяти; однако, я бы предпочел, чтобы у меня не было свопа для этой машины, если бы я мог.

Не решает реальную проблему, которая заключается в том, что не нужно устанавливать надлежащие пределы использования памяти (ограничения не очень полезны), приложения легко теряют память при распределении памяти, убийца OOM не запускается достаточно рано, а также массивная перегрузка диска и отсутствие отклика вызвано всем этим. Я просто потратил 30 минут времени своего работодателя, потому что машина компиляции стирала диск в течение получаса при компиляции моего кода, вместо того, чтобы просто убивать процессы Chromium, необходимые для уничтожения (или самой компиляции) менее чем за секунду, а затем покончим с этим.

— Троник

Если вы настроите oom_adjправильно, вы можете заставить свою настольную систему работать немного как Android, где система практически всегда работает против OOM killer (технически есть «убийца низкой памяти», и она настраивается через /sys/module/lowmemorykiller). Логика заключается в том, чтобы постоянно отмечать некритические фоновые процессы как потенциальные жертвы убийцы OOM и искать уничтоженные процессы и медленно перезапускать требуемые уничтоженные программы, чтобы избежать перегрузки системы. Просто убедитесь, что процесс, который продолжает перезапускать другие процессы, выделен за пределы OOM killer.

— Микко Ранталайнен