hola mindenki,
már lassanként beleőszülök ebbe a problémába, a neten nem találok hozzá semmit, viszont elég durva hiba.
szóval: van öt szerverünk, ezek közül egy kapásból friss F15-öt kapott, egy F12-essel megy (és már nem is lesz jobb, nyugdíjazásra váró hardverről van szó), a maradék hármat múlt csütörtökön upgradeeltem F13-ról F15-re.
mióta megtörtént az upgrade, a három upgrade-elt szerver közül kettő a következő jelenséget mutatja NÉHÁNY gépen: weboldal betöltés (vagy IMAP kapcsolat létrehozása, néha SSH login) közben időnként, eléggé sokszor, timeoutba fut bele. ha megtörténik egy ilyen timeout, utána néhány (tíz) másodpercig a szerver arról a gépről elérhetetlen. a weblapoknál gyakori, hogy az első pár elemet (pl. alap htm, css) rendben leszedi, aztán a képek letöltése közben kiakad, és nem tölt tovább, ezután egy másik linkre kattintva a site-on már jön a timeout azonnal.
és itt jön a feketeleves: *bizonyos* klienseknél van ez így. eddig három kliensgépet találtam, különböző hálózatokon, ahol ez a jelenség előfordul. mindegyik windows xp, mindegyik router mögött. és hogy szórjunk még egy kis kávét is a feketelevesbe: UGYANAZON router mögött bizonyos gépeken nincs hiba. az egyik hálózaton egy wifin csatlakoztatott gép nem megy, és a kábeles igen, a másik hálózaton egy csatlakoztatott és egy wifis gép nem megy, egy wifis xp-s notebook és egy android telefon tökéletesen.
és amitől teljesen elszáll az agyam: a három gép közül az egyik tökéletesen megy, igaz, az egy xeon, és azon az upgrade processz f15-ös részének post-upgradejénél volt egy váratlan újraindulás, tehát valami nem futott le rendesen, és emiatt maradt működőképes.
10+ éve vagyok rendszergazda, de ilyen szinten érthetetlen problémával még nem találkoztam.
amire eddig jutottam:
- amikor a tcp alapú protokollok timeoutolnak a "rossz" klienseken, a ping változatlanul működik, tehát a dhcp megy... és mivel nem csak az apache érintett, hanem a dovecot, a vsftpd és néha az openssh is, ezért arra gyanakszom, hogy valami a tcp layeren szabódott el (de mi? az MTU maradt a régi, nem a NetworkManager kontrollálja az eth0 interface-t, stb...).
- ifconfiggal nézve nincs se RX, sem TX hiba az eth0-n.
- apache error logokban nézegetve nincs error.
- maillogban nézve a hibás gépekről néha olyat látok, hogy Disconnected (no auth attempts), más hibát nem ír.
- a timeout a szerver oldalon úgy látszik, hogy a kliens gépről megnyitott kapcsolatok TIME_WAIT állapotban állnak egy ideig, aztán elhalnak.
- az upgrade után egyik gépen sem futott a cron daemon, ez valami fedora upgrade hiba lehetett; azon a gépen, ami jól működik, még pénteken észrevettem a hibát, és beindítottam a cron daemont, a másik kettőn, ami még mindig hibás, csak tegnap este vettem észre és indítottam el a crond-t. ez viszont semmit nem javított a helyzeten.
- megnéztem, hogy az egyik hibát produkáló kliensgép (amihez elérésem volt) nem vírusos-e. F14 livecd-ről bebootolva, nod32 v4-et letöltve és lefuttatva a C:-re nem talált vírust. ettől még lehet vírus, de még nem találkoztam olyannal, ami átcsúszna mind a nod32-n, mind az aktívan működő SAV-on, és ilyen problémákat produkálna.
- mindhárom gépnél a sysctl.conf-on keresztül komolyan át van állítva sok kernel paraméter (a nagyobb network teljesítmény kedvéért + a tempfs maximális méretének növeléséért). ez az egyik szervernél (ahol a legnagyobb a forgalom) nem okoz gondot, a másik kettőnél igen. megpróbáltam a "gyári" sysctl.conf-ot alkalmazni az egyiken, semmi nem változott.
- próbáltam lekapcsolt és felkapcsolt tűzfallal is, ugyanaz a helyzet (gyanakodtam a conntrack-os stateful packet szűrésre, de akkor tűzfal nélkül működnie kellett volna rendesen... nem működött)
- próbáltam közös dolgokat találni a "rossz" és a helyesen működő gépek között, de semmi. ami még a leginkább valószínű volt, hogy háromból két gépen működik egy-egy logitech hd270-es webcam, de már hónapok óta, és csak a F15 upgrade óta van ez a probléma.
az eddigi kutatás alapján nagyon kevés kliens-gépet érint a probléma (a szerverek forgalma jobbára változatlan), de mivel spec nekem ezekre a szerverekre kéne fejlesztenem, és a fejlesztő desktop gépem az egyik érintett "rossz" gép, eléggé szar a helyzet, nem tudok dolgozni rendesen.
valaki valami ötlet? hasonló dolgokba belefutottatok már? vagy van valakinek ilyen tapasztalata F15 upgrade után?
- 1409 megtekintés
Hozzászólások
Nekem a "net.ipv4.tcp_tw_recycle=1" okozott nagyon hasonló problémát
egy gépen amin FC12 van. A weblap szövege megjelent, de képek már nem.
0 -ra állitva megszünt a hiba.
PO
- A hozzászóláshoz be kell jelentkezni
Próbáld nullázni átmenetileg:
net.ipv4.tcp_window_scaling
net.ipv4.tcp_ecn
> mindhárom gépnél a sysctl.conf-on keresztül komolyan át van állítva sok kernel paraméter (a nagyobb network teljesítmény kedvéért)
A tuningolt sysctl.conf visszaállítása biztos megvolt, rebootal?
- A hozzászóláshoz be kell jelentkezni
Ha a probléma kb. reprodukálható (adott gépen mindig, vagy sokszor van, vagy ha előfordul, akkor fennmarad egy ideig), akkor tcpdumpot neki egyszerre mindkét végén. Aztán lehet szépen nézegetni, hogy kinél akadnak el a csomagok.
Az általam látott ilyen típusú hibák 90%-ában valahol valaki eldobálta a csomagokat.
Egy LAN-on 1% packet vesztés is látványos eredményre vezet.
- A hozzászóláshoz be kell jelentkezni
+1 tcpdump, valamint
- a timeout a szerver oldalon úgy látszik, hogy a kliens gépről megnyitott kapcsolatok TIME_WAIT állapotban állnak egy ideig, aztán elhalnak
A TIME_WAIT már a legvége [SVG]. Ha a kapcsolat volt valaha is ESTABLISHED-ben, akkor a TIME_WAIT csak akkor lehetséges, ha valamelyik oldal aktívan (processzbül) kezdeményezi a lezárást.
(A diagramhoz: az első szó (a "/" előtt) a fogadott csomag (ha vékonyan van szedve) vagy a művelet (ha vastagon van szedve); a második szó pedig a (művelethez vagy a fogadottra válaszként) küldött csomag.)
A tcpdump mellett még javasolnék valamit: a kliens és a szerver közé iktass be egy harmadik gépet ideiglenesen. Erre tegyél fel egy TCP port forwarder-t (lehet akár "ssh -v -v -v -L" is a kliensről), és nézd meg, hogy így szakad-e, és ha igen, akkor melyik kettő között.
- A hozzászóláshoz be kell jelentkezni
egy kicsit pihenek (már túl sok ideje pörgök ezen), aztán kipróbálom a dolgokat, szépen sorban. most még épp a wireshark által rögzített folyamot elemzem, és ami egyből feltűnik, hogy kurva sok SYN kérést küld ki a gépem egymás után. (ezzel a szabállyal szűrök: ( ip.dst == 212.40.97.56 && tcp.dstport == 80 ) || ( ip.src == 212.40.97.56 && tcp.srcport == 80 ). az ip cím az egyik beteg gép címe. esetleg egy wireshark export valakinek mondana valami érdekeset, vagy ne csatoljam, mert minek? :)
- A hozzászóláshoz be kell jelentkezni
A
man 7 tcp
-ban ilyeneket látok, hogy tcp_syncookies, tcp_max_syn_backlog, tcp_synack_retries, tcp_abort_on_overflow, de szerintem ezeket a végére kellene hagyni. Nem lehet a klienst visszafogni, vagy pl. HTTP pipelining-ot bekapcsolni? Szerver oldalon nagyobb listen backlog, vagy több kiszolgáló processz vagy szál?
- A hozzászóláshoz be kell jelentkezni
hát, gyerekek, nem tudom, melyik sysctl.conf-os ötlet vált be ennyire (mind a három direktívát beleraktam), de egyelőre siker, és gyorsabb, mint valaha. :) köszönöm a segítséget, még várok pár napot, ha marad minden jól, akkor vendégeim vagytok egy sörre, de komolyan. :D
- A hozzászóláshoz be kell jelentkezni