A arte do [JBoss] Tuning 7
<!DOCTYPE html PUBLIC “-//W3C//DTD HTML 4.01 Transitional//EN”>
O trabalho do Profissional JBoss B se inicia com a necessidade de instalação de novas instâncias do servidor de aplicações. Instalar o JBoss é tão simples quanto a descompactação de um arquivo ZIP e não são necessários muitos skills de infra e/ou desenvolvimento para sua realização, salvo uma possível necessidade de disposição das instâncias em clusters, onde o buraco é mais embaixo (sim, embaixo e não em baixo). Instaladas as novas instâncias, é hora de customizá-las à necessidade específica das aplicações que nelas serão executadas. Aqui, o administrador do ambiente precisa conhecer um pouco da arquitetura interna do servidor, baseada no padrão microkernel, seus módulos (mbeans) básicos e seus fluxos de ativação e desativação, para que se deixem habilitados apenas os componentes do servidor fundamentais para sua execução. Vez ou outra, algum trabalho de performance tuning é requerido, geralmente quando se espera alguma sobrecarga de acesso aos aplicativos hospedados no servidor. Farei um post específico sobre este assunto, que é de suma importância.
(…)”
Destaque especial ao termo performance tuning,
que sofre de grande estardalhaço no mercado, e que
será o foco do meu discurso hoje.
Normalmente, os passos seguidos por um cliente em
processo de aquisição de serviços JBoss
são, primeiramente, a instalação e
configuração básica do servidor,
seguida da
monitoração das instâncias com o JON
e a realização de ajustes finos (tuning),
com base nas métricas coletadas, para melhor
utilização dos recursos
disponíveis.
Tunar pra quê?
Existem vários tipos de tuning
e tratar qualquer tipo de ajuste no servidor de
aplicações como performance tuning é
um erro. Como o termo já diz, performance tuning é
um ajuste de performance apenas. Há, entretanto, outros
tipos de ajustes possíveis, que veremos adiante.
O primeiro passo de todos, então, é decidir o
objetivo a
ser alcançado. Até mesmo um playboy,
quando resolver fazer aquele tuning
no seu Chevettão, assim o faz com algum objetivo em mente.
Seja ele o objetivo mais fútil
variado do universo, mas sempre há um objetivo.
Há aqueles que ajustam a máquina para melhor
performance de arrancada, outros que buscam melhor estabilidade para
provas de longa distância e até os que primam
apenas pelo visual patético
exclusivo (esse da foto
até que tá bonito).
No mundo do software também é assim. Antes de tunar,
é mister a definição do
propósito do trabalho. Aliás, qual a
motivação para qualquer demanda de ajuste? Parece
incrível, mas há clientes que buscam turbinar
seus ambientes apenas pelo prazer do mérito. Não
adianta criticar, pois isso se repete a cada modismo de T.I. Resta-nos
administrar. Mas, se me derem a chance, vou perguntar na primeira
oportunidade, “qual o problema que se busca solucionar com um processo
de ajuste fino dos servidores”?
Se não houver problema algum a ser solucionado, o melhor a
fazer é agradecer a oportunidade e sair fora. Se
não há um objetivo pontual, não
haverá também indicadores claros de sucesso do
seu trabalho e você sempre estará coagido a tunar, tunar e tunar,
num ciclo literalmente sem fim. Portanto,
descubra em primeiro lugar se a motivação do tuning é
instalabilidade de serviços, desempenho, consumo excessivo
de mémória ou outros. Cada problema leva a focos
específicos de atuação.
Então, antes de se propor à
execução de performance tuning,
certifique-se de que o problema a ser atacado realmente é
performance, e não outra coisa qualquer. Cada cliente tem
problemas próprios e, naturalmente, necessidades
específicas de tuning.
Às
vezes, o consumo de memória em demasia por não
ser necessariamente um problema para o órgão X,
que conta com 500TB de memória em seus servidores, mas pode
ser o calcanhar de aquiles para outra
instituição, que sofre de carência de
recursos computacionais. Descubra o que aflige seu cliente e ajude-o,
com ou sem tuning.
Tunar o quê?
Por ser um blog relacionado ao ecossistema JBoss, pode-se crer que
só se faz tuning no
aplication
server, o que
também não é fato. Ser
o responsável por um projeto de tuning é
como brincar de médico (no melhor dos sentidos). O paciente
lhe chega dizendo que o pé adormece sempre que anda de
bicicleta e que provavelmente isso se deve a uma queda sofrida quando
ainda criança. Mas aí você, com toda a
sua ‘sabência’, descobre que o paciente sofre de uma leve
protusão no 4o. disco vertebral que lhe pressiona o nervo
ciático bloqueando o fluxo sanguíneo e gerando a
sensação de dormência quando sentado em
superfície irregular por longos períodos. O
cliente
conhecer bem seu problema é ótimo e
necessário. Já o cliente querer conhecer suas
causas, não é nada bom. Em muitas vezes, o
sintoma observado num ponto A pode ter como causa raiz um outro extremo
Z.
Portanto, cuidado com as “dicas”. Elas podem te levar para rumos
divergentes ao núcleo da questão.
Por isso é tão importante extrair do cliente as
razões de negócio pelas quais ele decidiu pelo tuning.
Quando ele diz “preciso de um tuning no
JBoss”, na verdade, ele pode estar querendo dizer “preciso que o
aplicativo N responda mais rápido”, ou ainda “precisamos
evitar que o sistema M caia em seu lançamento”. E, em ambos
os casos, não necessariamente o melhor ganho (falarei de ROI
já já) esteja em ajustes do JBoss, mas na
configuração da rede, no sistema operacional, no
banco de dados ou na própria aplicação
em cheque. Às vezes, uma única linha de
código pode resolver todo o gargalo que tanto incomoda seu
cliente.
Assim, antes de se meter a tunar o
servidor de aplicações JBoss, tenha total
convicção de que realmente é nele que
mora o X da questão. Se o problema não estiver no
JBoss, tuná-lo pra que?
ToC
ToC aqui não é Transtorno
Obcessivo e Compulsivo, mas Theory of Constraints,
ou Teoria
das Restrições,
um princípio de negócios que diz que “toda
organização tem - em um dado momento no tempo -
pelo menos uma restrição que limita a performance
do sistema (a organização em questão)
em relação a seus objetivos.” (Wikipedia).
Na definição dada, troque
“organização” por “JBoss” e teremos a Teoria das
Restriçõe aplicada ao servidor de
aplicações JEE open source
da Red Hat. Melhor ainda, troque “organização”
por “infra-estrutura”:
pelo menos uma restrição que limita a performance do sistema em relação a seus objetivos.”
No dia-a-dia, chamamos essas restrições de
gargalos.
Esses gargalos são os pontos que representam problemas no
uso dos recursos computacionais disponíveis (pra mais ou pra
menos). Na prática então, o que ocorre num
trabalho de tuning é
a busca incessante desses gargalos, a fim de eliminá-los.
Mas, sempre que um gargalo é desfeito, outro é
criado (essa é a teoria), e o desafio é
decidirmos até que ponto essa busca vale a pena.
Diving rescue
Tuning
é uma tarefa
lenta que exige perseverança e disciplina. Há uma
especialidade no mergulho chamada Search Recovery Diver
que ensina técnicas de resgate de objetos desaparecidos
debaixo d’água. Para um desatento, a
localização de objetos submersos é
questão de sorte. No entanto, o curso ensina
várias técnicas de varredura que buscam
potencializar esta sorte. Essas técnicas caracterizam
disciplinas de investigação que lhe garantem que
nenhum metro quadrado da área procurada ficará
sem ser investigado. Desnecessário dizer que
padrões randômicos de busca são de alta
possibilidade de erro e, por conseguinte, amadores e ineficazes.
Num processo de tuning,
mesmo antes de se saber ao certo o ponto exato do tuning,
é preciso estabelecer alguma estratégia de
varredura, que deve ser seguida à risca para que todos os
potenciais pontos de gargalo sejam avaliados. A não
obediência do padrão pré-estabelecido
de pesquisa abre lacunas colaboradoras ao fracasso de todo
esforço empreendido.
ROI
Está na moda, em com razão, IMHO, falar de retorno de investimento. Em tempos de crise global e de margens tão apertadas, qualquer puto gasto deve se provar útil o quão antes possível (não deve ter sido à toa que a Mitsubishi decidiu não mais participar do Paris Dakar, mesmo após 7 títulos consecutivos).
Assim, aplicar recursos em uma consultoria de tuning só
se justifica sobre uma nobre razão (e.g. evitar que o
sistema Y caia em seu lançamento), como discutido nas
seções anteriores. E, mesmo sob a
existência explícita desta justificativa, dentro
do processo de tuning em
si, é essencial a busca incessante do menor
esforço que gerará o maior benefício (Pareto).
Em primeira instância, deve-se avaliar a curva de
custo/benefício da contratação. Por
exemplo, se o problema relatado pelo cliente é “o servidor
cai por OutOfMemoryError sempre que o sistema atinge 400
usuários simultâneos”, pode sair mais barata a
aquisição de mais pentes de memória do
que a execução de um processo de tuning para
investigação de memory leaks
na aplicação ou o reajsute de
parâmetros de inicialização do servidor.
Num segundo momento, já imerso no ciclo de tuning,
o responsável pela atividade deve sempre buscar o ponto de
ajuste que trará mais resultado visível ao olhos
do cliente (é a estória
da martela certeira).
Pode ser então que uma
mega-complexa-configuração no app server
resolva determinado problema mas, uma alternativa no
nível de SO, muito mais simples de ser executada, e que
também atenderá a demanda, é bem mais
preferível.
Mas às vezes, o cliente diz assim “Não se
preocupe com o resto da infra. Tuna
ao máximo o JBoss e depois a gente vê o resto.”.
Isso é uma punhalada. Há a possibilidade de se
gastar meses em investigação e ajustes malucos no
servidor que poderiam ser facilmente resolvidos com um refactoring
da aplicação ou um micro-tuning
no banco, por exemplo. É como te pedirem pra manter o
chão de uma sala enxuto com uma flanela sem te deixarem
fechar a torneira da pia que está transbordando de
água. Pra evitar que isso ocorra, be nice.
E, por fim, sob a luz da Teoria das Restrições, a
busca por gargalos (restrições) é um
processo infinito (pois eles sempre existirão) e, decidir o
ponto exato de parada está totalmente relacionado com o
retorno do investimento aplicado até então (o
custo de eliminar o próximo grande gargalo é
menor que benefício obtido por sua
eliminação?).
Being nice
Nenhum administrador de infra-estrutura sente-se confortável
com pitacos de instrusos em seu ambiente. Então,
é natural que a chegada de uma consultoria externa
responsável por “resolver a parada” seja, a
princípio, mal recebida, por várias
razões. Se você, consultor externo, foi contratado
para resolução do problema, provavelmente
é porque a equipe interna não o resolveu por si
só. Daí, qualquer sucesso da sua parte
será a ratificação da
incompetência do time local. Se você, consultor
externo, concluir que ajustes no nível de rede, SO, banco ou
aplicação é menos oneroso que ajustes
no servidor de aplicações, você
não apenas estará registrando em pedra o fracasso
do pessoal da casa na resolução do
problema, como também estará indiretamente
questionando sua incompetência na
execução de seus trabalhos de rotina, como a
configuração do SO. E assim segue.
Veja então que, no papel de consultoria externa tida como a
salvação da pátria, qualquer passo em
falso pode desencadear conflitos capazes de inviabilizar
todo o trabalho.
Não se esqueça que quem detém os
acessos a todos os elementos da infra-estrutura são os
membros do time local do cliente. Indispor-se de alguma forma com essa
galera é fechar várias portas fundamentais para
implementação de sua estratégia de
investigação.
A única dica a se dar neste ponto é: seja legal.
Acho que não existam técnicas formais para se ter
sucesso nessas ocasiões. Tem muito a ver com soft skills desenvolvidos
pelo próprio profissional ao longo de sua
história e com seu bom senso. Parece óbvio, mas
é hiper comum vermos profissionais nesta
posição de consultoria externa apresentarem-se
com extrema arrogância é
pré-potência. Geralmente, são os malditos
famosos homens
de preto. É claro que
um cara desses será mal recebido e todas as barreiras
possíveis e imagináveis ao sucesso de seu
trabalho serão criadas pelo pessoal da infra local. A
filosofia ágil ataca um pouco este problema quando defende a
integração mais próxima
possível com o cliente. De fato, é seu dever
apresentar-se à equipe do cliente como parceiro, e
não concorrente. Se o seu problema não for o
problema dele e o problema dele não for o seu, do fundo do
coração, lascou. Se não for do fundo
do coração, será caracterizada a
falsidade. Aí é problema seu. Eu avisei que tinha
que ser de coração.
A multicasionalidade
Em uma missão de tuning, o mesmo raciocínio da aviação é válido. O problema de latência da aplicação relatado pelo cliente não necessariamente é de responsabilidade única da aplicação, ou do servidor, ou da rede, mas é responsabilidade conjunta de todos eles. Ora, tudo bem que a aplicação consuma grandes quantidades de memória, desde que o servidor tenha memória superestimada. Tudo bem que o tamanho das sessões de usuários sejam da ordem de gigabytes, desde que a rede que interconecte os nodos do cluster seja de terabits. Tudo bem que qualquer elemento da infra apresente problemas, desde que haja outro que os compense. Cada elemento deficitário contribui para o problema final observado pelo usuário, mas não necessariamente carrega a culpa exclusiva. O que não pode ocorrer é a combinação desses fatores deficientes, como uma aplicação gulosa de memória rodando sobre um servidor com recursos escassos numa rede com banda limitada. Aí não há santo que dê jeito.
Assim, sempre sob a luz do ROI, é essencial conhecer quais fatores cujo alinhamento contribuem para o problema em questão, para que só então se tome a decisão certa sobre o próximo passo do tuning, de preferência, a que apresentar o melhor custo/benefício. Esse papo de ROI é tão importante que, às vezes, comprar mais memória ou substituir o barramento de rede pode ser mais barato que a execução do tuning. Novamente, é a análise do custo/benefício com Pareto.
Escopo
Na era industrial da computação, chamada por
nós da SEA como a velha escola
do pensamento de TI, ou a TI 1.0,
havia o lema de que cada profissional possuía uma e apenas
uma
especialidade (vide tradicionais processos em cascata). Neste
raciocínio, então, você como profissional
JBoss seria
responsável apenas
por ajustes no app server, alienando-se
dos demais elementos compositores de sua infra-estrutura (rede, SO,
app…). Tecnicamente, pode até ser interessante para
você, profissional auto-definido por
consultor-intergalático com cabeça old-school.
Afinal, é menos coisa para se preocupar. Mas, negocialmente
falando, é a maior irresponsabilidade que se pode fazer.
Ora, quem efetivamente está preocupado com o sucesso de um
negócio está, naturalmente, interessado a se
envolver em todas as suas instâncias.
Equipes 1.0 concorrem entre si. Equipes 2.0 colaboram entre si. No
mundo 1.0, todos querem tirar os seus da reta. Por isso há
tantos documentos, tantas assinaturas e
tantas evidências geradas. Tudo para que eu possa
comprovar que, em caso de merda, a culpa não foi minha. O
principal sintoma desse modelo são os profissionais que
lavam suas mãos ao afirmarem não ser deles o
problema. Já no mundo 2.0, em contraponto, não
existe problema seu ou meu. Os problemas são sempre nossos.
Por isso, todos se responsabilizam por igual para o bom andamento do
negócio. Por mais que eu, como DBA, possa ter certeza quase
absoluta de que o principal gargalo não esteja no banco, eu
visto as sandálias da humildade, desço do
pedestal dos deuses e vou a campo me sujar com o restante do time,
ajundando o máximo que puder, da forma que puder.
Assim, num processo de tuning, não
existe o cara do banco, o cara do JBoss e o desenvolvedor da
aplicação, mas sim a equipe
responsável por resolver o problema em pauta, seja ele qual
for. Neste modelo, ao invés de ficar cada um no seu
quadrado, todos circulam além das fronteiras de sua
especialidade, abraçando a mesma causa e colaborando um com
ou outro para o sucesso global da iniciativa.
Tem a ver com a famosa estória da galinha e do porco contada
pela literatura do Scrum. No modelo 1.0, você é
responsável pela sua especialidade e apenas se envolve
com as outras, sem exercer por elas qualquer
relação de responsabilidade. Já no
2.0, você se compromete
com todo o escopo de atividades do tuning,
independente do seu papel principal. Queremos compormetimento, e
não apenas envolvimento.
Em caso de haver qualquer limite no escopo de
atuação da equipe de tuning,
que seja então uma limitação
política ou corporativa, mas não
limitações por ego ou orgulho gerados pela
especialização profissional.
Tuning não se compra, se faz
Não existe receita de bolo para tuning. Se
existisse, todo servidor JBoss já viria tunado
de fábrica.
Já disse que numa missão de tuning
deve-se buscar sempre os pontos de ajustes com maior ROI e que todos os
responsáveis pela infra-estrutura em
produção devem estar igualmente comprometidos com
o trabalho. Entretanto, há de se fazer ordem neste processo.
Apesar do comprometimento de representantes de todas as camadas da
infra, é necessário entrar em acordo sobre a
estratégia de evolução do processo.
No próximo post vou falar do ciclo de
instrumentalização,
execução, monitoramento e ajustes que se repete
dentro da estratégia pré-estabelecida. Em
especial, vou tratar das ferramentas utilizadas neste ciclo para
diagnóstico de gargalos e prognóstico de
soluções.
Keep
in touch, Keep walkin’, Drop a comment.
[]s
Parabéns pelo post Alê.
Muito bem detalhado. Ótima referência no assunto.
Minha impressão final foi:
“Se você criou a aplicação é seu dever tentar resolver os gargalos. Para isso é necessário passar pelo sofrimento de conhecer a fundo a ferramenta que você está utilizando”.
Abraço
Isso Luiz.
E uma coisa que esqueci de deixar claro é que, em qualquer ocasião, tuning é pensado após o desenvolvimento, e não durante. É como refactoring no XP. Você faz, vê funcionando e só então refatora. Iniciar o desenvolvimento do aplicativo ou a instalação do servidor já pensando em tuning pode colocar num ciclo infinito e nunca ter o trabalho feito.
valeu!
Muito bom o post!!!
Realmente é uma visão 2.0 de todo o processo de administração e tuning de servidores de aplicação.
Como vc mesmo diz: “Seja 2.0!”
Falou!
Mas o tunning que é bom nada…
@Fabio, se é de tuning (com um N apenas) que precisa, nosso deartamento comercial está ao seu dispor ;-)
Lá estava eu a procura de um bom artigo para “TUNAR” nosso servidor de aplicativos e caio neste post.
Resultado: Nada de tunar o JBoss, aumentamos a ram do server, passamos a rede toda para Gigabit e boomm… problema resolvido. E eu querendo tunar com um ‘N’ o menino JayBoss.
Excelente post.
Abraços.
Além do post estar muito bom, as respostas estão excelentes… Hehehe…
Vlw Alê, mandou muito bem mais uma vez!