Estou fazendo um ajuste em nossos servidores de produção para um portal, temos 4 servidores, 2 para web e 2 para app, e existe um firewall antes e depois dos servidores web (então sim, existe um firewall entre aplicativos e servidores web) o problema aqui comecei com a eliminação de conexões ociosas entre servidores de aplicativos e servidores web por firewall, tentei com várias soluções e agora parecia que o problema mudou de conexões quebradas travadas que estavam no aplicativo porque caiu do firewall, esse problema acontecia quando tenho carga baixa para portal, e para resolvê-lo preciso reiniciar todos os servidores de aplicativos, agora tenho problemas com dias de alta carga, e a solução urgente foi simplesmente reiniciar rapidamente os servidores web Apache, como resolver esse problema.
Fiz alterações ajudando o gerador de configuração de balanceamento de carga 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
E monitorando conexões em ambos os servidores usando o comando netstat e com a visão geral em tempo real do Google Analytics, obtive as seguintes estatísticas com cerca de 40 visitantes após 3 dias da última reinicialização:
Lado da web(2 servidores mas as conexões dela "para cada" não são totais):
ESTABLISHED ~700 - 750
TIME_WAIT: 100-200 (big jumbs for one second 150 another 200 another 170 and then 120 and so)
Lado do aplicativo(aqui contei todas as conexões, a maioria delas ESTABLISHED e poucas CLOSE_WAIT 0 - 5 cada vez que verifico):
S1 (4 instances running) : 900-950
S2 (5 instances running) : 1000-1100
Detalhes dos servidores:
- Em servidores web 2x: Apache 2.2.14/mod_jk 1.2.37
- em servidores de aplicativos 2x: Clustered Glassfish 2.1.1 com ajp13 (6 instâncias/cada servidor)
- Todos os servidores Solaris SPARC 64 V-CPUs 32GB de RAM.
Minhas configurações: Principalmente como o gerador me deu (você pode ver o link):
httpd.conf:
KeepAlive On
ServerLimit 12800
StartServers 5
MinSpareServers 5
MaxSpareServers 20
MaxClients 12800
MaxRequestsPerChild 5000
ExtendedStatus Off
trabalhador.propriedades:
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
Do lado do peixe-vidroatinge o tempo limite de 10 segundos do lado da configuração do cluster, tenho:
Propriedade do serviço HTTP:
- connectionTimeout = 10000
Processamento de solicitação:
- Contagem de tópicos: 2133
- Contagem inicial de threads: 20
- Incremento de thread: 10
Manter vivo (habilitado):
- Contagem de fios: 400
- Máximo de conexões 256
- Tempo limite: 10 segundos
Conjunto de conexões:
- Máximo de contagem pendente de 4.096 conexões
Então:
- Então minhas configurações estão corretas?
- Como resolver um grande número de conexões estabelecidas ou é seguro? Não quero tempo de inatividade novamente para o apache se tiver carga alta novamente.
Responder1
em relação ao mod_jk / mod_ajp: usamos esta configuração um pouco maior e nos deparamos com bugs e erros de vez em quando, conexões caindo, mas nunca encontramos uma solução real para nenhum dos nossos problemas (mas encontramos alguns bugs, que ainda existem)
meu conselho: faça uma configuração alternativa e testes de desempenho: mod_jk vs proxy_http e se proxy_http estiver dentro dos intervalos aceitáveis, pule mod_jk. eu fiz isso em 2 configurações diferentes agora (e, além disso, sou capaz de substituir o apache pelo nginx -> BIG WIN) e não me arrependo.
prós
- mais fácil de depurar
- mais variedade de possíveis gateways lb/frontend (haproxy, nginx, verniz)
- menos heisenbugs
contras
- não encontrei alguns