Я пытаюсь оптимизировать настройку хранилища на некотором оборудовании Sun с Linux. Приветствуются любые мысли.
У нас есть следующее оборудование:
Вот техническое описание оборудования SAS:
http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf
Он использует PCI Express 1.0a, 8 полос. С пропускной способностью 250 МБ / с на каждую полосу, мы должны иметь возможность делать 2000 МБ / с на контроллер SAS.
Каждый контроллер может работать со скоростью 3 Гбит / с на порт и имеет два 4-портовых PHY. Мы подключаем оба PHY от контроллера к JBOD. Таким образом, между JBOD и контроллером у нас есть 2 PHY * 4 порта SAS * 3 Гб / сек = 24 Гб / сек пропускной способности, что больше, чем пропускная способность PCI Express.
При включенном кэшировании записи и при выполнении больших операций записи каждый диск может поддерживать скорость около 80 МБ / с (около начала диска). С 24 дисками это означает, что мы должны иметь скорость 1920 МБ / с на каждый JBOD.
multipath {
rr_min_io 100
uid 0
path_grouping_policy multibus
failback manual
path_selector "round-robin 0"
rr_weight priorities
alias somealias
no_path_retry queue
mode 0644
gid 0
wwid somewwid
}
Я пробовал значения 50, 100, 1000 для rr_min_io, но, похоже, это не имеет большого значения.
Наряду с изменением rr_min_io я попытался добавить некоторую задержку между запуском dd, чтобы все они не писали на одном и том же PHY одновременно, но это не имело никакого значения, поэтому я думаю, что ввод-вывод правильно распределяется.
Согласно / proc / interrupts, контроллеры SAS используют схему прерывания IR-IO-APIC-fasteoi. По какой-то причине только ядро № 0 в машине обрабатывает эти прерывания. Я могу немного улучшить производительность, назначив отдельное ядро для обработки прерываний для каждого контроллера SAS:
echo 2 > /proc/irq/24/smp_affinity echo 4 > /proc/irq/26/smp_affinity
Использование dd для записи на диск генерирует «прерывания вызова функций» (не знаю, что это такое), которые обрабатываются ядром №4, поэтому я не использую и другие процессы в этом ядре.
Я запускаю 48 dd (по одному на каждый диск), назначаю их ядрам, которые не обрабатывают прерывания, например:
taskset -c somecore dd if=/dev/zero of=/dev/mapper/mpathx oflag=direct bs=128M
oflag = direct предотвращает использование буферного кеша любого типа.
Ни одно из моих ядер не исчерпано. Ядра, обрабатывающие прерывания, в основном простаивают, а все остальные ядра ожидают ввода-вывода, как и следовало ожидать.
Cpu0 : 0.0%us, 1.0%sy, 0.0%ni, 91.2%id, 7.5%wa, 0.0%hi, 0.2%si, 0.0%st Cpu1 : 0.0%us, 0.8%sy, 0.0%ni, 93.0%id, 0.2%wa, 0.0%hi, 6.0%si, 0.0%st Cpu2 : 0.0%us, 0.6%sy, 0.0%ni, 94.4%id, 0.1%wa, 0.0%hi, 4.8%si, 0.0%st Cpu3 : 0.0%us, 7.5%sy, 0.0%ni, 36.3%id, 56.1%wa, 0.0%hi, 0.0%si, 0.0%st Cpu4 : 0.0%us, 1.3%sy, 0.0%ni, 85.7%id, 4.9%wa, 0.0%hi, 8.1%si, 0.0%st Cpu5 : 0.1%us, 5.5%sy, 0.0%ni, 36.2%id, 58.3%wa, 0.0%hi, 0.0%si, 0.0%st Cpu6 : 0.0%us, 5.0%sy, 0.0%ni, 36.3%id, 58.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu7 : 0.0%us, 5.1%sy, 0.0%ni, 36.3%id, 58.5%wa, 0.0%hi, 0.0%si, 0.0%st Cpu8 : 0.1%us, 8.3%sy, 0.0%ni, 27.2%id, 64.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu9 : 0.1%us, 7.9%sy, 0.0%ni, 36.2%id, 55.8%wa, 0.0%hi, 0.0%si, 0.0%st Cpu10 : 0.0%us, 7.8%sy, 0.0%ni, 36.2%id, 56.0%wa, 0.0%hi, 0.0%si, 0.0%st Cpu11 : 0.0%us, 7.3%sy, 0.0%ni, 36.3%id, 56.4%wa, 0.0%hi, 0.0%si, 0.0%st Cpu12 : 0.0%us, 5.6%sy, 0.0%ni, 33.1%id, 61.2%wa, 0.0%hi, 0.0%si, 0.0%st Cpu13 : 0.1%us, 5.3%sy, 0.0%ni, 36.1%id, 58.5%wa, 0.0%hi, 0.0%si, 0.0%st Cpu14 : 0.0%us, 4.9%sy, 0.0%ni, 36.4%id, 58.7%wa, 0.0%hi, 0.0%si, 0.0%st Cpu15 : 0.1%us, 5.4%sy, 0.0%ni, 36.5%id, 58.1%wa, 0.0%hi, 0.0%si, 0.0%st
Учитывая все это, пропускная способность, сообщаемая при запуске «dstat 10», находится в диапазоне 2200–2300 МБ / с.
Учитывая приведенную выше математику, я ожидал бы что-то в диапазоне 2 * 1920 ~ = 3600+ МБ / с.
Кто-нибудь знает, куда пропала моя недостающая пропускная способность?
Спасибо!
Хороший, хорошо подготовленный вопрос :)
Я сам спид-н-кормит и думаю, что вы в деньгах, если честно. Я наполовину ожидал увидеть вашу пропускную способность ниже, чем есть, но я думаю, что у вас есть нарастание незначительных и ожидаемых недостатков. Например, для шины PCIe очень сложно достичь 100% все время, лучше предположить, что общая скорость составляет 90%. Учитывая джиттер, это также будет означать, что PHY не будет постоянно `` питаться '' на 100%, поэтому вы теряете там немного, то же самое для кеша, дисков, прерываний без согласования, планирования ввода-вывода и т. Д. это незначительная неэффективность, умноженная на незначительную неэффективность ... и так далее, она сама по себе оказывается больше ожидаемой 5-10% неэффективности. Я видел такие вещи, когда серверы HP DL общались со своими MSA SAS-блоками, используя W2K3, а затем выполняли NLB на нескольких сетевых адаптерах - я думаю, это неприятно, но понятно. В любом случае это мой 2с, извините, он не слишком позитивный.