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

14

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

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

apr_socket_recv: Connection reset by peer (104)

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

Идеи?

apache-2.2 nginx connection benchmark Мэтью
источник

Ответы:

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

moneyfly
источник