dirty_ratio на устройство

Недавно я исследовал RHEL7.2, который почти полностью зависал только потому, что он был записан в файловую систему CIFS. С настройками по умолчанию dirty_ratio = 30 и cifs, которые кэшируются (для чтения и записи), эти грязные страницы были в основном cifs.

Под давлением памяти, когда система осушенной большой части кэша чтения, система упорно пыталась очистить и вернуть грязный (запись) кэш. Таким образом, ситуация была огромным процессором iowait, сопровождаемым отличным временем завершения ввода-вывода на локальном диске, множеством процессов в D бесперебойном ожидании и полностью безответной системой. Убийца OOM никогда не занимался, потому что была свободная память, которую система не выдавала. (Я думаю, что есть также ошибка с CIFS, которая проползла покраснение до невероятно медленных скоростей. Но, конечно, неважно, что здесь.)

Я был ошеломлен, узнав, что ядро ​​обрабатывает очищающие страницы до медленного удаленного CIFS-бокса точно так же, как и сверхбыстрый локальный накопитель SSD. Просто dirty_ratio иметь один пакет dirty_ratio , он быстро приводит к ситуации, когда 30% ОЗУ содержит грязные данные от самых медленных устройств. Какая трата денег.

Ситуация воспроизводима; установка dirty_ratio = 1 решает проблему. Но зачем мне жертвовать кешем локальных дисков только потому, что я использую cifs mount?

Помимо полного отключения кэширования некоторых устройств или установки vm.dirty_ratio на очень низкое значение, есть ли способы «белого списка» быстрых устройств, чтобы иметь больше кэша записи? Или, чтобы медленные устройства (или удаленные «устройства», такие как // cifs / paths), использовали меньше кэша записи?

2 Solutions collect form web for “dirty_ratio на устройство”

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

Поэтому я приписываю все проблемы этой ошибке, связанной с CIFS, о которой я упоминал. Если другие процессы хотят писать на быстрый локальный диск, ядро ​​использовало бы меньше для CIFS. Здесь больше процессов, которые хотели просто использовать память и ядро, не могли очистить и восстановить большой кеш-запись CIFS из-за указанной ошибки. Вероятно, 30% dirty_ratio не будет проблемой, если не ошибка.

Я думаю, вы можете установить долю грязного отношения на устройство через

echo RATIO > /sys/class/bdi/MAJOR:MINOR/max_ratio

  • NFS Share Locking рабочие станции в закрытой сети
  • Сценарий Bash и база данных
  • Каковы различия между облачными изображениями и закрытыми виртуальными машинами?
  • Требуются ли оба смягчения, когда audit2allow предлагает и restorecon, и правило принудительного применения одного типа?
  • Синхронизация одинаковых каталогов между двумя Linux-серверами
  • Постоянно увеличивайте MTU для мостового интерфейса на RHEL 7
  • rsync --delete не удалял файл в пункте назначения, а с помощью ssh
  • Что такое пакеты gpg-pubkey *?
  • NFS: делиться со всеми клиентами, кроме одного
  • yum-builddep создает зависимости от источника
  • Как превратить локальный репозиторий yum в локальный спутник для многих других репозиториев
  • Linux и Unix - лучшая ОС в мире.