Вопросы Теги

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

Старая привычка я предполагаю

Будучи долговременным пользователем Linux, я привык к тому, что Вы только получили поддержку если Вы где использование Windows. И после слушания

- "Извините мы только поддерживаем XXX"

много раз я узнавал, что это было быстрее, чтобы искать сеть и попытаться решить проблему мой сам...

14
задан 30 May 2010 в 03:59
5 ответов

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

7
ответ дан 2 December 2019 в 21:13

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

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

4
ответ дан 2 December 2019 в 21:13

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

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
ответ дан 2 December 2019 в 21:13

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

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

Я подумал о переходе на 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
ответ дан 2 December 2019 в 21:13

Эта проблема вызвана система. если передать системе запрос с высоким уровнем параллелизма. Ядро ОС активирует защиту от 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
ответ дан 2 December 2019 в 21:13

Теги

Похожие вопросы