Linux - реальная настройка аппаратного RAID-контроллера (scsi и cciss)
Большинство систем Linux, которыми я управляю, поддерживают аппаратные RAID-контроллеры (в основном HP Smart Array). Они все используют RHEL или CentOS.
Я ищу реальные настраиваемые параметры, помогающие оптимизировать производительность для установок, которые включают аппаратные RAID-контроллеры с дисками SAS (Smart Array, Perc, LSI и т. Д.) И кэш-память с резервным питанием от батареи или флэш-память. Предположим, RAID 1+0 и несколько шпинделей (4+ дисков).
Я трачу значительное количество времени на настройку сетевых параметров Linux для приложений с низкой задержкой и финансовых торговых операций. Но многие из этих опций хорошо документированы (изменение буфера отправки / получения, изменение настроек окна TCP и т. Д.). Что делают инженеры на стороне хранилища?
Исторически я внес изменения в лифт планирования ввода / вывода, недавно выбрав deadline а также noop планировщики для повышения производительности в моих приложениях. По мере развития версий RHEL я также заметил, что скомпилированные значения по умолчанию для блочных устройств SCSI и CCISS также изменились. Это оказало влияние на рекомендуемые параметры подсистемы хранения с течением времени. Однако прошло некоторое время, так как я видел какие-то четкие рекомендации. И я знаю, что настройки ОС по умолчанию не оптимальны. Например, кажется, что буфер упреждающего чтения по умолчанию в 128 КБ чрезвычайно мал для развертывания на оборудовании серверного класса.
В следующих статьях рассматривается влияние на производительность изменения кэша упреждающего чтения и значений nr_requests в очередях блоков.
http://zackreed.me/articles/54-hp-smart-array-p410-controller-tuning
http://www.overclock.net/t/515068/tuning-a-hp-smart-array-p400-with-linux-why-tuning-really-matters
http://yoshinorimatsunobu.blogspot.com/2009/04/linux-io-scheduler-queue-size-and.html
Например, предлагаются следующие изменения для RAID-контроллера HP Smart Array:
echo "noop" > /sys/block/cciss\!c0d0/queue/scheduler
blockdev --setra 65536 /dev/cciss/c0d0
echo 512 > /sys/block/cciss\!c0d0/queue/nr_requests
echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
Что еще можно надежно настроить для повышения производительности хранилища?
Я специально ищу варианты sysctl и sysfs в производственных сценариях.
3 ответа
Я обнаружил, что, когда мне пришлось настраиваться на более низкую задержку по сравнению с пропускной способностью, я уменьшил значение nr_requests по умолчанию (до 32). Идея, заключающаяся в меньших партиях, означает меньшую задержку.
Также для read_ahead_kb я обнаружил, что для последовательного чтения / записи увеличение этого значения обеспечивает лучшую пропускную способность, но я обнаружил, что этот параметр действительно зависит от вашей рабочей нагрузки и схемы ввода-вывода. Например, в системе баз данных, которую я недавно настроил, я изменил это значение, чтобы оно соответствовало размеру страницы в один дБ, что помогло уменьшить задержку чтения. Увеличение или уменьшение выше этого значения оказало негативное влияние на производительность в моем случае.
Что касается других опций или настроек для очередей блочных устройств:
max_sectors_kb = Я установил это значение так, чтобы оно соответствовало тому, что аппаратное обеспечение допускает для одной передачи (проверьте значение файла max_hw_sectors_kb (RO) в sysfs, чтобы увидеть, что разрешено)
nomerges = это позволяет вам отключить или настроить логику поиска для объединения запросов io. (отключение этого может сэкономить вам некоторые циклы процессора, но я не увидел никакой выгоды при изменении этого для моих систем, поэтому я оставил его по умолчанию)
rq_affinity = Я еще не пробовал это, но вот объяснение этого из документации ядра
Если этот параметр равен '1', уровень блока будет переносить завершения запроса в "группу" ЦП, которая первоначально отправила запрос. Для некоторых рабочих нагрузок это обеспечивает значительное сокращение циклов ЦП из-за эффектов кэширования.
Для конфигураций хранения, в которых необходимо максимизировать распределение обработки завершения, установка этой опции в '2' заставляет завершение запускаться на запрашивающем процессоре (в обход логики агрегирования "group") "
scheduler = вы сказали, что пробовали сроки и noop. Я протестировал как noop, так и крайний срок, но обнаружил, что крайний срок выиграл для тестирования, которое я недавно провел для сервера базы данных.
NOOP работал хорошо, но для нашего сервера баз данных мне все же удавалось добиться лучшей производительности, настраивая планировщик крайних сроков.
Опции для планировщика крайнего срока расположены в / sys / block / {sd, cciss, dm -} * / queue / iosched /:
fifo_batch = вроде как nr_requests, но специфично для планировщика. Эмпирическое правило: уменьшите задержку или увеличьте пропускную способность. Управляет размером пакета запросов на чтение и запись.
write_expire = устанавливает время истечения для пакетов записи по умолчанию 5000 мс. Еще раз уменьшение этого значения уменьшает вашу задержку записи, в то время как увеличение значения увеличивает пропускную способность.
read_expire = устанавливает время истечения для пакетов чтения по умолчанию 500 мс. Здесь применяются те же правила.
front_merges = Я склонен отключить это, и он включен по умолчанию. Я не вижу необходимости в планировщике тратить циклы ЦП на попытки слияния запросов ввода-вывода.
write_starved =, поскольку крайний срок предназначен для чтения, по умолчанию здесь обрабатывается 2 пакета чтения до обработки пакета записи. Я обнаружил, что значение по умолчанию 2 подходит для моей рабочей нагрузки.
FYI read_ahead_kb а также blockdev --setra Это просто разные способы установки одинаковых настроек с использованием разных единиц измерения (кБ против секторов):
foo:~# blockdev --setra 65536 /dev/cciss/c0d0
foo:~# blockdev --getra /dev/cciss/c0d0
65536
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
32768
foo:~# echo 2048 > /sys/block/cciss\!c0d0/queue/read_ahead_kb
foo:~# cat /sys/block/cciss\!c0d0/queue/read_ahead_kb
2048
foo:~# blockdev --getra /dev/cciss/c0d0
4096
Итак
blockdev --setra 65536 /dev/cciss/c0d0
в твоем примере не имеет эффекта.
Больше всего на свете все зависит от вашей рабочей нагрузки.
read_ahead_kb может помочь вам, если действительно полезно заранее прочитать много данных из некоторого файла, например, при потоковой передаче видео. Иногда это может причинить тебе боль. Да, 128 КБ по умолчанию могут звучать как маленькие, но при достаточном параллелизме они начинают звучать как большие! С другой стороны, с таким сервером, как сервер кодирования видео, который конвертирует видео только из формата в другой, это может быть очень хорошей идеей для настройки.
nr_requestsпосле перестройки может легко залить ваш RAID-контроллер, что опять-таки снижает производительность.
В реальном мире вам нужно следить за задержками. Если вы подключены к SAN, посмотрите iostat, sar или что вы хотите использовать, и посмотрите, не истекло ли время обслуживания запросов ввода / вывода. Конечно, это помогает и с локальными дисками: если задержки очень и очень велики, рассмотрите возможность настройки параметров лифта ввода-вывода, уменьшив max_requests и другие параметры.