Натоварен ли е сървера ???

[MiPSus]

Ами това е по дефолт от кърнъла: 5 дена никога не съм го променял и не съм срещал на някого да му пречи, ма щом Бонев е "открил" че трябва да се намали на 5 минути ...

[NetworkPro]

За сравнение MikroTik са решили да дадат на клиентите си тези параметри по дефолт:

/ip firewall connection tracking> export verbose

# dec/27/2012 12:51:13 by RouterOS 6.0rc6

#

/ip firewall connection tracking

set enabled=auto generic-timeout=10m icmp-timeout=10s tcp-close-timeout=10s

tcp-close-wait-timeout=10s tcp-established-timeout=1d

tcp-fin-wait-timeout=10s tcp-last-ack-timeout=10s

tcp-syn-received-timeout=5s tcp-syn-sent-timeout=5s

tcp-time-wait-timeout=10s udp-stream-timeout=3m udp-timeout=10s

Не съм чувал такъв проблем - стойност от 5 минути какво би потрошила, така че съм съгласен. Пък ако нещо не работи - съпортвам светкавично (комерсиално).

Редактирано 27 Декември, 2012 от NetworkPro

[Semoff]

Ето моите стойнсти на едната PPPoE машина, но имай предвид че не ползвам NAT.

Възможно е да трябва да увеличиш conntrack_max (то имаше формула по кято се смяташе спрямо рам-а, ама не помня вече)

Въпроса е, че това няма да ти намали "натовареността" на машината кой знае колко.

Най-вероятно имаш нещо объркано в tc или iptables скриптовете.

Моето предположение е, че проблемното ти звено е логиката на разделението на български и международен трафик.

net.netfilter.nf_conntrack_max=262144

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_sent2=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_syn_recv=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_established=600

net.ipv4.netfilter.ip_conntrack_tcp_timeout_fin_wait=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close_wait=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_last_ack=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_time_wait=10

net.ipv4.netfilter.ip_conntrack_tcp_timeout_close=10

net.ipv4.netfilter.ip_conntrack_udp_timeout=10

net.ipv4.netfilter.ip_conntrack_udp_timeout_stream=180

net.ipv4.netfilter.ip_conntrack_icmp_timeout=10

[gbdesign]

то имаше формула по кято се смяташе спрямо рам-а, ама не помня вече

Формулите Тук.

Иначе и аз мисля че е безсмислено да се пазят данни за конекции за повече от 5 мин. 5 дни е ужасно висока стойност, пълнеща РАМ-а с ненужни данни. Аз примерно намалявам силно времената за half-open конекции, но това е по-важно за сървъри предоставящи услуги, от колкото за рутери.

[NetworkPro]

само да дам малко контекст: conntrack е firewall+NAT функция, рутерите само мятат пакетите по адресите им и във IPv6 утопията (брак. на NAT технологията) няма нужда от conntrack на ISP рутер.

Редактирано 27 Декември, 2012 от NetworkPro

[kokaracha]

Тази зайгравка със sysctls е загуба на време само,някой ако вярва че само със буфериране ще реши проблем е много далеч от истината.

Колегата с проблема,за 30 мин можеш да си локализираш проблема сам,не е сложно изобщо даже е елементарно.

Трявбва от самия твой рутер да пингваш/фпингваш по веригата рутерите преди теб по трасето и така до крайна точка в нет-а,ако там имаш загуби проблема е ясен или акото там нямаш загуби минаваш назад от твоята мрежа.Почваш да пингваш/фпингваш от машина закачена на въпросния суйч по същия ред напред като gateway ти е въпросния твой рутер,ако и от тук нямаш проблем,минаваш още по назад от мрежата и така до крайна точка в мрежата ви.

Пък аз да ви кажа не виждам лаг или проблем от прикачените графики