Кросспост из
блога автора. Комментировать лучше
там, но можно и тут
Как и обещал, привожу результаты тестирования перформанса
нового дискового ящика.
Помня о
весенних результатах (когда тестировался доступ по Infiniband к RAM-диску), я не стал тратить много времени на Samba (хотя и померял, см. ниже) и вдумчиво тестировал только iSCSI/SRP варианты.
Hardware
Клиент: Intel i7-2600K без оверклока, 16Gb RAM (DDR3-1600), Windows7. Файрволл выключен, антивирус - деинсталлирован (с антивирусом получается весело, но результаты невоспроизводимы).
Сервер: Intel i5-2400 без оверклока, 8GB RAM, Adaptec ASR-5805, 6x Seagate Barracuda ES.2 SAS 1Tb + 2 WD RE4 SATA 1Tb, объединены в RAID-6 (контроллер ругается, что SAS и SATA смешаны в одном томе, а мне плевать).
Сеть: Mellanox Infinihost Ex III (MHEA28-XTC), 10(8) Gbit/s, две карты соединены кабелем.
Сетевые протоколы: iSCSI (по IPoIB), SRP (SCSI RDMA Protocol).
Серверный софт:
- Ubuntu Server 12.04, драйвера Infiniband и iscsitarget - из поставки, scst - из гнезда (trunk), при установке scst ядро патчилось согласно инструкции.
- FreeBSD 9.1 Prerelease (свежий cvsup), istgt из портов.
SRP поддерживается только scst, остальные два варианта работали по iscsi.
Клиентский софт: iSCSI initiator из комплекта Win7. Infiniband SRP Initiator из комплекта Infiniband-драйверов openfabrics.org (OFED 3.1).
IPoIB Connected Mode у OFED 3.1 работает только Windows-Windows (в 3.0 - работало Windows-Linux). Возможно, причина не в Windows-стороне, а в других драйверах с Linux-стороны, детально не разбирался, жил с MTU 2044.
Бенчмарка
Меня интересует чтение запись больших и мелких файлов в один поток (ибо рабочая станция), в прошлый раз я сделал бенчмарку из говна и палок (набора файлов и секундомера), сейчас же решил пару часов попрограммировать.
Короткие файлы
- Порождаем 163840 файлов длиной 16384 байта каждый, разложенных в 256 каталогов (16 верхнего уровня, в каждом 16 подкаталогов). Файлы размазаны по каталогам round-robin.
В файлы пишутся псевдорандом-данные. На всякий случай.
- Сбрасываем кэш (вручную: размонтированием диска или перезагрузкой), затем читаем вышеописанные файлы в том же порядке.
Этап записи малочувствителен к количеству файлов, первые 16к пишутся примерно с той же скоростью, что и вторые. С чтением иначе: первые ~10-20к файлов читаются медленно (пока насосется кэш MFT), остальные - значительно (в разы) быстрее. Несмотря на это, тестирование чтения дает повторяемые результаты с приемлемым разбросом (5-8%).
Длинные файлы
- Пишем 40 гигабайт файла (псевдорандом-данные) кусками по 1Gb.
- Читаем их же. Сразу, без перезагрузки/размонтирования.
- И на чтение и на запись файлы открываются «мимо кэша» (FILE_FLAG_NO_BUFFERING у CreateFile()), без этого мы тестируем клиентский кэш и результаты очень разные.
Результаты
Все цифры в таблице - в мегабайтах (220 байт) в секунду. Short read/write можно перевести в файлы в секунду умножением на 64.
Система/ПО
Long write
Long read
Short write
Short read
FreeBSD, iSCSI
435
657
56
33
Linux, iSCSI
650
630
63
19
Linux, SRP
654
636
131
45
Linux, Samba 3.6
604
260
15
20
Samba - приведена для сравнения, что будет медленно - и так было понятно по результатам предыдущих тестов. У меня нет идей, почему длинное чтение на Samba такое медленное: каких-то особых узких мест не видно, smbd жрет около 30% CPU, диск недогружен, все свободно. Возможно, есть какой-то упор в RTT на сети, не знаю.
Второе удивление - медленная запись на FreeBSD. Объяснений у меня нет, UFS2 на этом же разделе диска дает писать в себя со скоростью 585Mb/sec. Тоже, помедленнее Linux/Win7 на локальном диске, но не 450 Mb/sec же. Оверхед на чтение, как видим, у istgt - низкий.
В остальном же - все примерно как и ожидалось: SRP сильно быстрее на коротких операциях и примерно такой же (как и iSCSI over IPoIB) на длинных.
P.S. Пойду запихивать драйвера Infiniband в recovery-сидюк... ничего не вышло за 10 минут, оказалось проще поднять лишний гигабитный ethernet-линк, чисто для рекавери.
P.P.S. scst маленько кривоват, поэтому если перегрузили сервер, то придется рестартовать SRP storage driver на клиенте. Неудобно, да.