☰

Apache с mod_jk с экземплярами Glassfish, большое количество установленных соединений для небольшого количества пользователей

tag-icon • tag-icon apache-2.2 load-balancing cluster glassfish mod-jk
Apache с mod_jk с экземплярами Glassfish, большое количество установленных соединений для небольшого количества пользователей

Я настраиваю наши производственные серверы для портала. У нас 4 сервера: 2 для веб-сервера и 2 для приложений. Перед и после веб-серверов есть брандмауэр (да, между серверами приложений и веб-серверами есть брандмауэр). Проблема началась с того, что брандмауэр сбрасывал неиспользуемые соединения между серверами приложений и веб-серверами. Я перепробовал множество решений, и теперь, похоже, проблема перешла из-за зависших разорванных соединений в приложении из-за сброса из-за брандмауэра. Эта проблема возникала, когда у меня была низкая нагрузка на портал, и для ее решения мне нужно было перезапустить все серверы приложений. Теперь у меня проблема с днями высокой нагрузки. И срочным решением был простой быстрый перезапуск веб-серверов Apache. Как решить эту проблему?

Я внес изменения с помощью генератора конфигурации балансировки нагрузки Jboss:http://lbconfig.appspot.com/?lb=mod_jk&mjv=1.2.28&nca=64&ncj=64&nai=2&nji=2&njips=6&f=true&c=false&lr=false&lrl=&mpm=Prefork

И отслеживая соединения на обоих серверах с помощью команды netstat и обзора Google Analytics в реальном времени, я получил следующую статистику с примерно 40 посетителями после 3 дней последнего перезапуска:

Веб-сторона(2 сервера, но подключений к ним «для каждого» не общее):

ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)

Сторона приложения(здесь я подсчитал все соединения, большинство из них ESTABLISHED и несколько CLOSE_WAIT 0 - 5 при каждой проверке):

S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100

Подробности сервера:

  • На серверах web 2x: Apache 2.2.14 / mod_jk 1.2.37
  • на серверах app 2x: кластеризованный Glassfish 2.1.1 с ajp13 (6 экземпляров / на каждом сервере)
  • Все серверы Solaris SPARC 64 V-CPUs 32 ГБ ОЗУ.

Мои конфигурации: В основном как мне дал генератор (можно посмотреть ссылку):

httpd.conf:

KeepAlive On
ServerLimit         12800
StartServers        5
MinSpareServers     5
MaxSpareServers     20
MaxClients          12800
MaxRequestsPerChild 5000

ExtendedStatus Off

свойства работника:

worker.maintain=30
worker.template.type=ajp13
worker.template.session_cookie=JSESSIONID
worker.template.lbfactor=1
worker.template.ping_timeout=10000
worker.template.connection_pool_timeout=10
worker.template.socket_keepalive=True
worker.template.socket_timeout=600
worker.template.connect_timeout=10000
worker.template.prepost_timeout=10000
worker.template.connection_ping_interval=20
worker.template.ping_mode=A
worker.template.socket_connect_timeout=600000

Со стороны стеклянной рыбытайм-ауты 10 секунд со стороны конфигурации кластера, у меня:

Свойство HTTP-сервиса:

  • Время ожидания соединения = 10000

Обработка запроса:

  • Количество тем: 2133
  • Начальное количество тем: 20
  • Приращение потока: 10

Поддержание активности (включено):

  • Количество тем: 400
  • Макс. количество подключений 256
  • Время ожидания: 10 секунд

Пул соединений:

  • Максимальное количество ожидающих соединений: 4096

Так:

  • Так верны ли мои конфигурации?
  • Как решить проблему большого количества установленных соединений или это безопасно? Я не хочу снова останавливать Apache, если снова возникнет высокая нагрузка.

решение1

относительно mod_jk / mod_ajp: мы использовали эту немного более мощную установку и время от времени сталкивались с ошибками и багами, соединения обрывались, но так и не нашли реального решения ни одной из наших проблем (но мы нашли несколько багов, которые все еще существуют)

мой совет: сделайте альтернативную настройку и тесты производительности: mod_jk против proxy_http, и если proxy_http находится в приемлемых пределах, пропустите mod_jk. Я сделал это в двух разных настройках (и, кроме того, могу заменить Apache на nginx -> BIG WIN) и не жалею об этом.

плюсы

  • легче отлаживать
  • больше разнообразия возможных шлюзов lb/frontend (haproxy, nginx, Varnish)
  • меньше гейзенбагов

минусы

  • не нашел некоторые

Связанный контент