Проблема сети при большом количестве клиентов

[nick_f]

есть машина, на Fedora8, Пень4, 2Гб озу
на машине - сервис Verlihub (сервер p2p файлокачалки). при небольшом количестве соединений, все бегаеть.
при достижении количества соединений порядка 1к, - новые клиенты не могут зайти и сеть начинает страшно тупить.
смотрю "netstat | grep SYN" и вижу большое количество полуоткрытых соединений,(со статусом SYN_RECV)
нагуглил параметры sysctl - net.ipv4.tcp_max_syn_backlog и fs.file-max а также ulimit -n и ulimit -u
немного помогло, количество пользователей выросло в полтора раза, но проблема всеже осталась

по мне так проблема не в объеме траффика а в количестве подключений.
типа система не может сама либо не дает открыть хабу новые соединения
учитывая что при этом наблюдаются также бока с апачем... думаю проблема в системе,
вот бы кто подсказал, куда ее пнуть чоб она больше соединений открывала....

[Хостинг HostFood.ru]

Тарифы на хостинг в России, от 12 рублей: https://www.host-food.ru/tariffs/hosting/
Тарифы на виртуальные сервера (VPS/VDS/KVM) в РФ, от 189 руб.: https://www.host-food.ru/tariffs/virtualny-server-vps/
Выделенные сервера, Россия, Москва, от 2000 рублей (HP Proliant G5, Intel Xeon E5430 (2.66GHz, Quad-Core, 12Mb), 8Gb RAM, 2x300Gb SAS HDD, P400i, 512Mb, BBU):
https://www.host-food.ru/tariffs/vydelennyi-server-ds/
Недорогие домены в популярных зонах: https://www.host-food.ru/domains/

[weec]

хотелось бы глянуть на вывод (в пиковый момент)

Код: Выделить всё

netstat -st

[nick_f]

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

Код: Выделить всё

[root@serv ~]# netstat -st
IcmpMsg:
    InType0: 58
    InType3: 31555
    InType4: 1
    InType5: 139
    InType8: 6638
    InType11: 4737
    OutType0: 6300
    OutType3: 195420
    OutType5: 27
    OutType8: 248
    OutType11: 146
Tcp:
    247939 active connections openings
    596865 passive connection openings
    44681 failed connection attempts
    60149 connection resets received
    1296 connections established
    173794967 segments received
    211226014 segments send out
    49884306 segments retransmited
    6047 bad segments received.
    630153 resets sent
UdpLite:
error parsing /proc/net/netstat: Победа
[root@serv ~]#   

[LMik]

Наверное сокетов нехватает, надоб увеличить.

[weec]

присутствует немалое количество неудавшихся соединений
попробуй установить следующие параметры (можешь добавить в /etc/sysctl.conf)

Код: Выделить всё

net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_synack_retries = 3

это снизит количество левых соединений

можешь еще увеличить очередь отправки на интерфейсе

Код: Выделить всё

ifconfig eth0 txqueuelen 2000

потести и отпиши о результатах
дай ещё вывод

Код: Выделить всё

netstat -ni

[nick_f]

Наверное сокетов нехватает, надоб увеличить.

Сокетов хватает

мне тут посоветовали увеличить память, выделяемую под сетевой стек
на предмет этого нашел

Код: Выделить всё

net.ipv4.tcp_mem
net.core.wmem_default
net.core.rmem_default
net.core.wmem_max
net.core.rmem_max

для первого параметра поднял верхний предел в полтора раза, для остальных - в два раза, перезапустил приложение - особой разницы не чувствуется,
хотя может нада еще и "/etc/init.d/network restart" сделать?

[nick_f]

присутствует немалое количество неудавшихся соединений
попробуй установить следующие параметры (можешь добавить в /etc/sysctl.conf)

Код: Выделить всё

net.ipv4.tcp_fin_timeout = 30 
net.ipv4.tcp_keepalive_time = 1800
net.ipv4.tcp_synack_retries = 3

это снизит количество левых соединений

можешь еще увеличить очередь отправки на интерфейсе

Код: Выделить всё

ifconfig eth0 txqueuelen 2000

потести и отпиши о результатах
дай ещё вывод

Код: Выделить всё

netstat -ni

Спасибо, поставил, сейчас потещу,

Код: Выделить всё

[root@serv ~]# netstat -ni
Kernel Interface table
Iface       MTU Met    RX-OK RX-ERR RX-DRP RX-OVR    TX-OK TX-ERR TX-DRP TX-OVR Flg
eth0       1500   0  1732557      0      0      0  3173563      0      0      0 BMRU
eth0:0     1500   0      - no statistics available -                            BMRU
eth0:1     1500   0      - no statistics available -                            BMRU
eth1       1500   0    19282      0      0      0    13450      0      0      0 BMRU
eth2       1500   0     4661      0      0      0      193      0      0      0 BMRU
lo        16436   0     3723      0      0      0     3723      0      0      0 LRU
ppp0       1492   0     4450      0      0      0        3      0      0      0 MOPRU
[root@serv ~]#

да, кстати, замечание - основная масса соединений приходится на алиас eth0:1, не знаю, важно ли это,

[weec]

nick_f, не стоит пробовать все сразу, получится каша
пробуй сначала одно, потом другое
вообще, стоит вникать, что за параметры меняешь и на, что они влияют

[opt1k]

попутал маленько

http://www.hardtek.ru/sistem/linux_proptim.shtml

Код: Выделить всё

Файл file-max. Значение в этом файле определяет максимальное число дескрипторов файлов, которые может распределить ядро. Мы настраиваем этот файл на увеличение числа открытых файлов. Для серверных систем рекомендуется следующее правило: увеличьте значение /proc/sys/fs/file-max до значения примерно равного 256 на каждые 4M RAM, например, для машины со 128 M установите значение равное 8192 (128/4=32, 32*256=8192). По умолчанию в Red Hat file-max равен 4096. Чтобы изменить эти значения, используйте ...

[koffu]

У меня была похожая проблема, не мог никак найти проблему в кластере со сквидом (squid >2500 чел + frox, transparent 100Mb/s Fiber в UA-IX, суточный траффик 30-200Gb, главная нода P4 3,06GHz/2Gb RAM/IDE 40Gb HDD/3com 1Gb/s LAN, OS Debian 4.0). Решал следующими способами:
Во-первых, как приходит/уходит траффик?. Если все идет через одну, то если в равной степени нагрузить канал, получается своеобразный DDOS.Как и в твоем случае куча SYN соединений, закрывать их таймаутами бесполезно. Выход - поставить НЕ ВСТРОЕННУЮ сетевуху желательно 1Gb/s 3com или Intel, обязательно с разгрузкой контрольных сумм, поддержкой POLLING, со встроенными в её ЦП аппаратными буфферами. В результате снизишь нагрузку на ЦП, IO на шине.

Во вторых, контролировать количество открытых файловых дескрипторов, иначе софт будет простаивать, ожидая освобождения ФД. Подробнее man ulimit.
В третьих, если канал в какой-то точке от тебя наружу <100Mb/s и загружен до предела, увеличивать буфферы нет смысла. В Generic конфиге линух рассчитан на среднюю нагрузку по 1Гб/с каналу.
В четвертых - немного уменьшить таймауты TCP.
В пятых - увеличить кол-во портов, доступных для userspace приложений.
В шестых - увеличить кол-во сокетов для обслуживания tcp соединений.

В итоге мой sysctl.conf выглядит так:

Код: Выделить всё

fs.file-max=8192
net.ipv4.conf.all.send_redirects=0
net.ipv4.conf.all.accept_redirects=0
net.ipv4.conf.all.secure_redirects=0
net.core.rmem_default=201250
net.core.wmem_default=201250
net.core.rmem_max=256000
net.core.wmem_max=256000
net.ipv4.tcp_fin_timeout=15
net.core.netdev_max_backlog=3000
net.core.somaxconn=3000
net.ipv4.tcp_keepalive_intvl=5
net.ipv4.tcp_keepalive_probes=3
net.ipv4.ip_local_port_range=1024 65000
net.ipv4.tcp_syncookies=1
net.ipv4.tcp_mtu_probing=1

настройка производилась по RHEL Performance Guide и Tuning Suse Enterprise Server 10 guide для Debian 4.0 etch.

И еще совет, неважно, Linux это или фря, поставить мониторинг этих значений например в MRTG. таким способом будет видно реальное соотношение параметрв, их значения в момент времени.

например как в этом примере mrtg.cfg (взято из боевого сервера)

Код: Выделить всё

Target[tcp-est]: `/etc/scripts/est_state.sh`
Title[tcp-est]: Num of connections in ESTABLISHED/SYN_SENT state
PageTop[tcp-est]: <H1>Firebox Num of connections in ESTABLISHED/SYN_SENT state</H1>
Options[tcp-est]: gauge, nopercent, perminute, pngdate
MaxBytes[tcp-est]: 10000
ShortLegend[tcp-est]: Number
YLegend[tcp-est]: Connections
LegendI[tcp-est]: TCP Connections in ESTABLISHED State
LegendO[tcp-est]: TCP Connections in SYN_SENT State
Legend1[tcp-est]: TCP Connections in ESTABLISHED State
Legend2[tcp-est]: TCP Connections in SYN_SENT State

Target[tcp-close]: `/etc/scripts/wait_state.sh`
Title[tcp-close]: Num of connections in TIME_WAIT/CLOSE_WAIT state
PageTop[tcp-close]: <H1>Firebox Num of connections in TIME_WAIT/CLOSE_WAIT state</H1>
Options[tcp-close]: gauge, nopercent, perminute, pngdate
MaxBytes[tcp-close]: 10000
ShortLegend[tcp-close]: Number
YLegend[tcp-close]: Connections
LegendI[tcp-close]: TCP Connections in TIME_WAIT State
LegendO[tcp-close]: TCP Connections in CLOSE_WAIT State
Legend1[tcp-close]: TCP Connections in TIME_WAIT State
Legend2[tcp-close]: TCP Connections in CLOSE_WAIT State

вот так выглядит /etc/scripts/est_state.sh

Код: Выделить всё

#!/bin/sh
echo `netstat -st | grep "connections established" | awk '{print $1}'`
echo `netstat -an | grep "SYN_SENT" | wc -l`

exit 0

вот так /etc/scripts/wait_state.sh

Код: Выделить всё

#!/bin/sh
echo `netstat -an | grep "TIME_WAIT" | wc -l`
echo `netstat -an | grep "CLOSE_WAIT" | wc -l`

exit 0

можно конечно применить RRDTOOL, но имхо, для этого случая мне хватило и MRTG, чтобы найти виновника.

[zingel]

Код: Выделить всё

CLOSE_WAIT

во фре другой, это - важно.

[koffu]

это рабочий пример для Linux. Для FreeBSD как-то небыло надобности.

[zingel]

тогда не пишите, что для фри это тоже подходит, это не подходит для фряхи (зайдёт нуб, посмотрит и нажмёт).

[koffu]

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

[zingel]

ошибочное мнение, очень часто, если не в 80 процентах случаев серверами рулят махровые ламоботы.