Розуміння цієї помилки: apr_socket_recv: Скидання з'єднання одноранговим (104)

Отже, якщо я роблю деякий бенчмаркінг із тестом apache (ab), і використовую велику кількість запитів. Тоді іноді в середині тесту я отримую цю помилку.

Я навіть не знаю, що це означає. То як я можу це виправити? Або це просто щось, що станеться, якщо сервер все одно отримає занадто багато звернень? Проблема полягає в тому, що якщо я наберу 10000 звернень, то все буде ідеально. Якщо я запускаю його знову, він отримає 4000 і отримає помилку:

apr_socket_recv: Connection reset by peer (104)

Трохи про мою настройку: у мене nginx приймає статичні запити та обробляє динамічні в apache. Даний файл подається з кешу nginx, тож, мабуть, це пов'язане з тим, як nginx обробляє запити?

Ідеї?

Помилка означає, що інший кінець (веб-сервер) раптово відключився в середині сеансу. подивіться журнали помилок apache або nginx, щоб побачити, чи є там щось підозріле.

Це означає, що сервер сильно завантажений запитом, тобто всі потоки зайняті обслуговуванням запиту. Рішення: або збільшити кількість атрибутів maxThread для з'єднувача у файлі server.xml або збільшити значення атрибута acceptCount.

acceptcount: Максимальна довжина черги для вхідних запитів на з'єднання, коли використовуються всі можливі потоки обробки запитів. Будь-які запити, отримані, коли черга заповнена, буде відхилено.

У мене була така ж проблема, і моя версія сервера:

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

я видалив непотрібні модулі, і проблема пішла:

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

Отже, один з mod_fcgid , mod_php або mod_perl викликає проблему. Ви можете спробувати відключити їх, якщо ви не використовуєте.

(Бічна примітка; Якщо ви використовуєте opcache, відключіть також fast_shutdown. Це також спричинило проблеми: opcache.fast_shutdown = 0)

Окрім відповідей тут, я прочитав багато інших:

• Замінити localhostна127.0.0.1
• Оновіть версію apache (у мене є ApacheBench, Version 2.3 <$Revision: 1807734 $>)
• Додати -r(потім я отримаю apr_pollset_poll: The timeout specified has expired (70007))

Ніхто з них не допоміг.

Я думав про перехід до wrkтого, як побачив подібну боротьбу .

Пошук проблеми

Здається, проблема пов'язана з кількістю порід ефірма . Я намагався встановити його від 50000 до 25000, оскільки це діапазон портів. Ще не везе. Тоді у мене склалося враження, що це пов’язано з TIME_WAIT і цією публікацією в блозі . Я думаю, що міг би підтвердити це:

$ 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

Що я спробував

Я цього не виправив: - /

Відповідно sudo sysctl -a | grep net.ipv4.tcp, у мене є:

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

Це питання викликане системою. якщо дати високий запит на сумісність системі. Ядро ОС запустить захист від повені SYN. Так система відновить посилання. ви можете змінити конфігурацію ОС у файлі.

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

ви можете спробувати.

зазвичай атрибут net.ipv4.tcp_syncookiesвикористовувався для захисту ОС, щоб уникнути величезної атаки запиту. Але якщо ви хочете скористатися цією ОС для того, щоб зробити тест навантаження або перевірку продуктивності, вам слід закрити цю функцію.