Просмотрите конфигурацию AJP между Apache и Jboss, как описано в https://developer.jboss.org/wiki/OptimalModjk12Configuration
Проблема
JBoss Web (Tomcat) server.xml Фрагмент AJP:
<Connector port="8009" address="${jboss.bind.address}" protocol="AJP/1.3"
emptySessionPath="true" enableLookups="false" redirectPort="8443" ></Connector> Apache's httpd.conf:
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
ServerLimit 256
MaxClients 256
MaxRequestsPerChild 4000
</IfModule>
Приведенная выше конфигурация под нагрузкой может привести к очень медленной работе mod_jk
и не отвечает, вызывает ошибки http и вызывает полузакрытие
соединения. Эти проблемы могут возникнуть, потому что нет
тайм-ауты подключения, указанные для поддержки потерянных соединений, нет
свойства обработки ошибок, определенные в worker.properties, и нет
пределы подключения, установленные в Apache и Tomcat.
Но это большое количество потоков может быть из другого источника. Как описано здесь :
самый распространенный сценарий зависания Socket.read () - высокий
время обработки или нездоровое состояние вашего удаленного поставщика услуг.
Это означает, что вам нужно будет связаться с поставщиком услуг
Команда поддержки сразу, чтобы подтвердить, если они сталкиваются с некоторыми
условие замедления в их системе.
Ваш сервер приложений Потоки должны быть освобождены после удаленного
проблема системы поставщика услуг решена, но довольно часто вы будете
необходимо перезагрузить экземпляры сервера (Java VM), чтобы очистить все
висящие нитки; особенно если вам не хватает надлежащего времени ожидания
осуществление.
Другие, менее распространенные причины:
- Огромные данные отклика, приводящие к увеличению истекшего времени чтения / потребления Socket Inputstream, например такие как очень большие данные XML. Это может быть
легко проверить, проанализировав размер данных ответа
- Задержка в сети, приводящая к увеличению прошедшего времени при передаче данных от поставщика услуг в вашу производственную систему Java EE. Это может
Докажите, запустив какой-то сетевой анализатор между вашими производственными
сервер и провайдер услуг и определить любую большую задержку / задержку
проблема
Какова бы ни была ваша проблема, первое, что нужно сделать, это просмотреть конфигурацию тайм-аута!
Что вы можете сделать?
Вам необходимо выполнить некоторые настройки для Jboss и Apache.
Сторона JBoss
Основная проблема с server.xml - это настройка connectionTimeout
который устанавливает SO_TIMEOUT основного сокета. Поэтому, когда соединение в
У Tomcat не было запроса в течение времени, указанного
connectionTimeout, затем соединение отключается. Это необходимо
потому что, если соединение не использовалось в течение определенного периода
время, когда есть шанс, что он наполовину близок к концу mod_jk.
Если соединение не закрыто, будет раздувание потоков
который со временем может достигнуть максимального значения в Tomcat, то Tomcat будет
не сможет принимать какие-либо новые подключения. Время соединения
600000 (10 минут) - хорошее число для начала. Может быть
ситуация, когда соединения не перерабатываются достаточно быстро,
в этом случае connectionTimeout может быть уменьшен до 60000 или 1
минут.
При установке connectionTimeout в Tomcat, mod_jk также должен иметь
connect_timeout / prepost_timeout set, который позволяет обнаружить, что
Соединение Tomcat было закрыто, и запрос на повторную попытку запрещен.
Рекомендуемое значение maxThreads составляет 200 на процессор, поэтому здесь мы предполагаем
Сервер - одноядерный компьютер. Если это был четырехъядерный процессор, мы
может увеличить это значение до 800 и более в зависимости от ОЗУ и других
характеристики машины.
<Connector port="8009"
address="${jboss.bind.address}"
emptySessionPath="true"
enableLookups="false"
redirectPort="8443"
protocol="AJP/1.3"
maxThreads="200"
connectionTimeout="600000"></Connector>
сторона Apache
файл worker.properties
См. Встроенные комментарии.
worker.list=loadbalancer,status
worker.template.port=8009
worker.template.type=ajp13
worker.template.lbfactor=1
#ping_timeout was introduced in 1.2.27
worker.template.ping_timeout=1000
#ping_mode was introduced in 1.2.27, if not
#using 1.2.27 please specify connect_timeout=10000
#and prepost_timeout=10000 as an alternative
worker.template.ping_mode=A
worker.template.socket_timeout=10
#It is not necessary to specify connection_pool_timeout if you are running the worker mpm
worker.template.connection_pool_timeout=600
#Referencing the template worker properties makes the workers.properties shorter and more concise
worker.node1.reference=worker.template
worker.node1.host=192.168.1.2
worker.node2.reference=worker.template
worker.node2.host=192.168.1.3
worker.loadbalancer.type=lb
worker.loadbalancer.balance_workers=node1,node2
worker.loadbalancer.sticky_session=True
worker.status.type=status
Ключевыми моментами в вышеприведенных работниках. Свойства являются то, что мы добавили ограничения
для соединений mod_jk делает. С базовой конфигурацией, розетка
время ожидания по умолчанию бесконечно. Другие важные свойства
ping_mode и ping_timeout, которые обрабатывают зондирование соединения дляошибки и connection_pool_timeout, которые должны быть равны
connectionTimeout server.xml при использовании prefork mpm. Когда эти
два значения одинаковы, после того как соединение было неактивно для х
количество времени, соединение в mod_jk и Tomcat будет закрыто в
в то же время, предотвращая полузакрытое соединение.
Конфигурация Apache
Обратите внимание, что maxThreads для соединения AJP должно совпадать с
MaxClients, установленный в httpd.conf Apache. MaxClients должен быть установлен
в правильном модуле в Apache.
Это можно определить, запустив httpd -V:
# httpd -V
Server version: Apache/2.2.3
Server built: Sep 11 2006 09:43:05
Server's Module Magic Number: 20051115:3
Server loaded: APR 1.2.7, APR-Util 1.2.8
Compiled using: APR 1.2.7, APR-Util 1.2.7
Architecture: 32-bit
Server MPM: Prefork
threaded: no
forked: yes (variable process count)
Server compiled with....
-D APACHE_MPM_DIR="server/mpm/prefork"
-D APR_HAS_SENDFILE
-D APR_HAS_MMAP
-D APR_HAVE_IPV6 (IPv4-mapped addresses enabled)
-D APR_USE_SYSVSEM_SERIALIZE
-D APR_USE_PTHREAD_SERIALIZE
-D SINGLE_LISTEN_UNSERIALIZED_ACCEPT
-D APR_HAS_OTHER_CHILD
-D AP_HAVE_RELIABLE_PIPED_LOGS
-D DYNAMIC_MODULE_LIMIT=128
-D HTTPD_ROOT="/etc/httpd"
-D SUEXEC_BIN="/usr/sbin/suexec"
-D DEFAULT_PIDLOG="logs/httpd.pid"
-D DEFAULT_SCOREBOARD="logs/apache_runtime_status"
-D DEFAULT_LOCKFILE="logs/accept.lock"
-D DEFAULT_ERRORLOG="logs/error_log"
-D AP_TYPES_CONFIG_FILE="conf/mime.types"
-D SERVER_CONFIG_FILE="conf/httpd.conf"
Что говорит мне, что MPM на сервере - это Prefork. Это не всегда 100%
точный, поэтому вы также должны просмотреть вывод / etc / sysconfig / httpd
посмотрите, есть ли следующая строка: HTTPD = / usr / sbin / httpd.worker. Если
это закомментировано, вы запускаете prefork, иначе, если не закомментировано
работник.
httpd.conf:
<IfModule prefork.c>
StartServers 8
MinSpareServers 5
MaxSpareServers 20
MaxClients 200
MaxRequestsPerChild 0
</IfModule>
Или, если Apache использует рабочий, это
<IfModule worker.c>
StartServers 2
MaxClients 200
MinSpareThreads 25
MaxSpareThreads 75
ThreadsPerChild 25
MaxRequestsPerChild 0
</IfModule>
MaxRequestsPerChild равно 0, это рекомендуемое значение при использовании
mod_jk as mod_jk сохраняет открытые постоянные соединения. Ключевые значения в
вышеуказанной конфигурацией являются MaxClients и MaxRequestsPerChild,
остальные значения остаются по умолчанию. Обратите внимание, что MaxRequestsPerChild
Рекомендуется быть 0, однако значение может быть больше 0
в зависимости от того, используется ли Apache и для других модулей, особенно в
случай утечки ресурса.
В ссылке вы можете найти другую конфигурацию, чтобы еще больше оптимизировать этот сценарий.