Вопрос: Ограничения для балансировки нагрузки Apache с Tomcat над AJP


У меня Apache действует как балансировщик нагрузки перед 3 серверами Tomcat. Иногда Apache возвращает 503 ответа, которые я хотел бы удалить полностью. Все 4 сервера не имеют значительной нагрузки с точки зрения процессора, памяти или диска, поэтому я немного не уверен, что достигает его пределов или почему. 503s возвращаются, когда все работники находятся в состоянии ошибки - что бы это ни значило. Вот подробности:

Конфигурация 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:

[Mon Mar 22 18:39:47 2010] [error] (70007) Истекший тайм-аут: прокси: AJP: попытка подключения к 10.176.201.10:8009 (10.176.201.10) не выполнена
[Mon Mar 22 18:39:47 2010] [ошибка] ap_proxy_connect_backend отключить работу для (10.176.201.10)
[Mon Mar 22 18:39:47 2010] [error] proxy: AJP: не удалось установить соединение с бэкэнд: 10.176.201.10
[Mon Mar 22 18:39:47 2010] [error] (70007) Истекший таймаут: прокси: AJP: попытка подключения к 10.176.201.9:8009 (10.176.201.9) не выполнена
[Mon Mar 22 18:39:47 2010] [ошибка] ap_proxy_connect_backend отключить работу для (10.176.201.9)
[Mon Mar 22 18:39:47 2010] [error] proxy: AJP: не удалось установить соединение с бэкэнд: 10.176.201.9
[Mon Mar 22 18:39:47 2010] [error] (70007) Истекший тайм-аут: прокси: AJP: попытка подключения к 10.176.219.168:8009 (10.176.219.168) не выполнена
[Mon Mar 22 18:39:47 2010] [ошибка] ap_proxy_connect_backend отключить работу для (10.176.219.168)
[Mon Mar 22 18:39:47 2010] [error] proxy: AJP: не удалось подключиться к бэкэнд: 10.176.219.168
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки
[Mon Mar 22 18:39:47 2010] [error] proxy: BALANCER: (балансир: // mycluster). Все работники находятся в состоянии ошибки

Балансировщик нагрузки top Информация:

вверх - 23:44:11 до 210 дней, 4:32, 1 пользователь, в среднем: 0.10, 0.11, 0.09
Задачи: 135 всего, 2 бега, 133 сна, 0 остановлено, 0 зомби
Cpu (s): 0.1% us, 0.2% sy, 0.0% ni, 99.2% id, 0.1% wa, 0.0% hi, 0.1% si, 0.3% st
Mem: 524508k всего, 517132k, 7376k бесплатно, 9124k буферы
Обмен: 1048568k всего, 352k использовано, 1048216k бесплатно, 334720k кэшировано

Кот top Информация:

наверх - 23:47:12 до 210 дней, 3:07, 1 пользователь, в среднем нагрузка: 0,02, 0,04, 0,00
Задачи: 63 всего, 1 бег, 62 сна, 0 остановлено, 0 зомби
Cpu (s): 0.2% us, 0.0% sy, 0.0% ni, 99.8% id, 0.1% wa, 0.0% hi, 0.0% si, 0.0% st
Mem: 2097372k всего, 2080888k, 16484k бесплатно, 21464k буферы
Своп: 4194296k всего, 380k использовано, 4193916k бесплатно, 1520912k кэшировано

В Catalina.out нет сообщений об ошибках.

Согласно состоянию сервера Apache, он, кажется, максимизируется на 143 запросов / сек. Я считаю, что серверы могут обрабатывать значительно большую нагрузку, чем они есть, поэтому были бы весьма полезны любые намеки на низкие лимиты по умолчанию или другие причины, по которым эта настройка была бы максимальной.


5
2018-03-26 23:59


Источник


У вас есть БД? Какова нагрузка на БД. Вы отслеживаете сетевой трафик? как насчет сетевых ошибок? Проводили ли вы проверку нагрузки на вашу сеть, приложение, сервер базы данных? Запустили ли вы тест нагрузки приложения через tomcat, а не apache? каковы различия? вы запускаете потоки дампов и сравниваете их и видите, что ждут потоки? вы настроили страницу состояния Apache? - Mircea Vutcovici
База данных не используется. Сетевой трафик идет вверх и вниз, но макс - 1 Мбит / с, 100 к / сек. Мы не видим сетевых ошибок. Состояние Apache включено, с ожиданием 37 потоков, 3 ответа отправки, 25 закрывающего соединения. Я могу запускать JMeter и откачивать еще 300 req / s через систему без проблем, но странная часть статуса сервера Apache не показывает лишний трафик JMeter, поэтому я задаюсь вопросом, правилен ли статус сервера. Похоже, что он может обрабатывать больше трафика, но беспорядочно возвращает 503s, когда все рабочие потоки заняты. - Peter Sankauskas


Ответы:


Решение этой проблемы довольно просто:

добавить в Proxypass:

BalancerMember ajp: //10.176.201.9: 8009 keepalive = On ТТЛ = 60

добавить в Tomcats Server.xml:

Порт разъема = "8009" protocol = "AJP / 1.3" redirectPort = "8443 ConnectionTimeOut = "60000"

После этих изменений все должно работать нормально :-)


7
2018-04-24 07:42





Учитывая, что журнал Apache показывает, что он не может подключиться к Tomcat (из вашего журнала ошибок), похоже, что приложение Tomcat не может идти в ногу с ним.

Когда я работал администратором sys для крупномасштабного веб-сайта Tomcat, я заметил серьезные ограничения производительности, и они не сводились к CPU, а проблемы синхронизации между потоками или задержки при обращении к серверному веб-сервису.

Последнее было огромной проблемой, потому что популярный Java HTTP-интерфейс ограничивает количество одновременных подключений к другому веб-серверу до 2 по умолчанию (когда я обнаружил, что моя челюсть упала). Видеть http://hc.apache.org/httpclient-3.x/threading.html

Ваше веб-приложение вызывает любые другие веб-службы?


1
2018-03-29 22:50





Похоже, что Apache получает таймаут соединения, соединяющийся с серверами в пуле, что приводит к тому, что он не может обслуживать запрос. Ваше значение тайм-аута выглядит ОЧЕНЬ низко, прерывистая сетевая латентность или даже страница, которая требует немного дополнительного времени для создания, может привести к выходу сервера из пула. Я бы попробовал более высокие значения таймаута и повтора, и, возможно, более высокое значение ping.

Вы также можете рассмотреть возможность перехода на работник или мероприятие м / мин, премьера м / мин обычно имеет наихудшую производительность.

Выделенное программное обеспечение прокси / балансировки, такое как кальмар, также может быть хорошим вариантом.


1
2018-03-29 03:57



Переход к рабочему потоку определенно является опцией, но я хотел бы выяснить, какова основная причина 503. - Peter Sankauskas
Глядя на ваш пост более внимательно, похоже, что Apache получает таймаут соединения, подключающийся к серверам в пуле, что приводит к тому, что он не может выполнить запрос. Ваше значение тайм-аута выглядит ОЧЕНЬ низко, прерывистая сетевая латентность или даже страница, которая требует немного дополнительного времени для создания, может привести к выходу сервера из пула. Я бы попробовал более высокие значения таймаута и повтора, и, возможно, более высокое значение ping. Я обновил свой ответ, чтобы содержать эти предложения. - Eric


У вас были случаи блокировки вашего tomcat? Я был свидетелем двух крупных корпоративных (разных компаний) проектов tomcat, страдающих от тупика - один из них был вызван более старой версией используемой сторонней библиотеки.

Можете ли вы подключиться непосредственно к экземпляру tomcat локально? То есть:

telnet localhost 8080

Затем введите:

GET / HTTP/1.0\n
\n

(где \n относится к клавише <enter>).

Если нет, то окажется, что ваш экземпляр tomcat умер или зашел в тупик. Если он зашел в тупик, пришло время получить дамп стека вашего экземпляра tomcat java, используя jstack (с PID программы tomcat java).


0
2018-03-29 10:09



Да, большинство серверов Tomcat отлично работают и делают то, что они предполагают. Мне интересно, есть ли какой-то лимит конфигурации Apache или Debian, который он попал. - Peter Sankauskas


PAS,

Я не видел значение тайм-аута в журнале Apache, который вы вставили. Если это 300, попробуйте изменить его на 1200. У нас была та же проблема и изменение тайм-аута в файле Apache httpd.conf с 300 до 1200 исправлено.


0
2018-03-18 19:44





Я столкнулся с такой же проблемой. Возьмите дамп потока в момент возникновения проблемы, вы узнаете, какой поток блокируется и отныне блокирует другие потоки. Тем временем все порты AJP привыкают, и в конце концов Apache умирает. Но эта проблема не имеет ничего общего с настройками Apache. Проблема находится в приложении (уровень tomcat).


0
2018-03-15 06:06





Давайте ответим на этот вопрос, через 6 лет = D

retry=1 timeout=1 

Это проблема. Тайм-аут а также повторить попытку слишком короткие.

Тайм-аут будет считать серверы мертвыми, если они не ответят в течение 1 секунды. Это слишком мало для обработки некоторых запросов (особенно, если вы выполняете нагрузочное тестирование с частотой 500 req / s).

Обратите внимание, что после того, как сервер опустится, оставшиеся 2 сервера получат + 50% запросов, и их время отклика значительно возрастет, до такой степени, что они, возможно, тоже мгновенно перейдут. Типичный каскадный отказ.

Вы получаете 503 «Service Unavailable», потому что все серверы считаются мертвыми Apache, потому что они не отвечают достаточно быстро при загрузке, потому что ваш тайм-аут слишком короткий.

Удалите обе настройки. Вообще говоря, НИКОГДА не настраивайте тайм-аут менее чем на 5 секунд в любом месте.


0
2018-01-23 13:08