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 free2.org . Évalué à 1.
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 feelgoord . Évalué à 1.
Je serais d'accord pour l'UDP si le SSH ne déboisait aps lui aussi.
# Le câble ?
Posté par Amand Tihon (site web personnel) . Évalué à 1.
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 feelgoord . Évalué à 1.
# Contradiction...
Posté par NeoX . Évalué à 1.
soucis avec un serveur dédié en unstable
qui explique peut-etre tes problemes
[^] # Re: Contradiction...
Posté par feelgoord . Évalué à 1.
[^] # Re: Contradiction...
Posté par NeoX . Évalué à 1.
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.