Вопрос: Понимание этой ошибки: apr_socket_recv: Сброс соединения с помощью peer (104)


Итак, если я проведу бенчмаркинг с помощью теста apache (ab), и я использую большое количество запросов. Затем иногда в середине теста я получаю эту ошибку.

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

apr_socket_recv: Connection reset by peer (104)

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

Идеи?


13
2018-05-30 00:59


Источник




Ответы:


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


6
2018-05-30 07:43





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

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


4
2018-03-13 07:21





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

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
2018-02-23 06:30





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

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

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

0
2017-07-11 21:24





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


-1
2017-11-30 22:46