Я пытаюсь оптимизировать настройку хранилища на некоторых устройствах Sun с Linux. Любые мысли будут с благодарностью.
У нас есть следующее оборудование:
- Sun Blade X6270
- 2 * LSISAS1068E SAS контроллеры
- 2 * JBOD Sun J4400 с дисками 1 ТБ (24 диска на JBOD)
- Fedora Core 12
- 2.6.33 релиз ядра от FC13 (также пробовал с последним ядром 2.6.31 от FC12, те же результаты)
Вот таблица данных для оборудования SAS:
http://www.sun.com/storage/storage_networking/hba/sas/PCIe.pdf
Он использует PCI Express 1.0a, 8x полос. При пропускной способности 250 МБ / с на линию, мы должны иметь возможность использовать 2000 МБ / с на контроллер SAS.
Каждый контроллер может делать 3 Гбит / с на порт и имеет два 4-портовых PHY. Мы подключаем оба PHY от контроллера к JBOD. Таким образом, между JBOD и контроллером у нас есть 2 PHY * 4 порта SAS * 3 Гбит / с = пропускная способность 24 Гбит / с, что больше пропускной способности PCI Express.
При включенном кэшировании записи и при выполнении больших операций записи каждый диск может поддерживать скорость около 80 МБ / с (около начала диска). С 24 дисками это означает, что мы должны иметь возможность делать 1920 МБ / с на JBOD.
многолучевость {
rr_min_io 100
UID 0
path_grouping_policy multibus
руководство по восстановлению
path_selector "Round-Robin 0"
приоритеты
псевдоним somealias
no_path_retry queue
режим 0644
Гид 0
WWID SomeWid
}
Я пробовал значения 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 дисков (по одному на каждый диск), назначая их ядрам, не имеющим отношения к прерываниям, например:
taskset -c somecore dd if = / dev / zero of = / dev / mapper / mpathx oflag = direct bs = 128M
oflag = direct предотвращает участие любого типа буферного кеша.
Ни одно из моих ядер не кажется исчерпанным. Ядра, работающие с прерываниями, в основном простаивают, а все остальные ядра ожидают ввода-вывода, как и следовало ожидать.
Cpu0: 0,0% сша, 1,0% sy, 0,0% ni, 91,2% id, 7,5% wa, 0,0% hi, 0,2% si, 0,0% st Cpu1: 0,0% сша, 0,8% sy, 0,0% ni, 93,0% id, 0,2% wa, 0,0% hi, 6,0% si, 0,0% st Cpu2: 0,0% сша, 0,6% sy, 0,0% ni, 94,4% id, 0,1% wa, 0,0% hi, 4,8% si, 0,0% st Cpu3: 0,0% сша, 7,5% sy, 0,0% ni, 36,3% id, 56,1% wa, 0,0% hi, 0,0% si, 0,0% st Cpu4: 0,0% сша, 1,3% sy, 0,0% ni, 85,7% id, 4,9% wa, 0,0% hi, 8,1% si, 0,0% st Cpu5: 0,1% сша, 5,5% sy, 0,0% ni, 36,2% id, 58,3% wa, 0,0% hi, 0,0% si, 0,0% st CPU6: 0,0% США, 5,0% sy, 0,0% ni, 36,3% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st Cpu7: 0,0% сша, 5,1% sy, 0,0% ni, 36,3% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st Cpu8: 0,1% сша, 8,3% sy, 0,0% ni, 27,2% id, 64,4% wa, 0,0% hi, 0,0% si, 0,0% st Cpu9: 0,1% США, 7,9% sy, 0,0% ni, 36,2% id, 55,8% wa, 0,0% hi, 0,0% si, 0,0% st Cpu10: 0,0% сша, 7,8% sy, 0,0% ni, 36,2% id, 56,0% wa, 0,0% hi, 0,0% si, 0,0% st Cpu11: 0,0% сша, 7,3% sy, 0,0% ni, 36,3% id, 56,4% wa, 0,0% hi, 0,0% si, 0,0% st Cpu12: 0,0% сша, 5,6% sy, 0,0% ni, 33,1% id, 61,2% wa, 0,0% hi, 0,0% si, 0,0% st Cpu13: 0,1% сша, 5,3% sy, 0,0% ni, 36,1% id, 58,5% wa, 0,0% hi, 0,0% si, 0,0% st Cpu14: 0,0% сша, 4,9% sy, 0,0% ni, 36,4% id, 58,7% wa, 0,0% hi, 0,0% si, 0,0% st Cpu15: 0,1% США, 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+ МБ / с.
У кого-нибудь есть идеи, куда ушла моя пропускная способность?
Спасибо!