Сокеты Java на RDMA (JSOR) и производительность jVerbs в Infiniband
У меня есть базовое понимание как JSOR, так и jVerbs.
Оба обрабатывают ограничения JNI и используют быстрый путь для уменьшения задержки. Оба они используют пользовательский интерфейс RDMA Verb для избежания переключения контекста и обеспечения быстрого доступа. У обоих также есть варианты для передачи нулевой копии.
Разница в том, что JSOR все еще использует интерфейс Java Socket. JVerbs предоставляет новый интерфейс. У jVerbs также есть то, что называется Stateful Verbs Call, чтобы избежать повторной сериализации запросов RDMA, которые, по их словам, уменьшают задержку. jVerbs предоставляет более родной интерфейс, и приложения могут напрямую использовать их. Я прочитал статью jVerbs SoCC 2013, в которой они строят jverbsRPC поверх jVerbs и показывают, что это значительно уменьшает задержку операций zookeeper и memcache.
Документация для обоих показывает, что они работают лучше, чем обычные сокеты Java на основе TCP/IP, SDP и IPoIB.
У меня нет сравнения производительности между JSOR и jVerbs. Я думаю, что jVerbs может работать лучше, чем JSOR. Но с JSOR мне не нужно менять существующий код, потому что он все еще использует тот же интерфейс сокетов Java. Мой вопрос заключается в том, что может быть увеличение производительности использования jVerbs по сравнению с JSOR. Кто-нибудь знает или имеет опыт работы с этими двумя? Если у вас есть сравнительные данные, это будет здорово. Я не мог найти ни одного.
2 ответа
Вот несколько примеров использования DiSNI - недавно открытого источника IBM jVerbs - и DaRPC, RPC-библиотеки с низкой задержкой, использующей DiSNI.
- Задержка чтения DiSNI RDMA для 64 байтов меньше 2 микросекунд
- Задержки отправки / возврата DaRPC RDMA для 64 байтов (запрос и ответ) составляют около 5 микросекунд
- Различия между RDMA для Java / DiSNI и C незначительны для односторонних операций
Эти тесты были выполнены на двух хостах, подключенных с использованием сетевого интерфейса Mellanox ConnectX-3.
Вот команды для выполнения тестов:
(1) Читать тест
Сервер:
java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-server -a <address> -o read -s 64 -k 100000 -p
Клиент:
java -cp disni-1.0-jar-with-dependencies.jar:disni-1.0-tests.jar com.ibm.disni.examples.benchmarks.AppLauncher -t java-rdma-client -a <address> -o read -s 64 -k 100000 -p
(2) отправка / получение контрольных показателей
Сервер:
java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.server.DaRPCServer -a <address> -d -l 64 -r 64
Клиент:
java -cp darpc-1.0-jar-with-dependencies.jar:darpc-1.0-tests.jar com.ibm.darpc.examples.client.DaRPCClient -a <address> -k 1000000 -l 64 -r 64 -b 1
Трудно сравнить производительность jVerbs против JSOR. Первый - это API, ориентированный на сообщения, а второй скрывает RDMA за потоковым API сокетов Java.
Вот некоторые характеристики. Мой тест проводился с использованием пары старых карт ConnectX-2 и серверов Dell PowerEdge 2970. CentOS 7.1 и Mellanox OFED версии 3.1.
Меня интересовал только тест на задержку.
jVerbs
Test - это разновидность RPing-примера (можете публиковать на github, если кому-то интересно). Проверьте измеренную задержку 5000000 циклов следующей последовательности вызовов через надежное соединение. Размер сообщения был 256 байтов.
PostSendMethod.execute()
PollCQMethod.execute()
CompletionChannel.ackCQEvents()
Результаты (микросекунды):
- Медиана: 10,885
- Процентиль 99,0%: 11,663
- Процентиль 99,9%: 17,471
- Процентиль 99,99%: 27,791
JSOR
Подобный тест через сокет JSOR. Тест был образцом сокета клиент / сервер учебника. Размер сообщения также составлял 256 байт.
Результаты (микросекунды):
- Медиана: 43
- Процентиль 99,0%: 55
- Процентиль 99,9%: 61
- Процентиль 99,99%: 217
Эти результаты очень далеки от теста латентности OFED. На том же оборудовании / стандарте ОС эталон ib_send_lat показал 2.77 в качестве медианы и 23.25 мкс в качестве максимальной задержки.