Титла: Сърверът забива
Публикувано от: VladSun в Oct 03, 2005, 16:35
Здравейте!
Описание на SW&HW (всичко за което се сещам):
машина: Celeron 1.4GHz, RAM 384MB.
Slackware 9
Linux 2.6.10
iptables v1.3.2
рутиране на една публична /24 мрежа,
SNAT на една частна /24 мрежа,
htb shaper
mysql Ver 11.18 Distrib 3.23.56, for slackware-linux (i386),
Apache/1.3.27 (Unix)
BIND 9.2.2
Проблемът:
от известно време машината забива тотално и само хардуерен рестарт я оправя. Има пуснат софтуерен watchdog, който проверява за връзка през двете мрежови карти и при необходимост рестартира софтуерно, но той изобщо не сработва, т.е. машината забива зверски. Тъй като не успях да остраня проблема сложих и един хардуерен watchdog и сега се мъча да локализирам проблема според ситуацията преди забиването.
Последно почнах да следя ip_conntrack_count и ми се струва, че проблемът е свързан с conntrack.
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568
Според графиката на /proc/sys/net/ipv4/netfilter/ip_conntrack_count забиването на машината е винаги, когато броят на връзките достигне стойност около 11400-11700.
Това, което също ме безпокои е, че графиката расте монотонно (с леки пикчета), и е права линия когато няма трафик. Все си мисля, че броят на следените връзки би трябвало да е горе-долу в синхрон с трафика през машината.
Някакви предложения?
ПП: И при предишната версия на ядрото - 2.4.ХХ проблемът съществуваше.
Описание на SW&HW (всичко за което се сещам):
машина: Celeron 1.4GHz, RAM 384MB.
Slackware 9
Linux 2.6.10
iptables v1.3.2
рутиране на една публична /24 мрежа,
SNAT на една частна /24 мрежа,
htb shaper
mysql Ver 11.18 Distrib 3.23.56, for slackware-linux (i386),
Apache/1.3.27 (Unix)
BIND 9.2.2
Проблемът:
от известно време машината забива тотално и само хардуерен рестарт я оправя. Има пуснат софтуерен watchdog, който проверява за връзка през двете мрежови карти и при необходимост рестартира софтуерно, но той изобщо не сработва, т.е. машината забива зверски. Тъй като не успях да остраня проблема сложих и един хардуерен watchdog и сега се мъча да локализирам проблема според ситуацията преди забиването.
Последно почнах да следя ip_conntrack_count и ми се струва, че проблемът е свързан с conntrack.
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568
Според графиката на /proc/sys/net/ipv4/netfilter/ip_conntrack_count забиването на машината е винаги, когато броят на връзките достигне стойност около 11400-11700.
Това, което също ме безпокои е, че графиката расте монотонно (с леки пикчета), и е права линия когато няма трафик. Все си мисля, че броят на следените връзки би трябвало да е горе-долу в синхрон с трафика през машината.
Някакви предложения?
ПП: И при предишната версия на ядрото - 2.4.ХХ проблемът съществуваше.
Титла: Сърверът забива
Публикувано от: ray в Oct 03, 2005, 20:19
Здравей,
За съжаление нищо конкретно, но ми стана интересно и пробвах на моя компютър - броят на връзките расте, после намалява после пак расте (както и трябва).
Иначе като идеи: 1)може да липсва някаква настройка на "iptables"-a, но коя точно. И защо не се освобождават старите връзки, а новите само се трупат докато се препълни буфера?
2)Някой съзнателно да атакува като поддържа всички стари връзки и генерира нови докато се препълни буфера.
PS: мога да изпратя моя kernel-конфиг. (1-1 от shorewall docs)
Успех. Румен
За съжаление нищо конкретно, но ми стана интересно и пробвах на моя компютър - броят на връзките расте, после намалява после пак расте (както и трябва).
Иначе като идеи: 1)може да липсва някаква настройка на "iptables"-a, но коя точно. И защо не се освобождават старите връзки, а новите само се трупат докато се препълни буфера?
2)Някой съзнателно да атакува като поддържа всички стари връзки и генерира нови докато се препълни буфера.
PS: мога да изпратя моя kernel-конфиг. (1-1 от shorewall docs)
Успех. Румен
Титла: Сърверът забива
Публикувано от: zarhi в Oct 03, 2005, 20:47
conntrack модула иска по 386 байта за всяка конекция. Това трябва да е физическа рам, достъпна и свободна в момент на нужда. В случай че няма свободна памет се налага нещо да иде във swap-а и междувременно се натрупват пакети. Възможно е да има бъг в драйвера на мрежовата карта, който води до забиване, конфликт в irq-та на дисковия контролер и лан картата или между самите лан карти....
Титла: Сърверът забива
Публикувано от: VladSun в Oct 03, 2005, 21:01
Благодаря за отговорите!
Давам още информация:
cat /proc/interrupts
CPU0
0: 29525058 XT-PIC timer
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
9: 0 XT-PIC acpi
11: 50452642 XT-PIC eth0
12: 44959263 XT-PIC eth1
14: 81985 XT-PIC ide0
NMI: 0
ERR: 0
cat /var/log/debug | grep eth
kernel: eth0: Identified 8139 chip type 'RTL-8100'
kernel: eth1: Identified 8139 chip type 'RTL-8100'
syslog
kernel: ip_conntrack: table full, dropping packet.
Последното би трябвало да означава, че сървера не забива заради това ... след като е логнато. Защото преди забиване и syslog-a умира
Давам още информация:
cat /proc/interrupts
CPU0
0: 29525058 XT-PIC timer
2: 0 XT-PIC cascade
7: 0 XT-PIC parport0
9: 0 XT-PIC acpi
11: 50452642 XT-PIC eth0
12: 44959263 XT-PIC eth1
14: 81985 XT-PIC ide0
NMI: 0
ERR: 0
cat /var/log/debug | grep eth
kernel: eth0: Identified 8139 chip type 'RTL-8100'
kernel: eth1: Identified 8139 chip type 'RTL-8100'
syslog
kernel: ip_conntrack: table full, dropping packet.
Последното би трябвало да означава, че сървера не забива заради това ... след като е логнато. Защото преди забиване и syslog-a умира
Титла: Сърверът забива
Публикувано от: zarhi в Oct 03, 2005, 21:12
А резултата от 'cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max' ?
Титла: Сърверът забива
Публикувано от: VladSun в Oct 03, 2005, 21:40
както по-горе съм писал 
:
cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568
Току що инсталирах iptstate и е пълно с конекции от вида:
State TTL
ESTABLISHED 115:57:17
ESTABLISHED 119
0:23
ESTABLISHED 115:16:29
ESTABLISHED 115:21:43
ESTABLISHED 113:116
ESTABLISHED 117:11:57
ESTABLISHED 115:46:56
ip_conntrack_count непрекъснато расте с постоянна малка девиация от около 100-200 конекции (т.е. има освобождаване на конекции, но на прекалено малко).
cat ip_conntrack_tcp_timeout_established
432000
Това не е ли прекалено много?
Да не би проблемът да идва от IRC, FTP и TFTP conntrack-инга (компилирани са в ядрото)?
:cat /proc/sys/net/ipv4/netfilter/ip_conntrack_max
24568
Току що инсталирах iptstate и е пълно с конекции от вида:
State TTL
ESTABLISHED 115:57:17
ESTABLISHED 119
0:23ESTABLISHED 115:16:29
ESTABLISHED 115:21:43
ESTABLISHED 113:11
6ESTABLISHED 117:11:57
ESTABLISHED 115:46:56
ip_conntrack_count непрекъснато расте с постоянна малка девиация от около 100-200 конекции (т.е. има освобождаване на конекции, но на прекалено малко).
cat ip_conntrack_tcp_timeout_established
432000
Това не е ли прекалено много?
Да не би проблемът да идва от IRC, FTP и TFTP conntrack-инга (компилирани са в ядрото)?
Титла: Сърверът забива
Публикувано от: ray в Oct 03, 2005, 21:55
Здравей,
От това (твоят цитат по долу) би следвало да е ясно, че таблицата с "ip_conntrack" е пълна и новите заявки се "drop"-ват (едва ли и syslog-a умира, само докладва):
...
syslog
kernel: ip_conntrack: table full, dropping packet.
...
Прави ми впечатление, че използваш евтини карти (8139) сигурно знаеш че те работят главно на база софтуерен драйвер и може да има проблеми с тях.
Опитай с някоя INTEL-ска или 3COM-ска (ако имаш подръка).
Без претенции за пълнота, но от време на време тук-там се появяват оплаквания от 8139. Имах такава и си работеше, но я смених с INTEL-ска, не че е имало проблеми, просто за по-добра надеждност и производителност.
Успех. Румен
От това (твоят цитат по долу) би следвало да е ясно, че таблицата с "ip_conntrack" е пълна и новите заявки се "drop"-ват (едва ли и syslog-a умира, само докладва):
...
syslog
kernel: ip_conntrack: table full, dropping packet.
...
Прави ми впечатление, че използваш евтини карти (8139) сигурно знаеш че те работят главно на база софтуерен драйвер и може да има проблеми с тях.
Опитай с някоя INTEL-ска или 3COM-ска (ако имаш подръка).
Без претенции за пълнота, но от време на време тук-там се появяват оплаквания от 8139. Имах такава и си работеше, но я смених с INTEL-ска, не че е имало проблеми, просто за по-добра надеждност и производителност.
Успех. Румен
Титла: Сърверът забива
Публикувано от: zarhi в Oct 03, 2005, 22:01
Не, това е стойността по подразбиране. Имам машини с кернел 2.4.21, ip_conntrack_max = 512000 които са работили с месеци без проблем, със заредени всички възможни допълнителни модули. След 24 часа работа 'rmmod ip_conntrack' отнемаше по 20 минути и освобождаваше над 400Мбайта рам, но никога не е забивала.
Забиване без kernel panic принципно е означава сериозен хардуерен проблем ( температура? спрял вентилатор? ) или бъг в модул, който работи с irq/dma и успява така да препрограмира чипсета че да го забие.
Забиване без kernel panic принципно е означава сериозен хардуерен проблем ( температура? спрял вентилатор? ) или бъг в модул, който работи с irq/dma и успява така да препрограмира чипсета че да го забие.
Титла: Сърверът забива
Публикувано от: zarhi в Oct 03, 2005, 22:07
Между другото доколкото си спомням RTL-8100 е чипсет за вграждане на дъна. И наличието на 2 такива лан карти е най-малкото странно. Някак си не си спомням да съм виждал дъно с 2 вградени realtek лан карти.
RTL-8139 принципно работят доста стабилно, но са така направени, че за всеки приет/предаден пакет генерират прекъсване. И съответно с 2 ( или повече ) такива карти при трафик над 70-80 Мбит натоварването на машината става доста сериозно. Тия лан карти са bus master и могат да задържат pci шината, което при някой дъна води до недостатъчно време за опресняване на памета. Но тогава винаги следва kernel panic.
Изобщо провери първо за хардуерни проблеми ( memtest86 ). Не е нормално един и същи ефект при кернел 2.4 и 2.6. Общото май остава само хардуера.
RTL-8139 принципно работят доста стабилно, но са така направени, че за всеки приет/предаден пакет генерират прекъсване. И съответно с 2 ( или повече ) такива карти при трафик над 70-80 Мбит натоварването на машината става доста сериозно. Тия лан карти са bus master и могат да задържат pci шината, което при някой дъна води до недостатъчно време за опресняване на памета. Но тогава винаги следва kernel panic.
Изобщо провери първо за хардуерни проблеми ( memtest86 ). Не е нормално един и същи ефект при кернел 2.4 и 2.6. Общото май остава само хардуера.
Титла: Сърверът забива
Публикувано от: VladSun в Oct 04, 2005, 00:02
Пак, много благодаря за бързите отговори!
Но, все пак, продължава да ме мъчи проблема с неосвобождаването на следените конекции... това не ми прилича на хардуерен проблем
В момента подкарвам lm-sensors, пък после да видим графиката какво ще покаже ...
ПП: Трафика през сървера никога не е над 30Мбит със сигурност.
Но, все пак, продължава да ме мъчи проблема с неосвобождаването на следените конекции... това не ми прилича на хардуерен проблем
В момента подкарвам lm-sensors, пък после да видим графиката какво ще покаже ...
ПП: Трафика през сървера никога не е над 30Мбит със сигурност.
Титла: Сърверът забива
Публикувано от: mhydra в Oct 04, 2005, 08:21
Защо не попиташ за всеки случай и в форума на linuxpackages.net.
Там може и да знаят, най малкото предполагам че Jim ще се заинтересова.
Там може и да знаят, най малкото предполагам че Jim ще се заинтересова.
Титла: Сърверът забива
Публикувано от: zarhi в Oct 04, 2005, 08:27
| Цитат |
| рутиране на една публична /24 мрежа, SNAT на една частна /24 мрежа, htb shaper |
2С мрежи, 506 ефективни ип-та, 24568 тракнати конекций. Това е по 48 конекций на ип. Няма нищо ненормално. Между другото една подробност която често се пропуска: зареди ли се conntrack модула веднага се тракват ВСИЧКИ конекций. И реални и нат-нати ип-та + трафика генериран от самия сървър. Това няма как да се промени, така работи модула. Даже и машината да е само рутер за реални ип-та, заредиш ли conntrack или nat модул ( който иска conntrack ) задължително се траква всичко, без значение дали ще ти потрябва или не.
Титла: Сърверът забива
Публикувано от: в Oct 04, 2005, 10:11
Ами и аз да се оплача. Значи имам Slack с ядро 2.4.20 и pptp,pppd,htb,16MB RAM, 2x3c503 LAN,P60. С NAT,CONNTRACK,firewall и всички необходими неща за натване на VPN и LAN мрежа. Това нещо забиваше с Aieee, killing interupt handler. И invalid opcode ... в незнам коя програма. Помислих че е от суапа, но не след като го изключих пак си забива. След това смених машината и отново същият резултат. Най-вероятно е несъвместимост на компонентите от горният софтуер. Така си забива регулярно и до сега. Някои ако се сети нещо да подскаже.
Титла: Сърверът забива
Публикувано от: zarhi в Oct 04, 2005, 12:57
РАМ-а е прекалено малко.
Титла: Сърверът забива
Публикувано от: в Oct 04, 2005, 13:28
Сега машината е със същия линукс, но P200 с 24MB RAM.
Резултат същият.
Резултат същият.
Титла: Сърверът забива
Публикувано от: toxigen в Oct 04, 2005, 16:12
24MB не е много повече от 16...
Особено ако използваш същите 16МБ от старата машина - виж си паметта. 3c503 не е ли ISA карта? Ако да , настроени ли са както трябва IRQ, IO Address etc. ?
Особено ако използваш същите 16МБ от старата машина - виж си паметта. 3c503 не е ли ISA карта? Ако да , настроени ли са както трябва IRQ, IO Address etc. ?
Титла: Сърверът забива
Публикувано от: в Oct 04, 2005, 17:03
Ами лично не мога да си обесня забиването заради хардуер.
Както казах всичко е друго.HDD, RAM и да 3с503 е ISA,но след това ги замених c 2хPCI. А 24МВ за рутер мисля че не са малко, имайки в предвид че се използват едва на 50%.
Най-вероятно е някоя джаджа в ядрото, или несъвместимост между модулите на pppd, htb или нещо друго.
Както казах всичко е друго.HDD, RAM и да 3с503 е ISA,но след това ги замених c 2хPCI. А 24МВ за рутер мисля че не са малко, имайки в предвид че се използват едва на 50%.
Най-вероятно е някоя джаджа в ядрото, или несъвместимост между модулите на pppd, htb или нещо друго.
Титла: Сърверът забива
Публикувано от: kmakaron в Oct 05, 2005, 01:09
total used free shared buffers cached
Mem: 22324 21680 644 0 2696 10672
-/+ buffers/cache: 8312 14012
Swap: 0 0 0
02:19:33 up 3 days, 6:40, 1 user, load average: 0.11, 0.07, 0.01
Module Size Used by Not tainted
ppp_deflate 3128 2 (autoclean)
zlib_inflate 18564 0 (autoclean) [ppp_deflate]
zlib_deflate 18776 0 (autoclean) [ppp_deflate]
bsd_comp 4248 0 (autoclean)
ppp_async 6400 1 (autoclean)
tun 3392 3
ppp_generic 15108 3 (autoclean) [ppp_deflate bsd_comp ppp_async]
slhc 4672 1 (autoclean) [ppp_generic]
ipt_TCPMSS 2296 2 (autoclean)
8139too 12744 1
mii 2208 0 [8139too]
3c503 6144 1
8390 5744 0 [3c503]
Mem: 22324 21680 644 0 2696 10672
-/+ buffers/cache: 8312 14012
Swap: 0 0 0
02:19:33 up 3 days, 6:40, 1 user, load average: 0.11, 0.07, 0.01
Module Size Used by Not tainted
ppp_deflate 3128 2 (autoclean)
zlib_inflate 18564 0 (autoclean) [ppp_deflate]
zlib_deflate 18776 0 (autoclean) [ppp_deflate]
bsd_comp 4248 0 (autoclean)
ppp_async 6400 1 (autoclean)
tun 3392 3
ppp_generic 15108 3 (autoclean) [ppp_deflate bsd_comp ppp_async]
slhc 4672 1 (autoclean) [ppp_generic]
ipt_TCPMSS 2296 2 (autoclean)
8139too 12744 1
mii 2208 0 [8139too]
3c503 6144 1
8390 5744 0 [3c503]
Титла: Сърверът забива
Публикувано от: toxigen в Oct 06, 2005, 10:28
За мен е ядрото. Ъпдейтвай!
Титла: Сърверът забива
Публикувано от: VladSun в Oct 12, 2005, 18:20
Така-а-а....
Значи смених вентилатора на CPU, но проблемът пак се появи.
Интересното е, че преди това бях пуснал следене на броя на IRQ-тата от двете лан карти от /proc/interrupts и получената графика е доста странна, макар и показателна - средната стойност се движи около 1400-1500, но точно когато сървера забива има пик от 30000 и държи така до рестарт (или поне според MRTG-то).
Някой да знае нещо по въпроса?
Утре сменям ЛАН картите, дано се оправи.
Значи смених вентилатора на CPU, но проблемът пак се появи.
Интересното е, че преди това бях пуснал следене на броя на IRQ-тата от двете лан карти от /proc/interrupts и получената графика е доста странна, макар и показателна - средната стойност се движи около 1400-1500, но точно когато сървера забива има пик от 30000 и държи така до рестарт (или поне според MRTG-то).
Някой да знае нещо по въпроса?
Утре сменям ЛАН картите, дано се оправи.
Титла: Сърверът забива
Публикувано от: zarhi в Oct 12, 2005, 20:33
Позната работа. Получава се от windows машина заразена с sasser, blaster, mssql worm или някаква подобна гадост. Ефекта е огромно количесто пакети в секунда, насочени към порт 445 и към всевъзможни ( случайно генерирани ) ип-та.
Въпреки всичко може и да е хардуерен проблем - irq конфликт. За проба направи следното 'iptables -I FORWARD 1 -p tcp --dport 445 -j DROP'. При това положение би трябвало да има скок в прекъсванията/сек само на едната лан карта. Ако пак го има и на двете, пусни си една графика за пакети/сек на двете лан карти отделно. Има ли връзка между броя прекъсвания/сек и броя пакети/сек значи те флудят жестотко. Ако обяче няма видима връзка, пак се върни на идеята да е хардуерен проблем ( изсъхнали кондензатори по дънната платка или захранването ).
Въпреки всичко може и да е хардуерен проблем - irq конфликт. За проба направи следното 'iptables -I FORWARD 1 -p tcp --dport 445 -j DROP'. При това положение би трябвало да има скок в прекъсванията/сек само на едната лан карта. Ако пак го има и на двете, пусни си една графика за пакети/сек на двете лан карти отделно. Има ли връзка между броя прекъсвания/сек и броя пакети/сек значи те флудят жестотко. Ако обяче няма видима връзка, пак се върни на идеята да е хардуерен проблем ( изсъхнали кондензатори по дънната платка или захранването ).
Титла: Сърверът забива
Публикувано от: VladSun в Oct 13, 2005, 00:02
Благодаря за отговора Zarhi.
Само, че бих заложил, че е хардуерен проблем ... И преди са ме флудили и ефекта определено не беше такъв. А защитната стена дропи всякакви Netbios пакети (http://www.linux-bg.org/cgi-bin....а+стена) и въпреки това броят на IRQ-тата на двете карти е еднакъв.
Мисля да сложа две Intel-ски карти и дано приключа с този тред във форума
Само, че бих заложил, че е хардуерен проблем ... И преди са ме флудили и ефекта определено не беше такъв. А защитната стена дропи всякакви Netbios пакети (http://www.linux-bg.org/cgi-bin....а+стена) и въпреки това броят на IRQ-тата на двете карти е еднакъв.
Мисля да сложа две Intel-ски карти и дано приключа с този тред във форума
Титла: Сърверът забива
Публикувано от: n_antonov в Oct 13, 2005, 00:15
Преди всичко, постарай се да си настроиш нещата съобразно трафика и наличната памет. Там е ключът от палатката. Този материал може да ти е от полза. В него се обясняват принципите и разликите между ядра 2.4 и 2.6.
Титла: Сърверът забива
Публикувано от: VladSun в Oct 13, 2005, 00:40
Чел съм я тази статия, но ...
Това е първото, което ме безпокои - все пак размера на заетата от userspace програмите се мени динамично ...
Второ, след като съм получавал съобщение в логовете за препълване на таблиците на conn_track (и сървера е оставал ОК), значи проблема не е там.
Трето, по тази логика не бих могъл да си обясня огромния брой на прекъсвания генерирани от ЛАН картите в моментите на забиване.
Благодаря за линк все пак
ПП: Значи освен Интелски ЛАН карти ще си купя и още памет
| Цитат |
| Ideal case: firewalling-only machine ------------------------------------ In the ideal case, you have a machine _just_ doing packet filtering and NAT (i.e. almost no userspace running, at least none that would have a growing memory consumption like proxies, ...). |
Това е първото, което ме безпокои - все пак размера на заетата от userspace програмите се мени динамично ...
Второ, след като съм получавал съобщение в логовете за препълване на таблиците на conn_track (и сървера е оставал ОК), значи проблема не е там.
Трето, по тази логика не бих могъл да си обясня огромния брой на прекъсвания генерирани от ЛАН картите в моментите на забиване.
Благодаря за линк все пак
ПП: Значи освен Интелски ЛАН карти ще си купя и още памет
Титла: Сърверът забива
Публикувано от: VladSun в Oct 13, 2005, 00:47
Сега се сетих.
На другия сървер:
P4, 2.4GHz
512MB RAM
int eth Repotec 8139
ext eth Compaq TLAN
SW същия като описания в първия пост.
Трафик - 5 пъти по-голям от този на първия сървер.
Значи, графиката на IRQ-тата е съвсем различна - на TLАN картата седи на 4000 и не мръдва по-нагоре, надолу - само когато IRQ-тата на Repotec-а паднат драстично. От своя страна IRQ-тата на Repotec-a стигат до 17000.
Но сървера не забива ...
На другия сървер:
P4, 2.4GHz
512MB RAM
int eth Repotec 8139
ext eth Compaq TLAN
SW същия като описания в първия пост.
Трафик - 5 пъти по-голям от този на първия сървер.
Значи, графиката на IRQ-тата е съвсем различна - на TLАN картата седи на 4000 и не мръдва по-нагоре, надолу - само когато IRQ-тата на Repotec-а паднат драстично. От своя страна IRQ-тата на Repotec-a стигат до 17000.
Но сървера не забива ...
Титла: Сърверът забива
Публикувано от: VladSun в Oct 13, 2005, 03:21
Загледах се в графиките на МРТГ-то:
то не било пик от 30'000, ами 30'000'000 .....
малка грешка
то не било пик от 30'000, ами 30'000'000 .....
малка грешка
Титла: Сърверът забива
Публикувано от: n_antonov в Oct 13, 2005, 12:54
При всички положения, независимо от софтуерните настройки, използвай мрежови карти на Intel.
Относно статията, имам машина на гигабитова оптика, през която непрекъснато се движат средно около 200 мегабита. На нея работи и DNS (доста натоварен, обслужва рекурсивно стотици клиенти и отговаря за стотина зони), който използва за съхранение на данните PGSQL. Машината е с 1G RAM и следните настройки на ip_conntrack.
От /etc/sysctl.conf
net/ipv4/ip_conntrack_max=2097152
От /etc/modules
ip_conntrack hashsize=2097152
Практически заделил съм половината памет за ip_conntrack. Никакви проблеми с препълването му нямам, нито пък с недостиг на памет. Просто забравям за тази машина. Веднъж на 24 часа се изпълнява командата:
sysctl -p
Ядрото е 2.6.13. Само при 2.6 можеш да променяш с параметри на insmod стойността на hashsize. При 2.4 е нужно да променяш сорса и да прекомпилираш.
Забравих. Същата машина е пълноценен border gateway с quagga и над 170 000 маршрута в рутинг таблицата си.
load average: 0.17, 0.34, 0.39
Относно статията, имам машина на гигабитова оптика, през която непрекъснато се движат средно около 200 мегабита. На нея работи и DNS (доста натоварен, обслужва рекурсивно стотици клиенти и отговаря за стотина зони), който използва за съхранение на данните PGSQL. Машината е с 1G RAM и следните настройки на ip_conntrack.
От /etc/sysctl.conf
net/ipv4/ip_conntrack_max=2097152
От /etc/modules
ip_conntrack hashsize=2097152
Практически заделил съм половината памет за ip_conntrack. Никакви проблеми с препълването му нямам, нито пък с недостиг на памет. Просто забравям за тази машина. Веднъж на 24 часа се изпълнява командата:
sysctl -p
Ядрото е 2.6.13. Само при 2.6 можеш да променяш с параметри на insmod стойността на hashsize. При 2.4 е нужно да променяш сорса и да прекомпилираш.
Забравих. Същата машина е пълноценен border gateway с quagga и над 170 000 маршрута в рутинг таблицата си.
load average: 0.17, 0.34, 0.39
Титла: Сърверът забива
Публикувано от: в Oct 13, 2005, 16:27
offtopic за което се извинявам , но все пак съм доста очуден:
т.е като дадеш route / route -n ти излизат 170 000 записа :???
с колко мрежови у-ва/карти/интерфейса* е тази машина ?
т.е като дадеш route / route -n ти излизат 170 000 записа :???
с колко мрежови у-ва/карти/интерфейса* е тази машина ?
Титла: Сърверът забива
Публикувано от: в Oct 13, 2005, 18:35
| Цитат (Guest @ Окт. 13 2005,17:27) |
| offtopic за което се извинявам , но все пак съм доста очуден: т.е като дадеш route / route -n ти излизат 170 000 записа :??? с колко мрежови у-ва/карти/интерфейса* е тази машина ? |
става въпрос за броят на прекъсванията генерирани от ЛАН картите, не номерата на прекъсванията
Титла: Сърверът забива
Публикувано от: zarhi в Oct 14, 2005, 08:11
| Цитат (Guest @ Окт. 13 2005,17:27) |
| offtopic за което се извинявам , но все пак съм доста очуден: т.е като дадеш route / route -n ти излизат 170 000 записа :??? |
[root@skk9 root]# route -n | wc -l
168509
[root@skk9 root]# uptime
08:09:46 up 270 days, 19:56, 1 user, load average: 0.33, 0.13, 0.03
Толкова ли е учудващо?
Титла: Сърверът забива
Публикувано от: n_antonov в Oct 14, 2005, 09:35
| Цитат (Guest @ Окт. 13 2005,19:27) |
| offtopic за което се извинявам , но все пак съм доста очуден: т.е като дадеш route / route -n ти излизат 170 000 записа :??? с колко мрежови у-ва/карти/интерфейса* е тази машина ? |
Точно така. Това border рутер и е нормално да има толкова записи. Мрежовите карти са само две, като едната е гигабитова и отива към оптика. Друг е въпросът, че върху нея са вдигнати 16 vlan-а.