sexta-feira, 11 de janeiro de 2008

2006, GNU/Linux, Java e o TCC [Cluster Linux] parte 004

Enquanto eu não conseguia verba para comprar componentes e dispor de mais máquinas para exigir o máximo do cluster, comecei a desenvolver um centro de controle parar realização dos testes, o console, ele seria o responsável por controlar as máquinas clientes, fazendo com que elas iniciassem uma sessão de teste ao mesmo tempo, procurando obter resultados mais precisos possíveis para um intervalo de tempo, pois disparar cada clientes "a mão", mesmo que eu tivesse três braços para iniciar e parar três clientes, ainda assim acredito que alguns centésimos de segundos teria de diferença entre um teste e outro, o que ocasionaria diferenças de resultado que eu estava disposto a eliminar.
Tudo parecia estar indo bem, já conseguia comandar os clientes através do console e neles eu apreciava em tempo real os tempos de resposta e o número de requisições atendidas por segundo. Mas como se sofre quando não se conhece os detalhes "ocultos" das tecnologias com que se trabalha, foi justamente o que ocorreu, quando eu não consegui colocar o cluster em carga máxima, ou seja, fazê-lo usar 100%, ou perto disto, da CPU, tua parecia bem, mas quando comecei a conseguir manter o uso de CPU em 100%, ocorria um efeito trágico, do nada, o cluster parava de responder e ficava um longo período sem processar nada. Isto era o fim! Tinha chegado num ponto em que não tinha a mínima idéia do que poderia estar acontecendo, a não ser por um pequeno detalhe que eu havia percebido, assim que eu terminei a aplicação web, reparava no gerenciador do tomcat, que a cada requisição que eu fazia à aplicação, uma nova sessão era criada. Minha primeira tentativa de contornar o problema foi diminuir ao máximo o tempo de timeout da sessão, coloquei 1 minuto, que era o mínimo permitido, mas mesmo assim, com este tempo, não era possível evitar que o cluster "travasse" em determinado momento de muita carga. Insisti que poderia modificar, então, alguma coisa na aplicação web para que ela não iniciasse uma nova sessão a cada requisição, mas minhas tentativas foram em vão e eu estava certo que era pelo número acumulado de sessões abertas, pois consegui visualizar que quando chegava a um determinado número de sessões abertas era que o cluster travava. Não lembro como consegui chegar à solução, mas foi algo bem diferente do que eu pensava ser a solução, lembro que foi alguma coisa relacionada a configuração da máquina virtual, como incluir o parâmetro "-server" e algumas diretivas para garbage collector operar em paralelo. Simplesmente o cluster passou a voar, consegui resolver o problema e de quebra ele processava muito mais requisições por segundo.
Passada a grande frustação e o êxtase da solução, ainda pairava em mim uma desconfiança de que ainda não tinha chegado ao fim os problemas que pareciam "insolucionáveis", mas para minha grata surpresa, não lembro de ter passado por outro momento de tanta dificuldade quanto este.

2 comentários:

Anônimo disse...

Seu blog é interessante, mas seu estilo de escrever é muito confuso.
Tente construir frases curtas, utilize mais o ponto final.
Você deveria ter utilizado o projeto Sequoia para fazer o load balance e fail over na camada de banco de dados. (opera com qualquer banco)
Ou Oracle com RAC.

biande disse...

Obrigado pela crítica Anônimo. Vou tentar mudar meu estilo e procurar tentar não fazer frases muito longas. Cheguei a pesquisar sobre o projeto Sequoia, o problema é que ele é usado para projetos Java pelo que me lembro. A questão é que queria um sistema de permitisse replicação para alta disponibilidade que fosse independente de plataforma de projeto e SGBDR, por isto também não parti para Oracle com RAC.
Ainda vou continuar a relatar sobre a saga e espero escrever melhor das próximas vezes.
Abraços