Trop de TCP Connections provoque des déconnexions

Question

J'ai un serveur de jeu qui fonctionne avec TCP Connections. Le serveur débranchit les utilisateurs au hasard. Je pense que c'est associé avec TCP Paramètres du serveur.

Dans l'environnement de développement local, le code écrit peut gérer 8 000 utilisateurs simultanés sans aucune déconnexion ou erreur (à localhost).

Mais dans de réels serveur de Centos 5 64bit, serveur Création de ces déconnexions indépendantes du montant de la connexion TCP simultanée.

Le serveur semble ne pas être capable de gérer le débit.

netstat -s -t IcmpMsg: InType0: 31 InType3: 87717 InType4: 699 InType5: 2 InType8: 1023781 InType11: 7211 OutType0: 1023781 OutType3: 603 Tcp: 8612766 active connections openings 14255236 passive connection openings 12174 failed connection attempts 319225 connection resets received 723 connections established 6351090913 segments received 6180297746 segments send out 45791634 segments retransmited 0 bad segments received. 1664280 resets sent TcpExt: 46244 invalid SYN cookies received 3745 resets received for embryonic SYN_RECV sockets 327 ICMP packets dropped because they were out-of-window 1 ICMP packets dropped because socket was locked 11475281 TCP sockets finished time wait in fast timer 140 time wait sockets recycled by time stamp 1569 packets rejects in established connections because of timestamp 103783714 delayed acks sent 6929 delayed acks further delayed because of locked socket Quick ack mode was activated 6210096 times 1806 times the listen queue of a socket overflowed 1806 SYNs to LISTEN sockets ignored 1080380601 packets directly queued to recvmsg prequeue. 31441059 packets directly received from backlog 5272599307 packets directly received from prequeue 324498008 packets header predicted 1143146 packets header predicted and directly queued to user 3217838883 acknowledgments not containing data received 1027969883 predicted acknowledgments 395 times recovered from packet loss due to fast retransmit 257420 times recovered from packet loss due to SACK data 5843 bad SACKs received Detected reordering 29 times using FACK Detected reordering 12 times using SACK Detected reordering 1 times using reno fast retransmit Detected reordering 809 times using time stamp 1602 congestion windows fully recovered 1917 congestion windows partially recovered using Hoe heuristic TCPDSACKUndo: 8196226 7850525 congestion windows recovered after partial ack 139681 TCP data loss events TCPLostRetransmit: 26 10139 timeouts after reno fast retransmit 2802678 timeouts after SACK recovery 86212 timeouts in loss state 273698 fast retransmits 19494 forward retransmits 2637236 retransmits in slow start 33381883 other TCP timeouts TCPRenoRecoveryFail: 92 19488 sack retransmits failed 7 times receiver scheduled too late for direct processing 6354641 DSACKs sent for old packets 333 DSACKs sent for out of order packets 20615579 DSACKs received 2724 DSACKs for out of order packets received 123034 connections reset due to unexpected data 91876 connections reset due to early user close 169244 connections aborted due to timeout 28736 times unabled to send RST due to no memory IpExt: InMcastPkts: 2

Ce qui me fait penser, c'est que celles-ci semblent être très problématiques.

123034 connections reset due to unexpected data 91876 connections reset due to early user close 28736 times unabled to send RST due to no memory

Comment puis-je résoudre ces erreurs? Ai-je besoin de faire TCP Tuning?

EDIT : Certaines informations SYSCTL:

sysctl -A | grep net | grep mem net.ipv4.udp_wmem_min = 4096 net.ipv4.udp_rmem_min = 4096 net.ipv4.udp_mem = 772704 1030272 1545408 net.ipv4.tcp_rmem = 4096 87380 4194304 net.ipv4.tcp_wmem = 4096 16384 4194304 net.ipv4.tcp_mem = 196608 262144 393216 net.ipv4.igmp_max_memberships = 20 net.core.optmem_max = 20480 net.core.rmem_default = 129024 net.core.wmem_default = 129024 net.core.rmem_max = 131071 net.core.wmem_max = 131071

EDIT : Infos EthTool pour 2 cartes Ethernet détectées:

Settings for eth0: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: 1000Mb/s Duplex: Full Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: yes Settings for eth1: Supported ports: [ TP ] Supported link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Supports auto-negotiation: Yes Advertised link modes: 10baseT/Half 10baseT/Full 100baseT/Half 100baseT/Full 1000baseT/Full Advertised auto-negotiation: Yes Speed: Unknown! Duplex: Half Port: Twisted Pair PHYAD: 1 Transceiver: internal Auto-negotiation: on Supports Wake-on: g Wake-on: d Link detected: no

Trevor Benson · Answer

Par "Server Débranchit les utilisateurs de manière aléatoire" Si vous vouliez dire des clients se déconnecter sans la nageoire attendue, ACK, la RST, je résoudrais d'abord l'interface demi-duplex, surtout si votre environnement de développement a à la fois des NIC en duplex intégral. L'interface ETH1 étant en demi-duplex lors de la négociation automatique = ON est généralement causée par:

La négociation automatique entre le commutateur et le serveur a échoué.
Le commutateur ayant une négociation automatique désactivée, définissant explicitement la vitesse et le duplex pour le port.

Je le vois plus souvent dans la situation n ° 2, mais c'est probablement parce que cela fait plus d'une décennie depuis que je constate sciemment qu'un échec de négociation automatique de l'examen. Le comportement de négociation automatique Ethernet Lorsqu'un côté est automatique et que l'autre est codé en dur (ou échoue à la réponse) est destiné au côté automatique de baisser en mode moitié duplex.

En termes simples, Eth1 étant en demi-duplex, le serveur n'envoie ou ne reçoit que des données via l'interface au lieu d'envoyer et de recevoir. Le côté codé dur sera toujours en mode duplex intégral et tentera d'envoyer des données au serveur lors de la réception de données du serveur. Cependant, le serveur examinera cette collision car elle suppose un domaine de collision, où le duplex complet élimine les domaines de collision. Le serveur utilisera un algorithme de backoff pour planifier une retransmission. Le serveur continuera à augmenter le temps d'attendre de retransmettre les données s'il continue à expérimenter ce qu'il pense est une collision.

Ainsi, avoir un partenaire de demi-duplex à moitié duplex W/Full Duplex peut facilement causer des déconnectes de clients, des problèmes de débit ou de performance, des pics de latence et d'autres problèmes divers.