Понимание этой ошибки: apr_socket_recv: сброс соединения одноранговым узлом (104)


14

Итак, если я сделаю какой-то сравнительный анализ с Apache Benchmark (AB), и я использую большое количество запросов. Тогда иногда в середине теста я получаю эту ошибку.

Я даже не знаю, что это значит. Так как я могу это исправить? Или это просто то, что произойдет, если сервер все равно получит слишком много попаданий? Проблема в том, что если я запустил 10000 хитов, все будет работать отлично. Если я запустлю его снова, он получит 4000 и получит ошибку:

apr_socket_recv: Connection reset by peer (104)

Немного о моей настройке: у меня nginx принимает статические запросы и обрабатывает динамические запросы в apache. Файл, о котором идет речь, подается из кэша с помощью nginx, так что, наверное, это связано с тем, как nginx обрабатывает запросы?

Идеи?

Ответы:


7

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


4

Это означает, что сервер сильно загружен запросом, т. Е. Все потоки заняты обслуживанием запроса. Решение: либо увеличьте количество атрибутов maxThread для соединителя в файле server.xml, либо увеличьте значение атрибута acceptCount.

acceptcount: максимальная длина очереди для входящих запросов на соединение, когда используются все возможные потоки обработки запросов. Любые запросы, полученные при заполнении очереди, будут отклонены.


0

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

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)


0

Помимо ответов здесь, я прочитал много других:

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

Я думал о переходе на 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

-1

Эта проблема вызвана системой. если дать высокий запрос на параллелизм в систему. Ядро ОС активирует защиту от переполнения 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использовался для защиты ОС, чтобы избежать атаки огромных запросов. Но если вы хотите использовать эту ОС для выполнения нагрузочного теста или теста производительности, вы должны закрыть эту функцию.

Используя наш сайт, вы подтверждаете, что прочитали и поняли нашу Политику в отношении файлов cookie и Политику конфиденциальности.
Licensed under cc by-sa 3.0 with attribution required.