Forum Linux.debian/ubuntu Probleme de connexion qui freeze en unstable

Posté par  .
Étiquettes :
0
24
nov.
2006
Bonjour,

J'ai un petit (gros) soucis avec un serveur dédié en unstable : les connexions, tout type de protocole confondus, gèlent. Par exemple, un ssh va freezer de manière aléatoire. J'ai testé sous divers OS (linux, osx, win2k) et depuis plusieurs ISP (nerim, neuf, mamadoo) : idem.
J'ai installé, entre autre, un petit serveur warsow (UDP), histoire de tester, et il en va de meme. Si non sommes 10 par exemple, d'un coups, trois vont etres déconnectés sans raison, et ne pourront se reconnecter que bien longtemps aprés (ce qui n'est pas du fait du jeu, mais bien un probleme de connexion).

Pour la petite histoire, voici les tests / modifications effectués :

- Carte réseau changée
- Divers noyaux testés, tous de debian : 2.6.8-i386, 2.6.18-2-K7, etc.
- RAM changée

Voici quelques infos sur la machine :

00:00.0 Host bridge: VIA Technologies, Inc. VT8375 [KM266/KL266] Host Bridge
00:01.0 PCI bridge: VIA Technologies, Inc. VT8633 [Apollo Pro266 AGP]
00:0a.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ (rev 10)
00:10.0 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.1 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.2 USB Controller: VIA Technologies, Inc. VT82xxxxx UHCI USB 1.1 Controller (rev 80)
00:10.3 USB Controller: VIA Technologies, Inc. USB 2.0 (rev 82)
00:11.0 ISA bridge: VIA Technologies, Inc. VT8235 ISA Bridge
00:11.1 IDE interface: VIA Technologies, Inc. VT82C586A/B/VT82C686/A/B/VT823x/A/C PIPC Bus Master IDE (rev 06)
01:00.0 VGA compatible controller: S3 Inc. VT8375 [ProSavage8 KM266/KL266]

noyau actuel : 2.6.18-2-k7 #1 SMP Wed Nov 8 20:38:36 UTC 2006 i686 GNU/Linux

cat /proc/cpuinfo
processor : 0
vendor_id : AuthenticAMD
cpu family : 6
model : 8
model name : AMD Athlon(tm) XP 2000+
stepping : 1
cpu MHz : 1662.627
cache size : 256 KB
fdiv_bug : no
hlt_bug : no
f00f_bug : no
coma_bug : no
fpu : yes
fpu_exception : yes
cpuid level : 1
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat pse36 mmx fxsr sse syscall mmxext 3dnowext 3dnow up ts
bogomips : 3328.88

free -m
total used free shared buffers cached
Mem: 1004 966 37 0 30 500
-/+ buffers/cache: 436 568
Swap: 2588 0 2588


eth0 Lien encap:Ethernet HWaddr 00:08:A1:5A:90:07
inet adr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Masque:255.255.255.0
adr inet6: xxx::xxxxx:xxxxx:xxxxxx/64 Scope:Lien
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:45090937 errors:9 dropped:14 overruns:9 frame:0
TX packets:19276808 errors:0 dropped:0 overruns:19 carrier:0
collisions:0 lg file transmission:1000
RX bytes:706663541 (673.9 MiB) TX bytes:289431040 (276.0 MiB)
Interruption:177 Adresse de base:0xec00

eth0:0 Lien encap:Ethernet HWaddr 00:08:A1:5A:90:07
inet adr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interruption:177 Adresse de base:0xec00

eth0:1 Lien encap:Ethernet HWaddr 00:08:A1:5A:90:07
inet adr:xxx.xxx.xxx.xxx Bcast:xxx.xxx.xxx.255 Masque:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
Interruption:177 Adresse de base:0xec00

lo Lien encap:Boucle locale
inet adr:127.0.0.1 Masque:255.0.0.0
adr inet6: ::1/128 Scope:Hôte
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:2382074 errors:0 dropped:0 overruns:0 frame:0
TX packets:2382074 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 lg file transmission:0
RX bytes:323495265 (308.5 MiB) TX bytes:323495

Je ne suis pas à meme de debugger, je cherche donc des billes et des infos pour essayer de trouver la source du problème. Qu'est-ce qui serait à tester, dois-je faire de la léchouille à TCPDUMP, existe-t-il des options du noyau qui me permettrait de tracer ce qui déconne ?
  • # proc et carte mere, udp

    Posté par  . Évalué à 1.

    Si tu as tout essayé sauf de changer de proc et de carte mere, je serais tenté de dire que le probleme vient d'un de ces 2 trucs (peut-etre la partie PCI de la carte mere).

    Mais tous les FAI ont régulièrement des saturations aux heures de pointe ce qui peut se traduire par des paquets perdus, et certains programmes sont assez sensibles à ce genre de perte (notamment ceux qui gèrent mal le fait que la couche udp ne demande pas la réémission des paquets perdus).

    Mes 2 centimes.
    • [^] # Re: proc et carte mere, udp

      Posté par  . Évalué à 1.

      Pour ce qui est de la bande passante, ce provider dispose d'une exellent connexion, jamais eus de problème.
      Je serais d'accord pour l'UDP si le SSH ne déboisait aps lui aussi.
  • # Le câble ?

    Posté par  (site web personnel) . Évalué à 1.

    Le câble réseau a peut-être la bougeotte (soit coté serveur, soit coté patch-panel) ?

    Normalement, tu devrais pouvoir vérifier ça en apt-get installant ifplugd. Ou alors, lancer dans un screen un ping vers ton premier hop, et voir comment il a réagi après un freeze.

    Enfin, c'est une piste à suivre...
    • [^] # Re: Le câble ?

      Posté par  . Évalué à 1.

      ifplugd ne correspond pas tout à fait, il faudrait que l'on puisse le passer en mode passif only.
  • # Contradiction...

    Posté par  . Évalué à 1.

    il y a une contradiction dans ton énoncé :
    soucis avec un serveur dédié en unstable

    qui explique peut-etre tes problemes
    • [^] # Re: Contradiction...

      Posté par  . Évalué à 1.

      Tout dépend de ce que tu veux faire avec. Je conçois que puisse parraitre contradictoire, mais aprés tout, j'aurais pris une ubuntu que celà aurait été assez proche et pourtant celà aurait semblé bien moins impie, non ?
      • [^] # Re: Contradiction...

        Posté par  . Évalué à 1.

        ben ca depend de la version d'ubuntu apres.

        pour mes serveurs montés en juillet et septembre j'ai pas pris la 6.10 beta mais plutot la 6.04.

        il est vrai que cela depend surtout de ce que tu veux en faire, mais en informatique en general on ne deploie jamais le dernier cri tout de suite.

        pour le poste client, on ne mettra pas forcement mandriva 2007 ou ubuntu 6.10 car c'est trop recent, donc pas forcement testé à fond (ne serait ce que dans nos services)

        Idem pour les serveurs : la derniere RHE, la derniere debian, on choisira toujours la stabilité pour eviter justement les plantages d'un trucs en prod sans savoir d'ou cela peut venir.

        mais apres tout c'est une question de choix technique et de politique d'administration...

Suivre le flux des commentaires

Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.