digsi Опубликовано 1 января, 2014 · Жалоба Есть связка из двух машин 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. есть предположение, что может где буферов не хватает или чего другого. Может кто подскажет куда копнуть или затюнить где? Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
CNick Опубликовано 2 января, 2014 · Жалоба Может проблема с реализацией шифрования? То есть в VPN софте нету поддержки AES-NI или ESXi не передает эту функцию аппаратно на гостевую ОС, но это так, мысли в слух. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
uxcr Опубликовано 2 января, 2014 · Жалоба net.core.netdev_max_backlog net.ipv4.udp_rmem_min Только сначала нужно подумать над netstat -s/netstat -i, обычно довольно редко проблема оказывается в буферах стека. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
digsi Опубликовано 2 января, 2014 · Жалоба CNick тут явно поддержка aes-ni есть, 80 мбайт - только одно ядро загружается на 80-100% , без поддержки было бы 20-30 мбайт\сек. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Mikler Опубликовано 2 января, 2014 · Жалоба О что вы к стеку привязались? Он работает есть пить не просит. Собственно интересны параметры, что происходит netstat первое надо посмотреть. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
digsi Опубликовано 4 января, 2014 (изменено) · Жалоба изменил размеры буферов по этой статье - http://sudouser.com/optimizaciya-tcpip-steka-v-linux-freebsd-mac-os-x-i-drugix-operacionnyx-sistemax.html в пике стало до 105 мбайт\сек доходить как посмотреть текущие размеры буферов? Сначала после загрузки скорость маленькая, потом вырастает до максимальных размеров. Изменено 4 января, 2014 пользователем digsi Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 4 января, 2014 · Жалоба Если у вас там TCP то ставьте cc=htcp Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
digsi Опубликовано 4 января, 2014 · Жалоба 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 Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
Ivan_83 Опубликовано 5 января, 2014 · Жалоба SACK=1 (с обоих сторон) и tcp.cc=htcp (на сервере) кардинально влияют на скорость. Ещё delay_ask=0 на клиенте, но проц выжирает сильнее. В некоторых случаях вместо htcp лучше hybla или ещё что то. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
zhenya` Опубликовано 5 января, 2014 · Жалоба но у него удп же.. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
fixx Опубликовано 7 января, 2014 · Жалоба ээ так надо в несколько потоков делать Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
digsi Опубликовано 8 января, 2014 · Жалоба пробовали в несколько потоков - скорость не растет, но у нас только был один источник, поэтому правильно не смогли проверить на тестах. Поставим в рабочую эксплуатацию, будут много источников и назначений, поднимем пару линков tap. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...
digsi Опубликовано 9 января, 2014 · Жалоба увеличил буфера по максимуму, сделал очереди 2000 на eth, 1000 на tap0. Скорость передачи с 80 до 100, средняя 88 примерно. Вставить ник Цитата Ответить с цитированием Поделиться сообщением Ссылка на сообщение Поделиться на других сайтах More sharing options...