Большинство систем 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 в производственных сценариях.
Я обнаружил, что когда мне приходилось настраиваться на более низкую задержку по сравнению с пропускной способностью, я уменьшал nr_requests по умолчанию (до 32). Идея меньших партий означает меньшую задержку.
Также для read_ahead_kb я обнаружил, что для последовательных операций чтения / записи увеличение этого значения обеспечивает лучшую пропускную способность, но я обнаружил, что этот параметр действительно зависит от вашей рабочей нагрузки и шаблона ввода-вывода. Например, в системе баз данных, которую я недавно настроил, я изменил это значение, чтобы оно соответствовало размеру страницы в одной базе данных, что помогло уменьшить задержку чтения. Увеличение или уменьшение этого значения в моем случае ухудшило производительность.
Что касается других опций или настроек для очередей блочных устройств:
max_sectors_kb = Я установил это значение, чтобы оно соответствовало тому, что оборудование допускает для одной передачи (проверьте значение файла max_hw_sectors_kb (RO) в sysfs, чтобы узнать, что разрешено)
номеры = это позволяет вам отключить или настроить логику поиска для слияния запросов io. (отключение этого параметра может сэкономить вам несколько циклов процессора, но я не увидел никаких преимуществ при изменении этого для своих систем, поэтому я оставил его по умолчанию)
rq_affinity = Я еще не пробовал это, но вот объяснение из документации ядра
Если для этого параметра установлено значение «1», уровень блока перенесет завершенные запросы в «группу» ЦП, которая изначально отправила запрос. Для некоторых рабочих нагрузок это обеспечивает значительное сокращение циклов ЦП из-за эффектов кэширования.
Для конфигураций хранилища, которым необходимо максимальное распределение обработки завершения, установка для этого параметра значения «2» принудительно запускает завершение на запрашивающем процессоре (в обход логики агрегации «группы») »
планировщик = вы сказали, что попробовали дедлайн и нет. Я тестировал и noop, и deadline, но обнаружил, что крайний срок не подходит для недавнего тестирования сервера базы данных.
NOOP работал хорошо, но для нашего сервера базы данных мне все же удалось добиться лучшей производительности, настроив планировщик крайних сроков.
Параметры для планировщика крайних сроков, расположенного в / sys / block / {sd, cciss, dm -} * / queue / iosched /:
fifo_batch = вроде как nr_requests, но специфичен для планировщика. Практическое правило - уменьшите это для уменьшения задержки или увеличьте для пропускной способности. Управляет размером пакета запросов на чтение и запись.
write_expire = устанавливает время истечения срока действия пакетов записи по умолчанию 5000 мс. Еще раз уменьшение этого значения уменьшает задержку записи, а увеличение значения увеличивает пропускную способность.
read_expire = устанавливает время истечения срока действия пакетов чтения, по умолчанию - 500 мс. Здесь действуют те же правила.
front_merges = Я обычно выключаю это, и по умолчанию он включен. Я не вижу необходимости для планировщика тратить циклы процессора, пытаясь выполнить предварительное слияние запросов ввода-вывода.
пишет_starved = так как крайний срок ориентирован на чтение, по умолчанию здесь нужно обработать 2 пакета чтения перед обработкой пакета записи. Я обнаружил, что значение по умолчанию 2 подходит для моей рабочей нагрузки.
К вашему сведению 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 и другие параметры.