Доброе время суток!!!
Нужна помощь.Есть сервер на Win2k3, который подключен к серверу с ОС OpenSolaris по SRP (интерфейс InfiniBand).
Проблема - маленькая скорость Рандом чтения.
Помогите настроить карточки и системы на максимальную производительность.
Карточки: Mellanox ConnectX VPI (MT26428)
Доступные настройки (привожу с настройками по умолчанию):
GUID bitwise mask - 0
Large Send Offload - Disabled
MC leave rescan (sec) - 260
Number of retries connecting to bc - 50
Payload Mtu size - 2044
Receive Pool Ratio - 1
Receive Queue depth -512
Receive Queue Low Watermark -4
Recv Checksum Offload - Enable (if support)
SA Query Retry Count - 10
SA Query Timeout (ms) - 1000
Send Checksum Offload - Enabled (if support)
Send Queue Depth - 512
А про железо поподробнее? Какие драйвы, какая скорость получается в цифрахНа самом сервере опенсоляриса скорость нормальная? или на нем тоже маленькая?
> А про железо поподробнее? Какие драйвы, какая скорость получается в цифрах
> На самом сервере опенсоляриса скорость нормальная? или на нем тоже маленькая?Железо openSolaris:
CPU: 2x Intel Xeon CPU X5650 @ 2.67GHz, 6 Core
RAM: 48GB (8+8+8+8+8+8+4)
RAID: LSI MegaSAS 9260 -i8 (RAID10 - 4.8TB 15K диски 10шт.) - таргеты как блоковое устройство, не через ZFS - драйвер mr_sas
LAN: Mellanox Technologies MT26428[ConnectX VPI PCIe 2.0 5TG/s -IB QDR / 10GigE] 40 GB/sec - драйвер hermonЖелезо Windows:
CPU: 2x Intel Xeon CPU X5650 @ 2.67GHz, 6 Core
RAM: 32GB (8+8+8+8)
RAID: Adaptec ech10-r RAID 10, установлена только для системы - драйвер Adaptec с сайта производителя
LAN: Mellanox Technologies MT26428[ConnectX VPI PCIe 2.0 5TG/s -IB QDR / 10GigE] 40 GB/sec - драйвер Mellanox VPI 2.1.2 с сайта производителя + FIX для работы SRP протокола (получен через Support Mellanox)Скорость интерфейса 40 ГБ/сек
Скорость в цифрах:
Тест SQLIO с Windows сервера к LUN на Solaris (LUN'ы калибровались с отступом 1024)Диск размеченый 8К
--- Random Read o4 b8---
IOs/sec: 108444.28
MBs/sec: 847.22
------------------------
- Sequential Read o4 b8-
IOs/sec: 108382.54
MBs/sec: 846.73
------------------------
- Random Read o4 b64---
IOs/sec: 24392.86
MBs/sec: 1524.55
------------------------
- Sequential Read o4 b8-
IOs/sec: 24178.48
MBs/sec: 1511.15
------------------------
тут вроде нормально, все траблы начинаются с 64К размеченым дискомДиск размеченый 64К
--- Random Read o4 b8---
IOs/sec: 6328.88
MBs/sec: 49.44
------------------------
- Sequential Read o4 b8-
IOs/sec: 24172.90
MBs/sec: 188.85
------------------------
--- Random Read o4 b64--
IOs/sec: 1439.97
MBs/sec: 89.99
------------------------
- Sequential Read o4 b64-
IOs/sec: 3522.63
MBs/sec: 220.16
------------------------В рандом риде о4 b64 в 64к размеченом диске должно быть минимум 2500 IOs/sec
вот так вот.
>[оверквотинг удален]
> IOs/sec: 1439.97
> MBs/sec: 89.99
> ------------------------
> - Sequential Read o4 b64-
> IOs/sec: 3522.63
> MBs/sec: 220.16
> ------------------------
> В рандом риде о4 b64 в 64к размеченом диске должно быть минимум
> 2500 IOs/sec
> вот так вот.На самой Solaris скорость нормальная, все проблемы с сетевой работой, нужно как -то что-то оптимизировать.
> На самой Solaris скорость нормальная, все проблемы с сетевой работой, нужно как
> -то что-то оптимизировать.http://social.technet.microsoft.com/forums/ru-RU/sqlru/threa.../
http://www.google.com.ua/search?hl=uk&client=firefox-a&hs=Jm...
> вот так вот.Ну что, главным образом тут отрулил низколатентный интерфейс, по которому "хранилище" отдавало инфу, и почти 48 ГБ кэша ФС под ОС :) Т.е. если объем обрабатываемых за раз данных превысит объем кэша ФС (хотя по задачам для такого "хоронилища" это маловероятно) - чтение упрется в винты. А там пик (если взять IOMeter) - 4500-5000 IOps в синтетике и раза в 3-4 ниже в жизни...
Грабли Вас на этом пути ждут следующие:
- отказоустойчивость. Она - на уровне одиночного сервера, т.е. - минимальная. Сделать "второй контроллер" - никак. Ну или по методу NetApp...
- производительность на запись. Тут грабли следующие: или мы отключаем кэш ФС на запись - и все внезапно становится банально и грустно. Или мы его включаем - и - внезапно ! - теряем (потенциально)десятки гигабайт данных в кэше ФС при потере питания.
Тут можно последовать методом Open-E, которая умеет использовать внешний UPS как своеобразное BBU :) Своеобразное потому, что отрубить питание от всего, кроме модулей ОЗУ ОС все равно не может.
- дороговизна инфраструктуры. Рано или поздно потребуется подключить "хранилище" к более, чем одному-двум серверам, и - привет... IB стоит не сильно дешевле FC.
Тут решить нечем, велосипеды, проапгрейженные до самолетов, стоят обычно дороже собственно самолетов...
>[оверквотинг удален]
> мы его включаем - и - внезапно ! - теряем (потенциально)десятки
> гигабайт данных в кэше ФС при потере питания.
> Тут можно последовать методом Open-E, которая умеет использовать внешний UPS как своеобразное
> BBU :) Своеобразное потому, что отрубить питание от всего, кроме модулей
> ОЗУ ОС все равно не может.
> - дороговизна инфраструктуры. Рано или поздно потребуется подключить "хранилище" к более,
> чем одному-двум серверам, и - привет... IB стоит не сильно дешевле
> FC.
> Тут решить нечем, велосипеды, проапгрейженные до самолетов, стоят обычно дороже собственно
> самолетов...Ну вообще то не все так плохо как ты сказал :)
Повесили пару полок на SAS-HBA, под логи оставили райд 10. использовали кеш на чстение и на запись в виде SSD и получили 40-60к иопсов на чтение и 25-30к иопсов на запись =)
В качестве надежности данных под логи как уже сказал райд 10, а для данных ZFS по паре дисков =)