Назад | Перейти на главную страницу

Почему jumbo-кадры влияют на производительность сервера

Обновление: должен ли я устанавливать только jumbo-фрейм для сервера и файлового сервера, а не для клиента?

Если да, то влияет ли это на связь между сервером и клиентом?

Я провожу тест производительности для нашего продукта.

В настоящее время все машины, связанные с тестированием (серверы, файловые серверы, клиенты, базы данных), находятся в сети 10G, подключенной мощным коммутатором Dell OpenManage Switch.

Мы используем iscsi для файлового сервера. У нас есть кластерный сервер, состоящий из нескольких узлов.

Тест производительности, который я выполняю, в основном состоит в моделировании следующего сценария: 1. Клиентский компьютер создает большое количество потоков для отправки HTTP-запроса на сервер. 2. В зависимости от типа запросов серверу необходимо получить некоторые данные с файлового сервера, которые используются всеми остальными узлами сервера.

Результаты теста: Без jumbo-кадров, MTU 1500, ЦП сервера 70%, а среднее время ответа на HTTP-запрос составляет 1 секунду.

При использовании jumbo-кадров MTU 9000, ЦП сервера 20% и среднее время ответа на HTTP-запрос составляет 5 секунд.

Мы настроили jumbo-кадры на всех машинах и изменили настройки TCP.

Любые идеи?

Хорошо:

  • Большие кадры = больше данных в каждом пакете = ваш ЦП меньше работает для отправки данных (у него меньше пакетов в секунду), но для сборки каждой полезной нагрузки требуется больше времени (большая задержка).
  • Меньшие кадры = меньше данных в каждом пакете = ваш процессор больше работает для отправки данных (больше пакетов в секунду), но требует меньше времени для сборки каждой полезной нагрузки (меньше задержки).

Я пытался прочитать и понять больше о влиянии использования Jumbo-фреймов и Зачем она все еще не стала мейнстримом спустя более десяти лет. Этот документ намекает на реальные проблемы, с которыми сталкиваются размеры Jumbo-фреймов, не позволяя достичь большего, чем сценарий массовой передачи файлов.

http://www.chelsio.com/jumbo_enet_frames.html

Сводка проблем, способствующих задержкам с высокой задержкой

  1. Отложенная конвейерная передача по средам передачи
  2. Небольшие буферы передачи / приема, вызывающие потерю пакетов = повторная передача
  3. Больший размер пакета = более высокая вероятность столкновения = повторная передача
  4. Более низкое качество CRC при большей длине полезной нагрузки = поврежденные пакеты = повторная передача
  5. Обнаружение MTU сквозного пути, в обоих направлениях

Ваш «сервер» должен иметь один интерфейс для iSCSI (этот интерфейс - дисковая шина!) И один интерфейс для клиентов для доступа к серверу. Интерфейс iSCSI должен иметь значение MTU9000, интерфейс клиентского доступа должен иметь значение MTU по умолчанию. Кроме того, ваш коммутатор должен быть настроен для поддержки как jumbo-кадров, так и управления потоком, иначе производительность будет отстой.