Обрывается tcp/ip соединение

как на апатче без него? только хуже..

Уже и без PMTU Discovery пробовал, менял MTU, уменьшал время TIME-WAIT.. короче по всякому..

ESTABLISHED соединений не более 1000, есть свободные LISTEN.. TcpMaxConnection уже задирал под 30 000.. всё бестолку..

Главное на интерфейсе, который трафик и не передаёт, порты в состоянии ESTABLISHED.. а трафика нет в эти периоды 15-20 сек..

С ngnix тоже пробовал по разному, уже настройки по минимуму оставил..

делал более одного процесса, менял количество поток, приоритетами игрался, разбивал на два виртуальных блока для каждого интерфейса и один блок, слушающий два ip.. Хоть бы хны.. При 800-1000 рабочих соединений один переда канал падает, другой работает и наоборот.. Такое ощущение, что ещё какое-то ограничение стоит.. Но я уже всё возможное перепробовал, тем более раз уже в параметры tcp полез

Хм.. интересно, если например воткнуть третью сетевуху и на неё пусть ещё запросы с третьей сети, какая будет ситуация? Надо вечером попробовать..

Что даёт его включение в подобное схеме ещё и на винде? Не нужно - отключить. Считаете иначе?

php используете ? если да, то как?

Конечно иначе. Настройка все-равно _уже_ отключена. То, что на апаче про

keepalive On/Off сказано - по барабану абсолютно, если на апач все через nginx идет.

случай из практики, nginx-apache-(php mod_fcgid) , онлайн порядка 600, при keepalive on дочек в состоянии "Waiting for Connection" на порядок больше нежели при keepalive off , даже несмотря на "Connection close" от nginx... на днях ещё на одном сервере проверю...

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

Проблему решил настройкой tcp/ip параметров, копался целый божий день и ночь с wireshark ловил красненькие пакеты. В итоге привёл к общему виду под необходимые задачи.. Просто запросов много и они мелкие по весу, а winwows по tcp окно настроит да и время умирания из time-wait было неоправданно долгим, убрал задержки между ожиданиями подтверждений и всякое по мелочи..

☝ Теперь всё ок! Спасибо всем кто поучаствовал обсуждении..

Уверен, что путаете причины. Скорее всего, дело в настройке директив конкретного

MPM типа префорк. Например, Max/MinSpaceWorkers.

Если таки нет - вы нашли багу в документации апача или реализации поддержки KeepAlive:

http://httpd.apache.org/docs/2.2/mod/core.html#keepalive

Добро пожаловать в багзиллу апача.

myhand, та нет, там всё упирается в HTTP 1.1 и 1.0 , и это уже не к апачу, да и багой не считается так как минорная версия... типа HTTP/1.0 апач игнорит и может спокойно использовать HTTP/1.1 , что он благополучно и делает

-----------------

GET /blablabal HTTP/1.0

///

HTTP/1.1 200 OK

Zaqwr, по цитированной ссылке ясно описано как себя ведет апач. Просто

прочитайте. Раз Вы утверждали, что наблюдаете эффект от KeepAlive On

- Вы нашли ошибку в документации либо реализации того, что

документировано. Логика простая - спорить не о чем.

Кстати. То, что апач отвечает HTTP/1.1 - просто означает то, что он понимает

эту версию протокола _включительно_. Уж никак не то, что он игнорирует

различий версий HTTP.

Картина была такая, что поочередно падали.. каналы передачи, то один то второй.. Теперь всё ок..

Ужас, сколько же всё таки ньюансов масса!

keepalive однозначно в оn. А если пугает, так есть keepalive timeout которым можно поиграться.