Miss34 Posté 3 Novembre 2005 Posté 3 Novembre 2005 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 failedIcmp: 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: 27328Tcp: 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 sentUdp: 381046 packets received 204394 packets to unknown port received. 0 packet receive errors 477001 packets sentTcpExt: 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 !
AvenueDuWeb Posté 3 Novembre 2005 Posté 3 Novembre 2005 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. @+
Dan Posté 3 Novembre 2005 Posté 3 Novembre 2005 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
Miss34 Posté 3 Novembre 2005 Auteur Posté 3 Novembre 2005 Il tourne sur le 2.4.31bipiv-ipv4 (sans grsecurity)
Dan Posté 3 Novembre 2005 Posté 3 Novembre 2005 Le grsecurity ne devrait faire aucune différence en ce qui concerne les interfaces Ethernet. As-tu contacté le support OVH ?
Miss34 Posté 3 Novembre 2005 Auteur Posté 3 Novembre 2005 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 ?
Dan Posté 3 Novembre 2005 Posté 3 Novembre 2005 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
Miss34 Posté 3 Novembre 2005 Auteur Posté 3 Novembre 2005 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.
Dan Posté 3 Novembre 2005 Posté 3 Novembre 2005 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
Miss34 Posté 3 Novembre 2005 Auteur Posté 3 Novembre 2005 En fait, j'ai bien fait ça : <VirtualHost *:80>ServerAdmin webmaster@----.comDocumentRoot -------User -----Group usersServerName www.----.comCustomLog /dev/null combinedScriptAlias /cgi-bin/ /home/ovh/cgi-bin/</VirtualHost><VirtualHost *:80>ServerAdmin webmaster@----.comDocumentRoot -------User -----Group usersServerName img.----.comCustomLog /dev/null combinedScriptAlias /cgi-bin/ /home/ovh/cgi-bin/</VirtualHost> Où dois-je rentrer l'ip de la 2e interface ?
Miss34 Posté 5 Novembre 2005 Auteur Posté 5 Novembre 2005 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-fc9e0000eth1 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ù ?
Dan Posté 5 Novembre 2005 Posté 5 Novembre 2005 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
Miss34 Posté 5 Novembre 2005 Auteur Posté 5 Novembre 2005 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
Dan Posté 5 Novembre 2005 Posté 5 Novembre 2005 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 ?
simpson Posté 7 Novembre 2005 Posté 7 Novembre 2005 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-fc9e0000eth1 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 ?
Dan Posté 7 Novembre 2005 Posté 7 Novembre 2005 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
Miss34 Posté 8 Novembre 2005 Auteur Posté 8 Novembre 2005 Le problème semble général pour les serveurs HG de chez ovh. Pour le moment, les réponses du contact ne m'ont rien apportées. cf forum ovh : http://forum.ovh.net/showthread.php?s=&threadid=5791
Urban Posté 8 Novembre 2005 Posté 8 Novembre 2005 Le serveur et le switch sont-il configuré de la même manière au niveau speed/duplex ? Parce que les lenteurs sur une interface non chargée ça peut être lié à ça.
Miss34 Posté 22 Novembre 2005 Auteur Posté 22 Novembre 2005 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 ioc0NMI: 0 0 0 0LOC: 53459871 53460048 53459764 53460536ERR: 0MIS: 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,01385 processes: 383 sleeping, 1 running, 1 zombie, 0 stoppedCPU0 states: 12,4% user, 4,4% system, 0,0% nice, 82,0% idleCPU1 states: 12,0% user, 3,0% system, 0,0% nice, 84,3% idleCPU2 states: 12,1% user, 4,4% system, 0,0% nice, 82,3% idleCPU3 states: 0,2% user, 92,0% system, 0,0% nice, 7,2% idleMem: 3616704K av, 3580096K used, 36608K free, 0K shrd, 123720K buffSwap: 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) ?
Miss34 Posté 22 Novembre 2005 Auteur Posté 22 Novembre 2005 (modifié) 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é 22 Novembre 2005 par Miss34
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant