Нагрузка на сканирование ZFS абсурдно высокая

Вопрос или проблема

У меня есть относительно новый компьютер на базе Ubuntu с ZFS-on-Linux, работающий на массиве из 18 дисков. В первые пару раз, когда я выполнял zpool scrub, все работало хорошо, но в ходе последних нескольких попыток система полностью зависала — когда я смог что-то сделать, она показывала среднюю нагрузку 20-50, а большую часть времени просто не реагировала.

Это не ожидаемое поведение, верно? Есть ли какая-либо настройка, которую я могу изменить, чтобы это было менее ужасно?

Обновление:

  • Аппаратная конфигурация в основном http://www.45drives.com/products/storage/s45-lite.php
  • 18 дисков по 6 ТБ, подключенных через HighPoint R750 HBA.
  • Ubuntu 14.04 LTS, ядро Linux 3.19.
  • Пул в настоящее время заполнен примерно на 50%.
  • Без дедупликации.
  • [Обновление 2]: диски организованы в 2 RAIDZ (с единичным четом) vdev с 9 дисками каждый.

В итоге я спросил на списке рассылки ZFS-on-Linux и в конечном итоге понял, что моя проблема в том, что ZFS ARC использовал слишком много оперативной памяти системы (или, точнее, не оставлял достаточно свободной). Это приводило к конфликту за память между другими задачами ядра и ZFS, в результате чего наблюдалось много ввода-вывода на диске системы (не ZFS), и все замедлялось до состояния, близкого к застою. Интересно, что система не сообщала о каком-либо использовании подкачки, и вся страница, которая происходила, читала статические страницы с диска (предположительно, библиотеки и тому подобное), поэтому мой обычный сигнал о том, что “идет обмен, поэтому будет медленно”, не сработал.

Я уменьшил размер кэша ARC, чтобы оставить 3-4 ГБ оперативной памяти свободными, и теперь все работает намного лучше!

Вам нужно настроить вашу установку ZFS. Значения по умолчанию в ZoL не ориентированы на ваш случай использования.

Пожалуйста, предоставьте детали вашей аппаратной конфигурации и настроек ZFS.

  • Ваш пул заполнен более чем на 80%?
  • У вас включена дедупликация?
  • Какие типы дисков и контроллеров вы используете?

В общем, вы можете изменить следующее в конфигурационном файле модуля zfs.conf.

options zfs zfs_vdev_scrub_min_active=48
options zfs zfs_vdev_scrub_max_active=128

Я бы также посмотрел на общее количество файловых систем ZFS и снимков, которые у вас есть в системе.

Недавно я обнаружил на одной из наших систем, что опция sanoid ‘prune’ случайно была закомментирована, и за последние 9 месяцев количество снимков достигло более 1,2 миллиона. Фрагментация в итоге составила более 87%.

Время задержки для любой команды ZFS превышало 12 минут. zfs -t snapshot list заняло около 17 часов для завершения. Еженедельный zfs scrub pool-name занял 17 дней, что, конечно, совпадало с предыдущими и последующими проверками.

После того, как мы обновили конфигурационный файл sanoid для начала обрезки, время задержки быстро вернулось к норме. Через 1 час количество снимков уменьшилось до всего лишь 170К, и система вернулась в норму. Фрагментация снизилась до менее чем 27%.

Ответ или решение

Высокая нагрузка CPU во время ZFS Scrub: диагностика и решение

При проведении операции zpool scrub в ZFS на системе с высокой нагрузкой CPU и общим ухудшением производительности, как в вашем случае, следует обратить внимание на несколько ключевых аспектов настройки и конфигурации системы. Ниже приведены рекомендации и рекомендации по решению этой проблемы.

Причины высокой нагрузки при ZFS Scrub

  1. Загруженность ARC (Adaptive Replacement Cache)

    • При избыточном использовании памяти ZFS ARC может негативно влиять на производительность других процессов. В вашем случае изначально система не оставляла достаточное количество свободной RAM (рекомендуется 3-4 ГБ), что приводило к нехватке памяти и чрезмерной активности ввода-вывода (I/O) для чтения данных со статических страниц на диске.
  2. Неправильная конфигурация RAIDZ

    • Ваши 18 дисков распределены по двум верификациям RAIDZ (с одним паритетом), что может снизить производительность при выполнении операций, требующих высокой скорости чтения и записи. Также важно контролировать уровень заполненности пула: при превышении 80% могут возникнуть проблемы с производительностью.
  3. Количество файловых систем и снимков

    • Накопление большого количества снимков файловых систем может привести к фрагментации и замедлению операций. В вашем случае, если количество снимков накапливается в больших объемах, то это может вызывать замедление команд ZFS (например, zfs -t snapshot list может занять много времени).

Рекомендации по оптимизации

  1. Настройка ARC

    • Уменьшите размер кэша ARC до принимаемого значения, чтобы обеспечить достаточное количество свободной памяти:
      echo "options zfs zfs_arc_max=допустимое_значение_в_байтах" >> /etc/modprobe.d/zfs.conf
    • Например, если у вас 16 ГБ оперативной памяти, вы можете установить значение около 12 ГБ для ARC. Таким образом, система всегда будет иметь достаточную RAM для выполнения других задач.
  2. Настройка ZFS Scrub

    • Настройте параметры параллельного выполнения для операции scrub, чтобы снизить нагрузку на систему:
      echo "options zfs zfs_vdev_scrub_min_active=48" >> /etc/modprobe.d/zfs.conf
      echo "options zfs zfs_vdev_scrub_max_active=128" >> /etc/modprobe.d/zfs.conf
    • Это поможет равномерно распределить нагрузку на диски и предотвратить перегрузку.
  3. Регулярная очистка снимков

    • Настройте систему, такую как sanoid, для регулярной очистки старых снимков, что поможет избежать проблем с производительностью из-за фрагментации. С актуальными настройками sanoid количество снимков можно поддерживать на оптимальном уровне.
  4. Мониторинг производительности

    • Используйте инструменты мониторинга, такие как top, htop и встроенные средства ZFS (zpool status, zfs list), для отслеживания состояния пула и производительности операционной памяти в реальном времени.

Заключение

Проблемы с высокой нагрузкой CPU во время выполнения zpool scrub в ZFS могут быть эффективно решены с помощью надлежащей настройки кэширования и периодического очищения данных. Постоянный мониторинг и корректировка параметров системы помогут добиться стабильной работы без значительных провалов в производительности. Это позволяет максимально эффективно использовать ресурсы вашей системы хранения данных, что крайне важно для обеспечения доверия к ZFS как к надежному решению для управления массивами данных.

Оцените материал
Добавить комментарий

Капча загружается...