Aller au contenu

[Dédié] Ralentissement réseau


Miss34

Sujets conseillés

Coucou !

Je vous fais part d'un problème que connais un des mes dédiés actuellement.

La config est un Bi Xeon , 4 GO de RAM, avec deux interfaces Gigabit Ethernet.

Le serveur (distrib RedHat 7.2) comporte essentiellemnt, un serveur Apache/PHP, et un serveur Shoutcast.

Lorsque on dépasse les 500/600 requêtes traitées par Apache chaque seconde, le serveur rame beaucoup. Le problème ne se situe pas au niveau d'Apache étant donné qu'il a toujours des slots de libre, et le temps de génération des pages est toujours très faible (0,001 à 0,1 sec).

Simplement, c'est l'envoi de ces pages qui traine. (le navigateur va trainer sur "Connexion à www.blablabla". Les pages ne finissent parfois pas de s'afficher. De même dans Shoutcast, on peut observer des coupures. SSH devient très lent, ainsi que FTP (connexion lente et transfert très saccadé)

Dans le log des messages, je peux voir, lorsqu'on est à fort trafic, plein de messages de ce genre se succéder :

Ip:
   745398919 total packets received
   3263154 forwarded
   0 incoming packets discarded
   738234390 incoming packets delivered
   847730253 requests sent out
   593 outgoing packets dropped
   476 fragments dropped after timeout
   1608 reassemblies required
   476 packet reassembles failed
Icmp:
   38650 ICMP messages received
   35 input ICMP message failed.
   Histogramme d'entrée ICMP
       destination unreachable: 10693
       timeout in transit: 488
       source quenches: 137
       echo requests: 27328
       echo replies: 4
   231826 ICMP messages sent
   0 ICMP messages failed
   Histogramme de sortie ICMP
       destination unreachable: 204498
       echo replies: 27328
Tcp:
   16709048 active connections openings
   82105403 passive connection openings
   844976 failed connection attempts
   731634 connection resets received
   68 connections established
   741509537 segments received
   847021115 segments send out
   11242309 segments retransmited
   8848 bad segments received.
   113985 resets sent
Udp:
   381046 packets received
   204394 packets to unknown port received.
   0 packet receive errors
   477001 packets sent
TcpExt:
   1394329 resets received for embryonic SYN_RECV sockets
   411 packets pruned from receive queue because of socket buffer overrun
   39 ICMP packets dropped because they were out-of-window
   24 ICMP packets dropped because socket was locked
   ArpFilter: 0
   93462248 TCP sockets finished time wait in fast timer
   68 time wait sockets recycled by time stamp
   58 packets rejects in established connections because of timestamp
   1344736 delayed acks sent
   3754269 delayed acks further delayed because of locked socket
   Quick ack mode was activated 729041 times
   33077 times the listen queue of a socket overflowed
   33077 SYNs to LISTEN sockets ignored
   187974152 packets directly queued to recvmsg prequeue.
   245457167 packets directly received from backlog
   18915718 packets directly received from prequeue
   76 packets dropped from prequeue
   25958423 packets header predicted
   87492666 packets header predicted and directly queued to user
   TCPPureAcks: 281876803
   TCPHPAcks: 57354842
   TCPRenoRecovery: 21585
   TCPSackRecovery: 1996906
   TCPSACKReneging: 62
   TCPFACKReorder: 1335
   TCPSACKReorder: 272
   TCPRenoReorder: 406
   TCPTSReorder: 233
   TCPFullUndo: 495
   TCPPartialUndo: 970
   TCPDSACKUndo: 42438
   TCPLossUndo: 339973
   TCPLoss: 1490295
   TCPLostRetransmit: 311
   TCPRenoFailures: 9726
   TCPSackFailures: 1140159
   TCPLossFailures: 109938
   TCPFastRetrans: 2863456
   TCPForwardRetrans: 71502
   TCPSlowStartRetrans: 2672066
   TCPTimeouts: 3110501
   TCPRenoRecoveryFail: 5337
   TCPSackRecoveryFail: 438424
   TCPSchedulerFailed: 76012
   TCPRcvCollapsed: 12398
   TCPDSACKOldSent: 748404
   TCPDSACKOfoSent: 5232
   TCPDSACKRecv: 824290
   TCPDSACKOfoRecv: 79
   TCPAbortOnSyn: 0
   TCPAbortOnData: 4506
   TCPAbortOnClose: 4495
   TCPAbortOnMemory: 0
   TCPAbortOnTimeout: 47385
   TCPAbortOnLinger: 0
   TCPAbortFailed: 0
   TCPMemoryPressures: 0

Merci bcp pour votre aide !

Lien vers le commentaire
Partager sur d’autres sites

Salut,

Tu as peut-être une carte réseau défectueuse. Je connais quelqu'un qui avait plus ou moins le même type de problème et après avoir changé la carte réseau tout était revenu en place. Mais je laisse les pros parler car je n'en suis absolument pas certain. @+

Lien vers le commentaire
Partager sur d’autres sites

Une question importante à mon avis ... quel noyau tournes-tu ?

Normalement tu devrais tourner le 2.4.31grs-bipiv-ipv4 sur un Bi-Xeon.

L'IP V6 n'est pas encore tout à fait au point si l'on en croit Octave Klaba (OVH) et il peut susciter des montées en charge ou de l'instabilité du serveur. ;)

Dan

Lien vers le commentaire
Partager sur d’autres sites

Je viens de regarder un truc (mais ça ne résoudra peut être pas le pb) :

Je pensais avoir réparti le trafic sur les deux interfaces réseau, mais ça n'a pas l'air d'être le cas.

En effet, le trafic des pages web est sur ma 1e IP (eth0).

Et j'ai paramétré le serveur dns pour que les images (accessibles depuis le sous domaine img.---.com) passent par ma 2e IP (2e interface).

Or les requetes sont bien reçues sur la 2e interface, mais le résultat est re-émis sur la 1e.

Comment dois je faire avec Apache pour faire deux Virtual Hosts : l'un sur eth0, et l'autre sur eth1 ?

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

C'est simple si tu veux y mettre des domaines différents.

Tu ajoutes un NameVirtualHost pour la deuxième IP.

Et tu crées un VirtualHost avec cette IP.

Que veux-tu faire précisément ?

Dan

Lien vers le commentaire
Partager sur d’autres sites

Je voudrais en gros :

www.----.com >> 1e IP (eth0)

img.----.com >> 2e IP (eth1)

Le DNS pour img.----.com est bien paramétré sur la 2e IP (eth1).

Mais le pb, c'est que le résultat des requêtes sort toujours par eth0.

Lien vers le commentaire
Partager sur d’autres sites

Il faut rajouter un VirtualHost dans le fichier httpd.conf pour img.---.com avec comme IP la seconde IP (eth1)

Copie le bloc contenant le www et change juste l'IP (et éventuellement les alias.

Redémarre Apache, et si le DNS pointe comme il faut, cela daoit marcher.

Dan

Lien vers le commentaire
Partager sur d’autres sites

En fait, j'ai bien fait ça :

<VirtualHost *:80>
ServerAdmin webmaster@----.com
DocumentRoot -------
User -----
Group users
ServerName www.----.com
CustomLog /dev/null combined
ScriptAlias /cgi-bin/ /home/ovh/cgi-bin/
</VirtualHost>

<VirtualHost *:80>
ServerAdmin webmaster@----.com
DocumentRoot -------
User -----
Group users
ServerName img.----.com
CustomLog /dev/null combined
ScriptAlias /cgi-bin/ /home/ovh/cgi-bin/
</VirtualHost>

Où dois-je rentrer l'ip de la 2e interface ?

Lien vers le commentaire
Partager sur d’autres sites

Pour la répartition de trafic sur les deux interfaces, j'ai enfin réussi. Ce ne se fait pas au niveau d'apache, mais de la config réseau. On peut faire du bounding, ou sinon, tout simplement défénir des regles de routage vers l'une ou l'autre des intarfaces selon l'ip du client :

80.0.0.0 > eth0

81.0.0.0 > eth1

etc ...

Mais j'observe toujours le mêmem problème ..

Je remarque quelque chose (et je suis sûr que c'est lié à mon problème) :

Si je fais un ifconfig, j'ai ça :

eth0      Lien encap:Ethernet  HWaddr 00:30:48:81:8F:15
         inet adr:213.---.---.30  Bcast:213.---.---.255  Masque:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:285636311 errors:5451692 dropped:5451692 overruns:2113212 frame:0
         TX packets:333153006 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:100000
         RX bytes:914168409 (871.8 Mb)  TX bytes:2065695838 (1970.0 Mb)
         Adresse de base:0xb800 Mémoire:fc9c0000-fc9e0000

eth1      Lien encap:Ethernet  HWaddr 00:30:48:81:8F:14
         inet adr:213.---.---.30  Bcast:213.---.---.255  Masque:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:115234759 errors:902752 dropped:902752 overruns:71692 frame:0
         TX packets:138008653 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:100000
         RX bytes:3514056880 (3351.2 Mb)  TX bytes:582474172 (555.4 Mb)
         Adresse de base:0xbc00 Mémoire:fc9e0000-fca00000

Quand on regarde les paquets en réception (RX Packets), j'ai beaucoup de "dropped", "errors", et "overruns". Et justement, ce nombre de packets augmente considérablement à haut trafic.

Par contre, aucun problème visible pour les packets transmis ...

Ca peut venir d'où ?

Lien vers le commentaire
Partager sur d’autres sites

Bonjour,

Il faut remplacer les <VirtualHost *:80> par <VirtualHost xxx.yyy.zzz.ttt:80> en mettant les IP adéquates. ;)

Le problème de <VirtualHost *:80> est que le VirtualHost est actif quelle que soit l'IP !

Dan

Lien vers le commentaire
Partager sur d’autres sites

De toutes façons, mon pb n'est plus là.

Mais ce que tu proposes Dan, ça ne marche pas. Les IP configurées dans les VHosts ne servent que pour l'écoute. Mais l'ensemble des données renvoyées sont gérées par le système. C'est lui qui va décider par quelle interface ça va passer (selon les règle du rout), pas Apache.

Mais c'est pas grave .. car la répartition de trafic ne résoud pas mon pb. Regarde mon message précédent, j'ai détaillé le ifconfig qui met en valeur le souci :o

Lien vers le commentaire
Partager sur d’autres sites

Mais ce que tu proposes Dan, ça ne marche pas.

C'est pourtant exactement comme ça que j'ai paramétré l'un des serveurs infogérés par le Hub, et ça marche très bien ainsi :)

Et il n'a aucune erreur sur les interfaces, ni en TX, ni en RX ...

As-tu contacté le support OVH pour ces erreurs d'interface ?

Lien vers le commentaire
Partager sur d’autres sites

Pour la répartition de trafic sur les deux interfaces, j'ai enfin réussi. Mais j'observe toujours le mêmem problème ...

Je remarque quelque chose (et je suis sûr que c'est lié à mon problème) :

Si je fais un ifconfig, j'ai ça :

eth0      Lien encap:Ethernet  HWaddr 00:30:48:81:8F:15
         inet adr:213.---.---.30  Bcast:213.---.---.255  Masque:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:285636311 errors:5451692 dropped:5451692 overruns:2113212 frame:0
         TX packets:333153006 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:100000
         RX bytes:914168409 (871.8 Mb)  TX bytes:2065695838 (1970.0 Mb)
         Adresse de base:0xb800 Mémoire:fc9c0000-fc9e0000

eth1      Lien encap:Ethernet  HWaddr 00:30:48:81:8F:14
         inet adr:213.---.---.30  Bcast:213.---.---.255  Masque:255.255.255.0
         UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
         RX packets:115234759 errors:902752 dropped:902752 overruns:71692 frame:0
         TX packets:138008653 errors:0 dropped:0 overruns:0 carrier:0
         collisions:0 lg file transmission:100000
         RX bytes:3514056880 (3351.2 Mb)  TX bytes:582474172 (555.4 Mb)
         Adresse de base:0xbc00 Mémoire:fc9e0000-fca00000

Salut,

J'ai pas tout suivi mais je remarque que tu semble donner la même adresse IP à tes deux interfaces réseau :

eth0: inet adr:213.---.---.30

eth1: inet adr:213.---.---.30

Avec la même IP sur deux cartes réseau, tu ne peux avoir que des problèmes !

Ca fait avancer la réflexion sur ton problème ?

Lien vers le commentaire
Partager sur d’autres sites

Chez OVH, les cartes montées sur les Bi-Xeon ont des classes C différentes.

Exemple 123.123.001.123 et 123.123.002.123

Et la classe est masquée dans son post ;)

Dan

Lien vers le commentaire
Partager sur d’autres sites

  • 2 semaines plus tard...

Malgré la répartition des données réseaux, ça ne change rien.

J'ai quelque chose qui m'intrigue tout de même :

En regardant mes MRTG, j'ai énormément d'interruptions réseau (environ 5000 interruptions par seconde en cumulant eth0 et eth1).

En faisant un cat /proc/interrupts , j'obtiens ça :

# cat /proc/interrupts
          CPU0       CPU1       CPU2       CPU3
 0:        141          0          0   53459452    IO-APIC-edge  timer
 1:          0          0          0          2    IO-APIC-edge  keyboard
 2:          0          0          0          0          XT-PIC  cascade
 4:          0          0          0         17    IO-APIC-edge  serial
 8:          0          0          0          1    IO-APIC-edge  rtc
26:          0          0          0  543840206   IO-APIC-level  eth1
27:          0          0          0  870705425   IO-APIC-level  eth0
50:          0          0          0   40608310   IO-APIC-level  ioc0
NMI:          0          0          0          0
LOC:   53459871   53460048   53459764   53460536
ERR:          0
MIS:          0

En faisant un top, j'ai toujours le CPU3 qui est nettement plus utilisé (avec même régulièrement du 0% en idle).

Exemple :

 9:58pm  up 6 days,  4:46,  2 users,  load average: 1,36, 2,32, 4,01
385 processes: 383 sleeping, 1 running, 1 zombie, 0 stopped
CPU0 states: 12,4% user,  4,4% system,  0,0% nice, 82,0% idle
CPU1 states: 12,0% user,  3,0% system,  0,0% nice, 84,3% idle
CPU2 states: 12,1% user,  4,4% system,  0,0% nice, 82,3% idle
CPU3 states:  0,2% user, 92,0% system,  0,0% nice,  7,2% idle
Mem:  3616704K av, 3580096K used,   36608K free,       0K shrd,  123720K buff
Swap:  522104K av,    6976K used,  515128K free                 2505300K cached

Je pense que dans mon cas, il pourrait y avoir des blocages réseau du à ça.

Y aurait un moyen de répartir les interruptions réseau sur les différents CPU, ou au moins répartir entre eth0 et eth1 (genre mettre eth0 sur CPU0 et eth1 sur CPU1) ?

Lien vers le commentaire
Partager sur d’autres sites

Je vais me répondre moi même finallement (en cherchant bien j'ai fini par trouver !!)

Dans /proc/irq , il y a un dossier correspondant à chacune des interruptions (des dossiers correspondant au numéro de l'IRQ).

Dans chacun de ces dossiers, il faut modifier le "fichier" smp_affinity :

Si on fait

echo "01" > smp_affinity

, ça va rediriger les interruptions vers la 1e unité de traitement (c'est à dire CPU0)

idem avec 02 (pour CPU1) ....

Modifié par Miss34
Lien vers le commentaire
Partager sur d’autres sites

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant
×
×
  • Créer...