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

14

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?

apache-2.2 nginx connection benchmark Mateusz
źródło

Odpowiedzi:

7

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.

Aleksandar Ivanisevic
źródło
4

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.

Kushal Bafna
źródło
0

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)

Ünsal Korkmaz
źródło
0

Oprócz odpowiedzi tutaj przeczytałem wiele innych:

Ż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
Martin Thoma
źródło
-1

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ę.

Moneyfly
źródło