Домашний стораджбокс: производительность iSCSI/SRP, FreeBSD/Linux

Как и обещал, привожу результаты тестирования перформанса нового дискового ящика.

Помня о весенних результатах (когда тестировался доступ по 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).

Серверный софт:

1. Ubuntu Server 12.04, драйвера Infiniband и iscsitarget из поставки, scst из гнезда (trunk), при установке scst ядро патчилось согласно инструкции.
2. 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()), без этого мы тестируем клиентский кэш и результаты очень разные.

Результаты

Все цифры в таблице - в мегабайтах (2²⁰ байт) в секунду. 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 на клиенте. Неудобно, да.