Comprendre cette erreur: apr_socket_recv: réinitialisation de la connexion par l'homologue (104)

Donc, si je fais de l'analyse comparative avec Apache benchmark (ab), et j'utilise un grand nombre de demandes. Puis parfois au milieu d'un test, j'obtiens cette erreur.

Je ne sais même pas ce que ça veut dire. Alors, comment puis-je y remédier? Ou est-ce simplement quelque chose qui se produira si le serveur reçoit trop de hits de toute façon? Le problème est que si je lance 10 000 coups sûrs, tout fonctionnera parfaitement. Si je le lance à nouveau, il atteindra 4000 et obtiendra l'erreur:

apr_socket_recv: Connection reset by peer (104)

Un peu sur ma configuration: j'ai nginx qui prend les requêtes statiques et traite les requêtes dynamiques pour apache. Le fichier en question est servi depuis le cache par nginx, donc je suppose que cela a probablement à voir avec la façon dont nginx gère les requêtes?

Des idées?

L'erreur signifie que l'autre extrémité (serveur Web) s'est soudainement déconnectée au milieu de la session. jetez un œil aux journaux d'erreurs apache ou nginx pour voir s'il y a quelque chose de suspect là-dedans.

Cela signifie que le serveur est lourdement chargé avec la demande, c'est-à-dire que tous les threads sont occupés à servir la demande. Solution: augmentez le nombre d'attributs maxThread pour le connecteur dans le fichier server.xml ou augmentez la valeur de l'attribut acceptCount.

acceptcount: longueur maximale de la file d'attente pour les demandes de connexion entrantes lorsque tous les threads de traitement des demandes possibles sont utilisés. Toute demande reçue lorsque la file d'attente est pleine sera refusée.

J'ai eu le même problème et ma version de serveur était:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips mod_fcgid/2.3.9 PHP/5.6.5 mod_perl/2.0.9dev Perl/v5.16.3

j'ai supprimé les modules inutiles et le problème a disparu:

Server Version: Apache/2.4.6 (CentOS) OpenSSL/1.0.1e-fips

Ainsi, l'un des modules mod_fcgid , mod_php ou mod_perl pose problème. Vous pouvez essayer de les désactiver si vous ne les utilisez pas.

(Remarque: si vous utilisez opcache, désactivez également fast_shutdown. Cela posait également problème: opcache.fast_shutdown = 0)

Outre les réponses ici, j'en ai lu beaucoup d'autres:

• Remplacer localhostpar127.0.0.1
• Mettre à jour la version apache (je l'ai ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Ajouter -r(alors je reçois apr_pollset_poll: The timeout specified has expired (70007))

Aucun d'eux n'a aidé.

J'ai pensé à passer à wrk après avoir vu des luttes similaires .

Trouver le problème

Le problème semble être lié à la quantité de ports sphériques . J'ai essayé de le régler de 50000 à 25000 car c'est la plage de ports. Toujours pas de chance. Ensuite, j'ai eu l'impression que c'était lié à TIME_WAIT et ce billet de blog . Je pense que je pourrais confirmer que:

$ netstat -nat | awk '{print $6}' | sort | uniq -c | sort -n

    1 CLOSE_WAIT
    1 established)
    1 Foreign
    4 LISTEN
    8 SYN_SENT
   62 SYN_RECV
  351 ESTABLISHED
13916 TIME_WAIT

Ce que j'ai essayé

Je ne l'ai pas encore résolu: - /

Selon sudo sysctl -a | grep net.ipv4.tcp, j'ai:

net.ipv4.tcp_tw_reuse = 0    # No luck setting only that to 1
net.ipv4.tcp_max_tw_buckets = 32768
net.ipv4.tcp_fin_timeout = 60  # Setting it to 5 didn't help either

Ce problème est dû au système. si donne une demande d'accès concurrentiel élevée au système. Le noyau du système d'exploitation déclenchera la protection contre les inondations SYN. Le système réinitialisera donc le lien. vous pouvez modifier la configuration du système d'exploitation dans le fichier.

#vi /etc/sysctl.conf
net.ipv4.tcp_syncookies = 0 # set value is 0
#sysctl -p # read config from the config file.

Tu peux l'essayer.

généralement, l'attribut net.ipv4.tcp_syncookiesétait utilisé pour protéger le système d'exploitation afin d'éviter l'énorme attaque de demande. Mais si vous souhaitez utiliser ce système d'exploitation pour effectuer un test de charge ou un test de performances, vous devez fermer cette fonctionnalité.