Zrozumienie tego błędu: apr_socket_recv: Resetowanie połączenia przez peer (104)

Jeśli więc przeprowadzę testy porównawcze za pomocą testu porównawczego Apache (ab) i użyję dużej liczby żądań. Czasami w trakcie testu pojawia się ten błąd.

Nawet nie wiem co to znaczy. Jak mogę to naprawić? Czy jest to coś, co się stanie, jeśli serwer i tak otrzyma zbyt wiele trafień? Problem polega na tym, że jeśli wykonam 10 000 trafień, wszystko zadziała idealnie. Jeśli uruchomię go ponownie, przejdzie do 4000 i pojawi się błąd:

apr_socket_recv: Connection reset by peer (104)

Trochę o mojej konfiguracji: Nginx przyjmuje statyczne żądania i przetwarza dynamiczne żądania do apache. Plik, o którym mowa, jest obsługiwany z pamięci podręcznej przez nginx, więc myślę, że prawdopodobnie ma to związek z tym, jak nginx obsługuje żądania?

Pomysły?

Błąd oznacza, że ​​drugi koniec (serwer WWW) nagle rozłączył się w połowie sesji. spójrz na dzienniki błędów apache lub nginx, aby sprawdzić, czy jest tam coś podejrzanego.

Oznacza to, że serwer jest mocno obciążony żądaniem, tzn. Wszystkie wątki są zajęte obsługą żądania. Rozwiązanie: zwiększ liczbę atrybutów maxThread dla łącznika w pliku server.xml lub zwiększ wartość atrybutu acceptCount.

acceptcount: maksymalna długość kolejki dla żądań połączeń przychodzących, gdy używane są wszystkie możliwe wątki przetwarzania żądań. Wszelkie żądania otrzymane po zapełnieniu kolejki zostaną odrzucone.

Miałem ten sam problem, a moja wersja serwera to:

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

usunąłem niepotrzebne moduły i problem zniknął:

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

Więc jeden z mod_fcgid , mod_php lub mod_perl powoduje problem. Możesz spróbować je wyłączyć, jeśli nie używasz.

(Uwaga dodatkowa; Jeśli używasz opcache, wyłącz też fast_shutdown. To także powodowało problem: opcache.fast_shutdown = 0)

Oprócz odpowiedzi tutaj przeczytałem wiele innych:

• Zastąp localhostprzez127.0.0.1
• Zaktualizuj wersję apache (mam ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Dodaj -r(wtedy dostaję apr_pollset_poll: The timeout specified has expired (70007))

Żaden z nich nie pomógł.

Myślałem o zmianie wrkpo obejrzeniu podobnych zmagań .

Znalezienie problemu

Problem wydaje się być związany z ilością portów epermicznych . Próbowałem ustawić go z 50000 na 25000, ponieważ jest to zakres portów. Wciąż nie ma szczęścia. Potem odniosłem wrażenie, że jest to związane z TIME_WAIT i tym postem na blogu . Myślę, że mógłbym potwierdzić, że:

$ 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

Co próbowałem

Jak dotąd nie naprawiłem tego: - /

Według sudo sysctl -a | grep net.ipv4.tcpmam:

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

Ten problem jest spowodowany przez system. jeśli przekaże systemowi żądanie wysokiej współbieżności. Jądro systemu operacyjnego uruchomi ochronę przeciwpowodziową SYN. System zresetuje łącze. możesz zmodyfikować konfigurację systemu operacyjnego w pliku.

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

możesz tego spróbować.

zwykle ten atrybut net.ipv4.tcp_syncookiesbył używany do ochrony systemu operacyjnego, aby uniknąć ataku z użyciem ogromnych żądań. Ale jeśli chcesz użyć tego systemu operacyjnego do wykonania testu obciążenia lub testu wydajności, powinieneś zamknąć tę funkcję.