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

Размеры буфера TCP и соединение Ethernet

(Этот вопрос изначально был размещен на переполнение стека; Энди сказал мне, что здесь я мог бы получить более быструю помощь, поэтому сейчас она повторно размещена здесь.)

Я экспериментирую с настройкой размера буфера TCP в Linux, но разные результаты сбивают меня с толку.

В тестовые программы входят сервер и клиент. Сервер просто прослушивает порт, ожидая, пока клиент отправит данные из файла mmaped. Полученные данные копируются в буфер приложения с помощью recv а потом упал. При отправке данных клиент использует send с полным размером буфера mmapped в качестве начального аргумента.

Программы работают на двух узлах из двух разных центров обработки данных, время отклика на пинг между ними составляет около 9 мсек. На обоих узлах установлено по два контроллера Gigabit Ethernet. Максимальная пропускная способность составляет 256 МБ / с, а правильная установка размеров буфера отправки / получения должна быть около 256 МБ / с * 0,09 с ~ 2415919 байт.

Я провел несколько экспериментов.

При первом запуске я запустил один экземпляр сервера и один экземпляр клиента. Я не устанавливал размер ни отправляющего, ни принимающего буфера, позволяя ядру настраивать их автоматически. Цель этого случая - установить основу для других экспериментов.

Фактическая пропускная способность при этой настройке составляла около 117 МБ / с. В этом случае одна пара сервера и клиента использовала только один контроллер любой сети. Проверка с ifconfig, Я видел, что большинство пакетов прошло через единственный интерфейс между eth0 и eth1.

Затем я попробовал два сервера и два клиента, на этот раз пропускная способность увеличилась примерно до 225 МБ / с, что намного ближе к идеальной максимальной пропускной способности.

Это первая проблема, которая меня смущает:

  1. Почему мне нужно несколько процессов, чтобы использовать полосу пропускания? FWIW, ниже является частью /proc/net/bonding/bond0:

    Bonding Mode: IEEE 802.3ad Dynamic link aggregation
    Transmit Hash Policy: layer3+4 (1)
    MII Status: up
    MII Polling Interval (ms): 100
    Up Delay (ms): 0
    Down Delay (ms): 0
    

Затем я попробовал несколько комбинаций размеров буфера отправки / получения для одной пары сервера и клиента. В следующей таблице приведены результаты:

| send buf size | recv buf size | throughput | comment                   |
|      (client) |      (server) |     (MB/s) |                           |
|       1048576 |             - |       51.5 |                           |
|       2621400 |             - |       48.6 | server uses autotuning    |
|        524288 |             - |       43.3 |                           |
|       8388608 |             - |       36.3 |                           |
|       2621400 |       2621400 |       33.0 | somewhat the theory value |
|             - |       2621400 |       30.4 | client uses autotuning    |
|       4194304 |             - |       30.3 |                           |
|        262144 |             - |       29.1 |                           |
|             - |       1048576 |       27.9 |                           |
|       6291456 |       6291456 |       26.5 |                           |
|       8388608 |       8388608 |       23.9 |                           |
|       6291456 |             - |       22.2 |                           |
|             - |       4194304 |       20.8 |                           |
|       1048576 |       1048576 |       19.8 |                           |
|       4194304 |       4194304 |       19.3 |                           |
|             - |       8388608 |       19.3 |                           |
|             - |       6291456 |       13.8 |                           |

Вот еще несколько вопросов, поднятых в приведенной выше таблице:

  1. Почему теоретическая ценность не дает наилучшей пропускной способности (117 МБ / с)?
  2. Почему лучший результат (51,5 МБ / с) все же не так хорош, как результат автонастройки ядра (117 МБ / с)?
  3. Почему больший буфер приводит к снижению пропускной способности?

Заранее спасибо.