Плохая ошибка шлюза 502 с прокси-сервером Apache mod и Tomcat
мы запускаем веб-приложение на Tomcat 6 и Apache mod_proxy 2.2.3. Видя много 502 ошибок, как это:
Плохой Шлюз! Прокси-сервер получил недопустимый ответ от вышестоящего сервера.
прокси-сервер не смог обработать запрос GET / the / page.сделай.
Причина: Ошибка чтения с удаленного сервера
Если вы считаете, что это ошибка сервера, обратитесь к веб-мастеру.
ошибка 502
Tomcat имеет много потоков, поэтому он не ограничен потоками. Мы толкаем 2400 пользователей через JMeter против приложения. Все коробки находятся внутри нашего брандмауэра в быстро выгруженной сети, поэтому проблем с сетью не должно быть.
У кого-нибудь есть предложения по вещам, чтобы посмотреть или попробовать? Далее мы направляемся в tcpdump.
UPDATE 10/21/08: все еще не понял этого. Видя только очень небольшое количество из них под нагрузкой. Этот ответы ниже не дали никаких магических ответов...еще. :)
8 ответов
чтобы добавить некоторые конкретные настройки, у меня была аналогичная настройка (с обратным проксированием Apache 2.0.63 на Tomcat 5.0.27).
для некоторых URL-адресов сервер Tomcat может занять, возможно, 20 минут, чтобы вернуть страницу.
Я закончил тем, что изменил следующие настройки в файле конфигурации Apache, чтобы предотвратить его тайм-аут с его прокси-операцией (с большим коэффициентом переполнения в случае, если Tomcat занял больше времени, чтобы вернуть страницу):
Timeout 5400
ProxyTimeout 5400
некоторые backgound
ProxyTimeout одного было недостаточно. Глядя на документацию для тайм-аут я гадание (я не уверен), что это потому, что, пока Apache ждет ответа от Tomcat, между Apache и браузером (или любым http - клиентом) нет трафика-и поэтому Apache закрывает соединение с браузером.
Я обнаружил, что если я уйду в тайм-аута по умолчанию (300 секунд), то если прокси-запрос Tomcat занял больше 300 секунд, чтобы получить ответ, браузер отобразит страницу "ошибка прокси-сервера 502". Я считаю, что это сообщение генерируется Apache, зная, что он действует как обратный прокси - сервер, прежде чем он закроет соединение с браузером (это мое текущее понимание-оно может быть ошибочным).
страница ошибки прокси-сервера говорит:
Прокси-Ошибка
прокси-сервер получил недопустимый ответ от вышестоящий сервер. Этот прокси-сервер не смог обработать запрос GET.
Причина: Ошибка чтения с удаленного сервера
...что говорит о том, что это слишком короткий параметр ProxyTimeout, в то время как исследование показывает, что параметр тайм-аута Apache (тайм-аут между Apache и клиентом) также влияет на это.
Итак, отвечая на мой собственный вопрос здесь. В конечном итоге мы определили, что видим ошибки 502 и 503 в балансировщике нагрузки из-за тайм-аута потоков Tomcat. В краткосрочной перспективе мы увеличили время ожидания. В долгосрочной перспективе, мы исправили проблемы приложения, которые вызывают перерывы в первую очередь. Почему тайм-ауты Tomcat воспринимались как ошибки 502 и 503 в балансировщике нагрузки, все еще остается загадкой.
Вы можете использовать proxy-initial-not-pooled
см.http://httpd.apache.org/docs/2.2/mod/mod_proxy_http.html:
Если эта переменная задана, пул не будет использоваться повторно, если клиентское соединение является начальным. Это позволяет избежать сообщения об ошибке "прокси: ошибка чтения строки состояния с удаленного сервера", вызванного условием гонки, что сервер бэкэнда закрыл соединение пула после проверки соединения прокси и до того, как данные, отправленные прокси, достигли бэкэнда. Следует иметь в виду, что установка этой переменной снижает производительность, особенно с клиентами HTTP/1.0.
У нас тоже была эта проблема. Мы исправили это, добавив
SetEnv proxy-nokeepalive 1
SetEnv proxy-initial-not-pooled 1
и поворачивая keepAlive на всех серверах выключен.
mod_proxy_http отлично в большинстве сценариев, но мы запускаем его с большой нагрузкой, и у нас все еще есть некоторые проблемы с таймаутом, которые мы не понимаем.
но смотри, если выше директива соответствует вашим потребностям.
пример из apache conf:
значение#по умолчанию-2 минуты.
тайм-аут 600
ProxyRequests off
ProxyPass /приложение балансир://приложение myapp stickysession=lbmethod JSESSIONID=bytraffic nofailover=о
ProxyPassReverse / балансировщик приложений: / / MyApp
ProxyTimeout 600
BalancerMember http://node1:8080/ route=node1 retry=1 max=25 timeout=600
.........
Я предполагаю, что вы используете mod_proxy_http (или прокси-балансировщик).
посмотрите в своих журналах tomcat (localhost.лог или Каталина.log) я подозреваю, что вы видите исключение в своем веб-стеке, пузырящемся и закрывающем сокет, к которому подключен работник tomcat.
вы должны иметь возможность решить эту проблему с помощью параметра timeout и proxyTimeout, установленного в 600 секунд. Это сработало для меня после борьбы некоторое время.
вы можете избежать глобальных таймаутов или виртуальных хостов, указав таймауты прокси в директиве ProxyPass следующим образом:
ProxyPass /svc http://example.com/svc timeout=600
ProxyPassReverse /svc http://example.com/svc timeout=600
обратите внимание timeout=600 секунд.
однако это не всегда работает, когда у вас есть балансировщик нагрузки. В этом случае вы должны добавить тайм-ауты в обоих местах (проверено в Apache 2.2.31)
балансировки нагрузки пример:
<Proxy "balancer://mycluster">
BalancerMember "http://member1:8080/svc" timeout=600
BalancerMember "http://member2:8080/svc" timeout=600
</Proxy>
ProxyPass /svc "balancer://mycluster" timeout=600
ProxyPassReverse /svc "balancer://mycluster" timeout=600
побочный Примечание:timeout=600 on ProxyPass не требовалось, когда Chrome был клиент (я не знаю, почему) но без этого ожидания ProxyPass Internet Explorer (11) прерывает сброс соединения сервером.
моя теория заключается в том, что:
ProxyPass timeout используется между клиентом (браузером) и Apache.
BalancerMember timeout используется между Apache и бэкэндом.
для тех, кто использует Tomcat или другие резервные копии, вы также можете обратить внимание на таймауты http-коннектора.