digsi Posted January 1, 2014 Posted January 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. есть предположение, что может где буферов не хватает или чего другого. Может кто подскажет куда копнуть или затюнить где? Вставить ник Quote
CNick Posted January 2, 2014 Posted January 2, 2014 Может проблема с реализацией шифрования? То есть в VPN софте нету поддержки AES-NI или ESXi не передает эту функцию аппаратно на гостевую ОС, но это так, мысли в слух. Вставить ник Quote
uxcr Posted January 2, 2014 Posted January 2, 2014 net.core.netdev_max_backlog net.ipv4.udp_rmem_min Только сначала нужно подумать над netstat -s/netstat -i, обычно довольно редко проблема оказывается в буферах стека. Вставить ник Quote
digsi Posted January 2, 2014 Author Posted January 2, 2014 CNick тут явно поддержка aes-ni есть, 80 мбайт - только одно ядро загружается на 80-100% , без поддержки было бы 20-30 мбайт\сек. Вставить ник Quote
Mikler Posted January 2, 2014 Posted January 2, 2014 О что вы к стеку привязались? Он работает есть пить не просит. Собственно интересны параметры, что происходит netstat первое надо посмотреть. Вставить ник Quote
digsi Posted January 4, 2014 Author Posted January 4, 2014 (edited) изменил размеры буферов по этой статье - http://sudouser.com/optimizaciya-tcpip-steka-v-linux-freebsd-mac-os-x-i-drugix-operacionnyx-sistemax.html в пике стало до 105 мбайт\сек доходить как посмотреть текущие размеры буферов? Сначала после загрузки скорость маленькая, потом вырастает до максимальных размеров. Edited January 4, 2014 by digsi Вставить ник Quote
Ivan_83 Posted January 4, 2014 Posted January 4, 2014 Если у вас там TCP то ставьте cc=htcp Вставить ник Quote
digsi Posted January 4, 2014 Author Posted January 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 Вставить ник Quote
Ivan_83 Posted January 5, 2014 Posted January 5, 2014 SACK=1 (с обоих сторон) и tcp.cc=htcp (на сервере) кардинально влияют на скорость. Ещё delay_ask=0 на клиенте, но проц выжирает сильнее. В некоторых случаях вместо htcp лучше hybla или ещё что то. Вставить ник Quote
fixx Posted January 7, 2014 Posted January 7, 2014 ээ так надо в несколько потоков делать Вставить ник Quote
digsi Posted January 8, 2014 Author Posted January 8, 2014 пробовали в несколько потоков - скорость не растет, но у нас только был один источник, поэтому правильно не смогли проверить на тестах. Поставим в рабочую эксплуатацию, будут много источников и назначений, поднимем пару линков tap. Вставить ник Quote
digsi Posted January 9, 2014 Author Posted January 9, 2014 увеличил буфера по максимуму, сделал очереди 2000 на eth, 1000 на tap0. Скорость передачи с 80 до 100, средняя 88 примерно. Вставить ник Quote
.png.5d2afa2996cc6a85d0f2c09b92dd0a28.png)
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.