Ограничения балансировки нагрузки Apache с Tomcat через AJP
У меня есть Apache, выступающий в качестве балансировщика нагрузки перед 3 серверами Tomcat. Иногда Apache возвращает 503 ответа, которые я хотел бы удалить полностью. Все 4 сервера не находятся под значительной нагрузкой с точки зрения процессора, памяти или диска, поэтому я немного не уверен, что достигает его пределов или почему. 503 возвращаются, когда все работники находятся в состоянии ошибки - что бы это ни значило. Вот подробности:
Конфигурация Apache:
<IfModule mpm_prefork_module>
StartServers 30
MinSpareServers 30
MaxSpareServers 60
MaxClients 200
MaxRequestsPerChild 1000
</IfModule>
...
<Proxy *>
AddDefaultCharset Off
Order deny,allow
Allow from all
</Proxy>
# Tomcat HA cluster
<Proxy balancer://mycluster>
BalancerMember ajp://10.176.201.9:8009 keepalive=On retry=1 timeout=1 ping=1
BalancerMember ajp://10.176.201.10:8009 keepalive=On retry=1 timeout=1 ping=1
BalancerMember ajp://10.176.219.168:8009 keepalive=On retry=1 timeout=1 ping=1
</Proxy>
# Passes thru track. or api.
ProxyPreserveHost On
ProxyStatus On
# Original tracker
ProxyPass /m balancer://mycluster/m
ProxyPassReverse /m balancer://mycluster/m
Конфигурация Tomcat:
<Server port="8005" shutdown="SHUTDOWN">
<Listener className="org.apache.catalina.core.AprLifecycleListener" SSLEngine="on" />
<Listener className="org.apache.catalina.core.JasperListener" />
<Listener className="org.apache.catalina.mbeans.ServerLifecycleListener" />
<Listener className="org.apache.catalina.mbeans.GlobalResourcesLifecycleListener" />
<Service name="Catalina">
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="8443" />
<Connector port="8009" protocol="AJP/1.3" redirectPort="8443" />
<Engine name="Catalina" defaultHost="localhost">
<Host name="localhost" appBase="webapps"
unpackWARs="true" autoDeploy="true"
xmlValidation="false" xmlNamespaceAware="false">
</Engine>
</Service>
</Server>
Журнал ошибок Apache:
[Пн Март 22 18:39:47 2010] [error] (70007) Истекло указанное время ожидания: proxy: AJP: попытка подключения к 10.176.201.10:8009 (10.176.201.10) не удалась [Mon Mar 22 18:39:47 2010] [error] ap_proxy_connect_backend отключение работника для (10.176.201.10) [понедельник, 22 18:39:47 2010] [error] прокси-сервер: AJP: не удалось установить соединение с бэкендом: 10.176.201.10 [пн, 22 18:39: 47 2010] [ошибка] (70007) Истекло указанное время ожидания: прокси: AJP: попытка подключения к 10.176.201.9:8009 (10.176.201.9) не удалась [Пн Мар 22 18:39:47 2010] [ошибка] ap_proxy_connect_backend отключение работника для (10.176.201.9) [пн, 22 марта 18:39:47 2010] [error] прокси-сервер: AJP: не удалось установить соединение с бэкендом: 10.176.201.9 [пн, 22 марта 18:39:47 2010] [error] (70007) Указанный тайм-аут истек: proxy: AJP: попытка подключения к 10.176.219.168:8009 (10.176.219.168) завершилась неудачей [Пн 22 Мар 18:39:47 2010] [error] ap_proxy_connect_backend отключение работника для (10.176.219.168) [Пн Март 22 18:39:47 2010] [error] прокси: AJP: не удалось установить соединение с бэкендом: 10.176.219.168 [пн 22 мар. 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники находятся в состоянии ошибки [Пн. Мар. 22 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники находятся в состоянии ошибки [Пн. Мар. 22 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники находятся в состоянии ошибки [Пн. Мар. 22 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники находятся в состоянии ошибки [Пн. Мар. 22 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники находятся в состоянии ошибки [Пн. Мар. 22 18:39:47 2010] [ошибка] прокси: BALANCER: (балансировщик://mycluster). Все работники в состоянии ошибки
Балансировщик нагрузки top Информация:
вверх - 23:44:11 до 210 дней, 4:32, 1 пользователь, средняя загрузка: 0,10, 0,11, 0,09 Задачи: всего 135, 2 бега, 133 сна, 0 остановок, 0 зомби Процессор (ы): 0,1% США, 0,2%sy, 0,0%ni, 99,2%id, 0,1%wa, 0,0%hi, 0,1%si, 0,3%st Память: всего 524508 КБ, использовано 517132 КБ, 7376 КБ свободно, буферы 9124 КБ. Обмен: всего 1048568 тыс., Использовано 352 тыс., Свободно 1048216 тыс., Кэшировано 334720 тыс.
Кот top Информация:
вверх - 23:47:12 до 210 дней, 3:07, 1 пользователь, средняя загрузка: 0,02, 0,04, 0,00 Задачи: 63 всего, 1 работает, 62 спит, 0 остановлен, 0 зомби Процессор (ы): 0,2% США, 0,0%sy, 0,0%ni, 99,8%id, 0,1%wa, 0,0%hi, 0,0%si, 0,0%st Память: всего 2097372 КБ, использовано 2080888 КБ, свободно 16484 КБ, буферы 21464 КБ Обмен: всего 4194296 тыс., Использовано 380 тыс., Свободно 4193916 тыс., Кэшировано 1520912 тыс.
Catalina.out не имеет сообщений об ошибках в нем.
Судя по состоянию сервера Apache, оно достигает максимума при 143 запросах в секунду. Я считаю, что серверы могут выдерживать значительно большую нагрузку, чем они есть, поэтому любые советы по поводу низких пределов по умолчанию или других причин, по которым эта установка будет максимальной, будет принята с благодарностью.
7 ответов
Решение этой проблемы довольно простое:
добавить в Proxypass:
BalancerMember ajp: //10.176.201.9: 8009 keepalive = On ttl = 60
добавить в Tomcats Server.xml:
Порт соединителя ="8009" протокол = "AJP / 1.3" redirectPort = "8443 connectionTimeout =" 60000 "
После этих изменений все должно работать нормально:-)
Учитывая, что журнал Apache показывает, что он не может подключиться к Tomcat (из вашего журнала ошибок), может показаться, что это приложение Tomcat, которое не может идти в ногу.
Когда я работал системным администратором на крупном веб-сайте Tomcat, я заметил серьезные ограничения производительности, и они были связаны не с процессором, а с проблемами синхронизации между потоками или задержками при запросе внутреннего веб-сервиса.
Последнее было огромной проблемой, потому что популярный интерфейс Java HTTP ограничивает количество одновременных подключений к другому веб-серверу по умолчанию до 2 (когда я обнаружил это, у меня отвисла челюсть). См. http://hc.apache.org/httpclient-3.x/threading.html
Вызывает ли ваше веб-приложение какие-либо другие веб-сервисы?
Похоже, что Apache получает тайм-аут соединения с серверами в пуле, из-за чего он не может обслуживать запрос. Ваше значение времени ожидания выглядит ОЧЕНЬ низким, прерывистая задержка в сети или даже страница, на создание которой уходит немного больше времени, может привести к выпадению сервера из пула. Я бы попробовал более высокие значения тайм-аута и повторных попыток и, возможно, более высокое значение ping.
Вы также можете подумать о переключении на рабочий или событийный mpm, как правило, prefork mpm имеет худшую производительность.
Отдельное ПО для прокси / балансировки, такое как squid, также может быть хорошим вариантом.
Ваши экземпляры кота зашли в тупик? Я был свидетелем того, как два крупных корпоративных (разных компаний) проекта Tomcat страдают от тупиковой ситуации - один был вызван использованием более старой версии сторонней библиотеки.
Можете ли вы подключиться напрямую к экземпляру tomcat локально? То есть:
telnet localhost 8080
Затем введите:
GET / HTTP/1.0\n
\n
(где \n ссылается на клавишу
Если нет, то кажется, что ваш экземпляр tomcat умер или заблокирован. Если он заблокирован, то пришло время получить дамп стека вашего экземпляра tomcat java, используя jstack программа (с PID Java-программы Tomcat).
Давайте ответим на этот вопрос, 6 лет спустя =D
retry=1 timeout=1
Это проблема. Время ожидания и повторные попытки слишком короткие.
Тайм-аут будет считать сервер мертвым, если он не ответит в течение 1 секунды. Слишком мало времени для обработки некоторых запросов (особенно если вы выполняете нагрузочное тестирование со скоростью 500 запросов в секунду).
Обратите внимание, что как только сервер выходит из строя, оставшиеся 2 сервера получают +50% запросов, и их время отклика значительно возрастает, так что они, вероятно, также мгновенно прекратят работу. Типичный каскадный сбой.
Вы получаете 503 "Служба недоступна", потому что Apache считает все серверы мертвыми, потому что они не отвечают достаточно быстро под нагрузкой, потому что ваше время ожидания слишком короткое.
Удалить обе настройки. Вообще говоря, НИКОГДА не настраивайте время ожидания менее 5 секунд в любом месте.
Я столкнулся с точно такой же проблемой. Возьмите дамп потока во время возникновения проблемы, вы будете знать, какой поток блокируется и впредь блокирует другие потоки. Между тем все порты AJP используются, и в конечном итоге Apache умирает. Но эта проблема не имеет ничего общего с настройками Apache. Проблема в приложении (уровень Tomcat).
PAS,
Я не увидел значение тайм-аута в журнале Apache, который вы вставили. Если это 300, попробуйте изменить его на 1200. У нас была та же проблема, и мы изменили время ожидания в файле Apache httpd.conf с 300 до 1200.