2

Я сделал экстремальные испытания. cp, dd, rysnc, iperf, netcat, custom-dd и, возможно, больше.

Я смотрю на сильную сеть. Приведенные ниже результаты iperf показывают это, и у меня есть и другие данные для его проверки.

Я ищу протокол обмена, который будет соответствовать этим скоростям или даже приближаться к ним.

То, что я сейчас получаю с протоколами совместного использования iSCSI (FreeNAS) и CIFS (WIN7), составляет от 1,5 ГБ / м до 2,5 ГБ / м. Моя цель - 3,0 ГБ / м.

Что я мог напортачить в реализации протокола обмена, который так резко снижает скорость? 

root@fdas:~# ./iperf -c 192.168.2.138
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43066 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-10.0 sec  1.05 GBytes   900 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 60
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 43067 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-60.0 sec  6.22 GBytes   891 Mbits/sec
root@fdas:~# ./iperf -c 192.168.2.138 -t 600
------------------------------------------------------------
Client connecting to 192.168.2.138, TCP port 5001
TCP window size: 16.0 KByte (default)
------------------------------------------------------------
[  3] local 192.168.2.118 port 35506 connected with 192.168.2.138 port 5001
[ ID] Interval       Transfer     Bandwidth
[  3]  0.0-600.0 sec  62.0 GBytes   887 Mbits/sec

// редактирование бенчмарков добавлено. ПРИМЕЧАНИЕ: этот тест hdparm читает в последовательном порядке, и конечной целью здесь является чтение и запись сырых байтов с диска (всего диска, а не раздела)

/dev/sdd1 on /a type ext4 (rw)

ПРИМЕЧАНИЕ: sdd - это диск FreeNAS iSCSI

root@fdas:~# hdparm -t /dev/sdd

/dev/sdd:
 Timing buffered disk reads:  168 MB in  3.02 seconds =  55.71 MB/sec
root@fdas:~# hdparm -t -T /dev/sdd

/dev/sdd:
 Timing cached reads:   5240 MB in  2.00 seconds = 2620.70 MB/sec
 Timing buffered disk reads:  168 MB in  3.01 seconds =  55.84 MB/sec
|источник

2 ответа2

2

По моему опыту, iSCSI - это самая низкая нагрузка из всей группы, а огромные кадры в конечном итоге считаются. Я видел, как iSCSI насыщает соединение GigE, используя инфраструктуру LIO-Target iSCSI и виртуальный диск в качестве цели. Эта вещь полетела. Старая версия стека Linux iSCSI имела некоторые проблемы с производительностью и не могла использовать виртуальный диск для полной пропускной способности. Я не уверен, что FreeNAS работает в эти дни, LIO-Target довольно недавно.

Одним из главных ограничений такой пропускной способности является серверная часть системы хранения. Как я уже упоминал, я получил вышеупомянутую скорость благодаря использованию оперативного диска (на сервере было 32 ГБ ОЗУ, поэтому стоило попробовать). Когда я попробовал тот же тест, используя хранилище, распределенное по 48 дискам, я смог насыщать GigE во время последовательных тестов, но случайные тесты ввода / вывода были намного ниже этого; в диапазоне 65-80МБ / с, насколько я помню.

|источник
2

Вы запускали тесты дискового ввода-вывода как на сервере, так и на клиенте? Если дисковые подсистемы не способны обеспечить необходимую вам пропускную способность, они, конечно, будут узким местом, а не сетью.

|источник

Всё ещё ищете ответ? Посмотрите другие вопросы с метками .