Вопросы Теги

Действительно ли возможно инициировать OOM-уничтожителя на принудительном свопинге?

Я не имею rsnapshot установите для тестирования этого на. Будьте осторожны.

Лично, я думаю, что лучшая вещь сделать состоит в том, чтобы тщательно оценить вывод rsnapshot -t interval. Однако, если Вы хотите на самом деле переместить файлы, один способ сделать это мог бы состоять в том, чтобы создать альтернативный файл конфигурации, который идентичен Вашему реальному файлу конфигурации, но с другим snapshot_root такой как: 

snapshot_root   /test/backup/path

И затем можно выполнить тестовое использование

rsnapshot -c rsnapshot.test.conf interval0

где interval0 Ваш интервал самый низкоуровневый.

26
28.12.2012, 09:13
2 ответа

Это походит на чрезмерно тщательно продуманное решение. Я предложил бы (и я делаю это на машинах, которые я устанавливаю, которые не должны быть в спящем режиме), просто выделение небольшого количества (128-256MiB) области подкачки. Таким образом, ядро может выгрузить некоторые страницы, но OOM-уничтожитель вызывается, прежде чем вещи становятся плохими.

Если Вы действительно хотите сделать это, я думаю, что необходимо будет записать собственный сценарий/программу, который контролирует использование подкачки и вызывает OOM-уничтожителя с помощью Волшебства ключ SysReq (который может быть сделан программно путем записи в /proc/sysrq-trigger).

4
27.01.2020, 19:40
  • 1
    я утверждал бы, что наличие маленькой подкачки не является очень изящным решением. Вы в основном заканчиваете тем, что ограничили полноценность своей подкачки. Что, если бы Вы имеете много неактивных страниц и извлекли бы выгоду из наличия 10 ГБ подкачки вокруг? У меня есть поля с ~100gb поршня, где 10 ГБ подкачки не являются неправдоподобной идеей. И при записи приложения, чтобы сделать это в пространстве пользователя просто открыто для проблем (по сравнению с исходно в ядре). –  Patrick 13.05.2012, 09:40
  • 2
    Поскольку затем Вам по существу нужен механизм для различения "хорошего свопинга" от "плохого свопинга", и это - трудный алгоритм для создания. Объем подкачки, которая является соответствующей, очевидно, зависит от суммы RAM и рабочей нагрузки, которую Вы выполняете, поэтому если 10 ГиБ подходят для Ваших машин, затем выделяют тот :-) –  mgorven 13.05.2012, 10:13
  • 3
    , Почему это было бы трудно? Существует только 2 типа подкачки, упреждающей подкачки из-за vm.swappiness, и вызванный свопинг из-за разряжения поршня. Все, что должно произойти, - когда ядро вынуждено подкачать, инициировать oom-уничтожителя. И 10 ГБ также оставляют тонны пространства для принудительного свопинга для перегрузки диска. –  Patrick 13.05.2012, 19:12

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

Однако в пространстве пользователя, мы можем сделать то, что мы хотим. Таким образом, я записал Раннему Демону OOM (https://github.com/rfjakob/earlyoom), который уничтожит самый большой процесс (RSS), после того как доступная RAM понижается 10%.

Без earlyoom было легко запереть мою машину (8 ГБ RAM) путем запуска http://www.unrealengine.com/html5/ несколько раз. Теперь, виновные вкладки браузера уничтожаются, прежде чем вещи выходят из-под контроля.

22
27.01.2020, 19:40
  • 1
    Спасибо, это точно, что я искал. Я могу теперь продолжать бежать column -t -s, на некоторых огромных файлах CSV и позволяют earlyoom уничтожьте его, когда это не будет возможно, прежде замечающий безразличность. –  henfiber 24.06.2015, 08:48

Теги

Похожие вопросы