Перейти к содержимому
Калькуляторы

тюнинг сетевых и стека tcp на Ubuntu может кто делал или есть форум

Есть связка из двух машин

I5-3770K 4 гига, сетевая Intel x520-da2 c двумя sfp 1 Gb. На машинах стоит vmware esxi 5.1, внутри виртуальная машина с ubuntu 13, 2 вирт. ядра, гиг памяти , 4 гига вирт. диск. Поднимаем шифрование aes-256-cbc на openvpn, скорость передачи в районе 70 мбайт\сек, iperf показывает 810 мбит.

Подняты еще машины с 2008 server R2, по самбе гоняются файлы для теста через шифрованный канал. Вначале при копировании показывает 100-120 мбайт\сек.

Есть дропнутые пакеты TX на интерефейс tap. есть предположение, что может где буферов не хватает или чего другого.

Может кто подскажет куда копнуть или затюнить где?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Может проблема с реализацией шифрования? То есть в VPN софте нету поддержки AES-NI или ESXi не передает эту функцию аппаратно на гостевую ОС, но это так, мысли в слух.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

net.core.netdev_max_backlog

net.ipv4.udp_rmem_min

 

Только сначала нужно подумать над netstat -s/netstat -i, обычно довольно редко проблема оказывается в буферах стека.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

CNick тут явно поддержка aes-ni есть, 80 мбайт - только одно ядро загружается на 80-100% , без поддержки было бы 20-30 мбайт\сек.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

О что вы к стеку привязались? Он работает есть пить не просит. Собственно интересны параметры, что происходит netstat первое надо посмотреть.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

изменил размеры буферов по этой статье - http://sudouser.com/optimizaciya-tcpip-steka-v-linux-freebsd-mac-os-x-i-drugix-operacionnyx-sistemax.html

в пике стало до 105 мбайт\сек доходить

как посмотреть текущие размеры буферов?

 

Сначала после загрузки скорость маленькая, потом вырастает до максимальных размеров.

Изменено пользователем digsi

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Если у вас там TCP то ставьте cc=htcp

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

tap по udp

растет значение у sndbuferrors. Передача от этого рывками и скорость падает. Прочитал что связано когда канал больше 200 mbit, у меня около 800 mbit. Что нужно изменить, чтобы эта ошибка перестала расти?

txqueuelen на eth - 1000 на tap - 200, mtu на tap - 12000.

sysctl -p

net.core.rmem_max = 33554432

net.core.wmem_max = 33554432

net.core_rmem_default = 8388608

net.core.wmem_default = 4194394

net.ipv4.tcp_rmem = 8388608 8388608 16777216

net.ipv4.tcp_wmem = 4194394 4194394 16777216

net.ipv4.tcp_window_scaling = 1

net.ipv4.tcp_timestamps = 1

net.ipv4.tcp_sack = 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

SACK=1 (с обоих сторон) и tcp.cc=htcp (на сервере) кардинально влияют на скорость. Ещё delay_ask=0 на клиенте, но проц выжирает сильнее.

В некоторых случаях вместо htcp лучше hybla или ещё что то.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

пробовали в несколько потоков - скорость не растет, но у нас только был один источник, поэтому правильно не смогли проверить на тестах. Поставим в рабочую эксплуатацию, будут много источников и назначений, поднимем пару линков tap.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

увеличил буфера по максимуму, сделал очереди 2000 на eth, 1000 на tap0. Скорость передачи с 80 до 100, средняя 88 примерно.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Гость
Ответить в тему...

×   Вставлено в виде отформатированного текста.   Вставить в виде обычного текста

  Разрешено не более 75 смайлов.

×   Ваша ссылка была автоматически встроена.   Отобразить как ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставить изображения напрямую. Загрузите или вставьте изображения по ссылке.