Предотвращение записи большого файла при замораживании системы

Поэтому на моем рабочем столе Linux я пишу большой файл либо на локальный диск, либо на NFS-mount.

Существует какой-то системный буфер, в который записываются записанные данные. (Что-то в диапазоне 0,5-2 ГБ в моей системе, я думаю?)

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

Что мне нужно настроить, чтобы убедиться, что этого не произойдет?

Я хочу:

Если процесс не может записывать данные на диск (или сетевое подключение и т. Д.) Достаточно быстро, этот процесс может блокироваться до тех пор, пока диск не настигнет, но другие процессы могут читать и записывать данные с разумной скоростью и латентностью без каких-либо перерывов.

В идеале я бы мог установить, какая часть общей скорости чтения / записи dsik доступна для определенного типа программы (cp, git, mplayer, firefox и т. Д.), Например « все процессы mplayer вместе получают как минимум 10 МБ / с, независимо от того, что делает остальная система ». Но « все экземпляры mplayer вместе получают как минимум 50% от общей ставки, независимо от того, что « отлично ». (т. е. меня не волнует, если я могу установить абсолютные ставки или пропорции общей ставки).

Что еще более важно (потому что самые важные чтения / записи небольшие), мне нужна аналогичная настройка для латентности. Опять же, у меня была бы гарантия того, что чтение / запись одного процесса не сможет заблокировать остальную часть системы более чем на 10 мс (или что-то еще), несмотря ни на что. В идеале у меня была бы гарантия, что « mplayer никогда не должен ждать больше 10 мс для чтения / записи, чтобы обрабатывать, независимо от того, что делает система ».

Это должно работать независимо от того, как начался процесс оскорбления (включая пользователя, которого он запускает под и т. Д.), Поэтому « оберните большой cp в ионите » или что-то еще мало полезное. Это только предотвратило бы некоторые задачи от предсказуемого замораживания всего, если я помню, чтобы их ионизировать, но как насчет задания cron, вызова exec от какого-то запущенного демона и т. Д.?

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

One Solution collect form web for “Предотвращение записи большого файла при замораживании системы”

Обычно Linux использует кеш для асинхронной записи данных на диск. Однако может случиться так, что временной интервал между запросом на запись и фактической записью или количеством неписаных (грязных) данных становится очень большим. В этой ситуации авария приведет к огромной потере данных, и по этой причине Linux переключается на синхронную запись, если грязный кеш становится большим или старым. Поскольку заказ на запись также должен соблюдаться, вы не можете просто обойти небольшой IO без гарантии того, что маленький IO полностью не зависит от всех ранних записей в очереди. Таким образом, зависящие от записи могут вызвать огромную задержку. (Подобные зависимости также могут быть вызваны уровнем файловой системы: см. https://ext4.wiki.kernel.org/index.php/Ext3_Data%3DOrdered_vs_Data%3DWriteback_mode ).

Я предполагаю, что вы испытываете какой-то буйный набухание в сочетании с зависимой записью. Если вы пишете большой файл и имеете большой кеш диска, вы попадаете в ситуации, когда необходимо записать огромное количество данных до того, как будет выполнена синхронная запись. В LWN есть хорошая статья, описывающая проблему: https://lwn.net/Articles/682582/

Работа над планировщиками все еще продолжается, и ситуация может улучшиться с новыми версиями ядра. Однако до: Есть несколько переключателей, которые могут влиять на поведение кэширования в Linux (более подробно см .: https://www.kernel.org/doc/Documentation/sysctl/vm.txt ):

  • dirty_ratio: Содержит в процентах от общей доступной памяти, содержащей свободные страницы и исправляемые страницы, количество страниц, на которых процесс генерации записи на диске сам начнет записывать грязные данные. Общая доступная память не равна общей системной памяти.
  • dirty_background_ratio: Содержит в процентах от общей доступной памяти, содержащей свободные страницы и исправляемые страницы, количество страниц, на которых потоки флеш-памяти фонового ядра начнут записывать грязные данные.
  • dirty_writeback_centisecs: потоки flusher ядра будут периодически просыпаться и записывать «старые» данные на диск. Этот перестраиваемый выражает интервал между этими пробуждениями в 100'-й секунде. Установка этого значения в ноль полностью отключает периодическую обратную запись.
  • dirty_expire_centisecs: этот настраиваемый используется для определения, когда грязные данные достаточно старые, чтобы иметь право на запись потоками флеш-памяти ядра. Он выражается в 100'-й секунде. Данные, которые были загрязнены в памяти дольше, чем этот интервал, будут выписаны в следующий раз, когда поток флуорессора просыпается.

Самый простой способ уменьшить максимальную задержку в таких ситуациях – уменьшить максимальный объем кэша грязного диска и заставить фоновое задание выполнять ранние записи. Конечно, это может привести к ухудшению производительности в ситуациях, когда в противном случае большой кеш предотвратит синхронную запись вообще. Например, вы можете настроить следующее в файле /etc/sysctl.conf:

vm.dirty_background_ratio = 1 vm.dirty_ratio = 5 

Обратите внимание, что значения, подходящие для вашей системы, зависят от объема доступной ОЗУ и скорости диска. В экстремальных условиях вышеупомянутый грязный рацион может по-прежнему быть большим. Например, если у вас есть 100GiB доступная оперативная память и вы записываете диск со скоростью около 100 Мбайт, приведенные выше настройки приведут к максимальному количеству грязного кеша 5GiB, и для записи может потребоваться около 50 секунд. С dirty_bytes и dirty_background_bytes вы также можете установить значения для кэша в абсолютном порядке.

Еще одна вещь, которую вы можете попробовать: переключить планировщик io. В текущих версиях ядра есть noop, deadline и cfq. Если вы используете более старое ядро, вы можете получить лучшее время реакции с планировщиком сроков по сравнению с cfq. Однако вы должны проверить его. Noop следует избегать в вашей ситуации. Существует также не-магистральный планировщик BFQ, который утверждает, что снижает латентность по сравнению с CFQ ( http://algo.ing.unimo.it/people/paolo/disk_sched/ ). Однако он не включен во все дистрибутивы. Вы можете проверить и переключить планировщик во время выполнения с помощью:

 cat /sys/block/sdX/queue/scheduler echo <SCHEDULER_NAME> > /sys/block/sdX/queue/scheduler 

Первая команда даст вам также краткое изложение доступных планировщиков и их точных имен. Обратите внимание: после перезагрузки настройка теряется. Чтобы постоянно выбирать график, вы можете добавить параметр ядра:

 elevator=<SCHEDULER_NAME> 

Ситуация для NFS аналогична, но включает и другие проблемы. Следующие два отчета об ошибках могут дать некоторые сведения о статистике обработки в NFS и почему большая запись файла может привести к тому, что stat будет очень медленным:

https://bugzilla.redhat.com/show_bug.cgi?id=688232 https://bugzilla.redhat.com/show_bug.cgi?id=469848

Обновление: (14.08.2017) С ядром 4.10 были введены новые параметры ядра CONFIG_BLK_WBT и его BLK_WBT_SQ и CONFIG_BLK_WBT_MQ . Они предотвращают разбухание буфера, вызванные аппаратными буферами, размеры и приоритетность которых не могут контролироваться ядром:

 Enabling this option enables the block layer to throttle buffered background writeback from the VM, making it more smooth and having less impact on foreground operations. The throttling is done dynamically on an algorithm loosely based on CoDel, factoring in the realtime performance of the disk 

Кроме того, BFQ-Scheduler основывается на ядре 4.12.

  • Какой дистрибутив Linux это?
  • Связанный с Планированием
  • Проблема эмуляции мыши
  • Сколько меняет ядро ​​Linux за один год?
  • Дублировать поле в первом столбце
  • Как создать ISO настраиваемой операционной системы Linux таким образом, чтобы я мог использовать ISO для установки на другие системы?
  • Значение pid 0 в "ipcs -s -i <id>"
  • Чтобы найти файлы типа файлов -file9
  • Уменьшить количество процессов Apache2
  • Местный «спокойный» сервис
  • найти груз?
  • Linux и Unix - лучшая ОС в мире.