Linux ping 10.0.0.x connect: No buffer space available, TCP:Possible SYN flooding on port

	B O A R D
	» Board » Zadaj pytanie » Archiwum » Szukaj » Stylizacja

M E N U

» Nowości

» Archiwum

» Recenzje / Testy

» Board

» Rejestracja

Szukaj @ TwojePC

	OBECNI NA TPC
	» NimnuL 06:15 » NWN 05:07 » Shark20 02:49 » MARC 02:08 Dzisiaj przeczytano 41106 postów, wczoraj 25974 Szybkie ładowanie jest: włączone.

ccc

A R C H I W A L N A W I A D O M O Ś Ć

Linux ping 10.0.0.x connect: No buffer space available, TCP:Possible SYN flooding on port , AwerS 20/10/11 14:28
Witam

Mam problem z serwerem wyglada tak ze ma za duzo zapytan i zaczol sie dlawic.

w dmesg'u pojawily sie wpisy:

TCP: Possible SYN flooding on port 8766. Dropping request.
ipv4: Neighbour table overflow.

Mial juz ktos stycznosc z podobnym problemem? Wylaczylem ciasteczka dla SYN

netstat -tan | grep ':8766 ' | awk '{print $6}' | sort | uniq -c
144 CLOSE_WAIT
16 ESTABLISHED
1 FIN_WAIT1
65 FIN_WAIT2
1 LISTEN
17073 TIME_WAIT

cat /proc/sys/net/core/somaxconn
128

free
total used free shared buffers cached
Mem: 4146032 4027316 118716 0 48720 3398656
-/+ buffers/cache: 579940 3566092
Swap: 1954316 10280 1944036

AwerS

dodalem do sysctl.conf , AwerS 20/10/11 14:39
net.ipv4.tcp_no_metrics_save = 1
net.ipv4.tcp_moderate_rcvbuf = 1
net.core.netdev_max_backlog = 2500
net.ipv4.core.rmem_default = 262144
net.ipv4.core.wmem_default = 262144
net.ipv4.tcp_rmem = 4096 87380 8388608
net.ipv4.tcp_wmem = 4096 87380 8388608
net.ipv4.tcp_mem = 8388608 8388608 8388608
net.ipv4.core.rmem_max = 8388608
net.ipv4.core.wmem_max = 8388608
net.ipv4.neigh.default.gc_thresh1=1024
net.ipv4.neigh.default.gc_thresh2=4096
net.ipv4.neigh.default.gc_thresh3=8192

oraz echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter i jak na razie pomoglo
AwerS
1. a co to za baza? , Master/Pentium 20/10/11 21:29
  dla Oracle trzeba dać cześć twoich wpisów ale cześć widzę po raz pierwszy w życiu.
  Nie ma tego złego , co by się w gorsze
  obrócić nie mogło - jak nie wierzysz
  włącz komputer :-)
hahaaha , Druzil 20/10/11 18:46
pomyliłes nas z forum komputerowym ;-)
1. przesadzasz , Master/Pentium 20/10/11 21:28
  ale faktycznie niewiele osób tutaj siedzi od baz danych.
  Nie ma tego złego , co by się w gorsze
  obrócić nie mogło - jak nie wierzysz
  włącz komputer :-)
2. hehe , MARtiuS 21/10/11 12:31
  dobre naprawdę dobre :D
  feci, quod potui, faciant meliora
  potentes
  GG 617689
3. Lubię to! , brygi 21/10/11 23:17
  123
Mozesz ustawic w klientach aby sie tak szybko nie rozlaczali. , ptoki 21/10/11 13:42
I reuzywali polaczenie.
Mozesz serwer bazodanowy ustawic tak aby nasluchiwal na kilku portach.
Warto tez ciutke skrocic czas time_wait.

Ale z tego co widze to problem moze nie byc spowodowany iloscia polaczen a tym ze klienci nie sa w stanie sie do ciebie dobic albo dostajesz zduplikowane pakiety.
tcpdump prawde powie...
1. Jest to aplikacja autorska, problemem jest ze klientow ostatnio drastycznie przybylo , AwerS 21/10/11 14:46
  i pojawily sie nowe trudnosci.
  AwerS
  1. Kodu pewnie nie ma? , ptoki 22/10/11 20:29
    Czy klienta daje sie zrekonfigurowac tak aby na innym porcie gadal?
    
    Zrob sobie zrzut tcpdump-em albo wiresharkiem (jest pod winde ale moze narzekac na sterownik sieciowy tzw promiscous mode - poczytaj o tym jesli to srodowisko jest mocno produkcyjne).
    Pogadaj z sieciowcami moze sie na chwile span port zestawia na bok.
    
    Przechwyc to co sie tam dzieje. Bedziesz wiedzial co jest problemem (czy ilosc polaczen czy jakis problem sieciowy)