LINUX.ORG.RU
ФорумAdmin

Тюнинг TCP стека

 ,


3

5

Добрый день, коллеги.

Хотелось бы услышать людей с реальным опытом тюнинга TCP-стека на ядре 2.6. Статей в интернете 100500, и 95% из них переводы/копипаст одного и того же. И все это я уже проштудировал.

Столкнулся с тем, что для новых TCP-соединений первое время (около 2-3 перезодов по страницам сайта, допустим) задержки выше, чем обычно.

Стоит nginx, весь контент в кеше. При первоначальной загрузке основная страница загружается барузер посетителя за 400-500 мс (при пинге до сервера в районе 120). 2-я страница за 280 мс. Третья - четвертая тоже 280 мс. Далее все страницы загружаются за 150 мс. Сам nginx тут не причем. Проблема наблюдается именно при работе с новыми соединениями. Если закрыть браузер, все повторяется; если подождать в пределах keep-alive и продолжить серфинг - все грузится за те же 150мс. Но стоит браузер перезапустить и на новых соединениях опять начнется с 500 мс. Конечно, дело не в браузере.

Природа долгой первой загрузки ясна (разрешение DNS и установка соединения, видимо). Но непонятно почему потом некоторое время все отдается по 280 мс. А потом вдруг 150. Хотелось бы сразу 150.

sysctl:

net.ipv4.ip_forward = 0
net.ipv4.conf.default.rp_filter = 1
net.ipv4.conf.default.accept_source_route = 0

# Controls the use of TCP syncookies
net.ipv4.tcp_syncookies = 0

kernel.msgmnb = 65536
kernel.msgmax = 65536
kernel.shmmax = 68719476736
kernel.shmall = 4294967296

net.ipv4.ip_conntrack_max = 2621440
net.ipv4.netfilter.ip_conntrack_max = 2621440

net.core.netdev_max_backlog = 3000
net.core.rmem_max = 16777216
net.core.wmem_max = 16777216
net.ipv4.tcp_rmem = 4096 87380 16777216
net.ipv4.tcp_wmem = 4096 65536 16777216
# and ip route change default via 35.28.51.2 dev eth0 initcwnd 10
net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_tw_reuse = 1

Помимо всего прочего пытался вертеть по разному:

net.ipv4.tcp_no_metrics_save
net.ipv4.tcp_congestion_control (остановится на htcp)
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_max_tw_buckets
net.ipv4.tcp_max_syn_backlog
net.ipv4.tcp_moderate_rcvbuf
net.ipv4.tcp_window_scaling
Но с них толку не было и пришлось вернуть все на место. Единственное, что реально повлияло на ситуацию (-200мс на любой запрос), это установка initcwnd 10. Есть советы?

Природа долгой первой загрузки ясна (разрешение DNS и установка соединения, видимо). Но непонятно почему потом некоторое время все отдается по 280 мс. А потом вдруг 150. Хотелось бы сразу 150.

Быть может браузер кеширует у себя что-то (например статические картинки, текст), и потом банально просто меньше запрашивает с сервера? Попробуй позапрашивать страницы через wget, посмотри на время.

P.S. я не спец в этом, просто предполагаю... :)

DALDON ★★★★★ ()

А если после первой страницы немного подождать, та же фигня? Браузер использует только одно соединение для работы с сервером? Другие соединения не устанавливает? А то может он просто создает некий пул соединений, после чего им пользуется без установления новых.

Kiborg ★★★ ()
Ответ на: комментарий от DALDON

При первоначальной загрузке сайта есть только запросы к страничке и паре динамических JS. В логе nginx в принципе видно что запросы только к ним и они всегда именно такие, что там 500мс ожидание, что 150.

В любом случае в nginx expire для статики я не прописывал и собирался это сделать в ближайшее время, как сделаю - напишу.

Amoled ()
Ответ на: комментарий от Kiborg

При первой загрузке создается пачка соединений сразу (около 7). После остается только одно (которое keep-alive), остальные закрываются. Дальше все по нему гоняется. Почему я сразу и подумал в принципе что задержка именно в создании соединения. В принципе меня DALDON навел на мысль - а что, если и правда статика проверяется на обновление, я особо не обращал внимание на логи первой загрузки. Хотя, конечно, почему на 2-й странице это происходит - непонятно, все уже загружено должно быть.

Amoled ()

nginx и браузер это сложно. Для тестирования луче-бы использовать что-то предельно простое, например простейший пинг-сервер на любимом скриптовом языке, или вообще на nc с какой-то скриптовой обвязкой.

MrClon ★★★★★ ()

Установите стандартные TCP-окна побольше:

net.ipv4.tcp_slow_start_after_idle = 0
net.ipv4.tcp_fastopen = 3
net.ipv4.tcp_rmem = 4096 262143 4194304
net.core.rmem_max = 4194304
net.core.rmem_default = 262143
net.ipv4.tcp_wmem = 4096 262143 4194304
net.core.wmem_max = 4194304
net.core.wmem_default = 262143

net.ipv4.tcp_keepalive_time = 300
net.ipv4.tcp_keepalive_intvl = 60
net.ipv4.tcp_keepalive_probes = 3

net.ipv4.tcp_fin_timeout = 10
net.ipv4.tcp_retries2 = 5

net.ipv4.tcp_congestion_control = yeah
Вот мой sysctl-конфиг. Yeah на старых (<3.4) ядрах использовать не рекомендую, там баг был какой-то, что он CPU жрал. Ну и увеличивать нужно не только initcwnd, но и initrwnd. Я использую значение 20 для обоих параметров.

ValdikSS ★★★★★ ()
Ответ на: Re: нет пути от wakuwaku

2.6. Чем богаты.

Посмотрел внимательнее tcpdump и понял в чем проблема. Сналача сервер отвечает вот такими пакетами 12:22:33.979995 IP *.*.*.*.80 > 192.168.1.175.29013: . 1461:2921(1460) ack 381 win 6432

Потом такими

12:22:45.999559 IP *.*.*.*.80 > 192.168.1.175.29013: . 8316:9776(1460) ack 941 win 7840

Далее

12:22:54.004220 IP *.*.*.*.80 > 192.168.1.175.29013: . 17897:19357(1460) ack 1515 win 8610

И наконец 12:23:06.639769 IP *.*.*.*.80 > 192.168.1.175.29013: . 26939:28399(1460) ack 2116 win 10217

Как видите отличается win. Его размер соответствует картинка тому как долго запрос обрабатывается. Проверял несколько раз. Ну и у новых соединений все начинается с 5840 опять (S 1168619423:1168619423(0) ack 1785540070 win 5840 <mss 1460,nop,nop,sackOK>). Буду разбираться как настроить сразу большое окно (если это оно конечно).

Amoled ()

есть некоторые сомнения, что дефаултные настройки сетевого стека не оптимальны под средне-статистическую задачу...

посмотрите по f12 (chrome) -> network на что тратится время при получении страниц, особо имеет смысл обратить внимание на
наличие/отсутствие 304 ответов

neomag ()
Ответ на: комментарий от neomag

так же отбросить версию с сетью поможет локальное тестирование времени ответов, если так же - дело не в сети...

neomag ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.