Relatório Técnico sobre Manutenção e Performance do Servidor de Produção do Projeto PADCT

 

Antônio Mário Franklin Guerrera, José Fernando Tepedino Martins, Pedro Alves Bezerra Júnior

  Recife, 29 de Outubro de 1997

 

Apresentação

  

Este relatório tem como objetivo apresentar uma descrição das medidas tomadas com o servidor IBM RS/6000, sistema operacional AIX 4.1.4, pertencente ao projeto ReAACT do Programa de Apoio ao Desenvolvimento Científico e Tecnológico (PADCT) do Ministério da Ciência e Tecnologia, no que se refere à avaliação do desempenho da referida máquina. Este projeto envolve, entre outras aplicações, a implementação de um sistema de informações na Web para cadastramento de pesquisadores.

 

Características do servidor:

 

 

O acompanhamento do servidor foi necessário dada a natureza de sua utilização no projeto, e que pode ser considerado uma aplicação de missão crítica: atender os pedidos de vários p ontos do país via Internet, gerando uma sobrecarga considerável para a máquina.

 

A seguir são apresentados alguns tópicos levados em consideração durante todo o acompanhamento e suas descrições. Ocorreram modificações constantes no sistema para atender aos requ isitos do cliente (PADCT) e dos usuários.

 

1. Tamanho do área de swap

 

Dada a nossa experiência em administração de sistemas Unix, sabe-se que o tamanho da área de paginação deve ser, no mínimo, o dobro da área de memória RAM. Como a aplica& ccedil;ão em estudo requer um trabalho maior da máquina, já que se trata de um gerenciador de banco de dados com centenas de acessos, esse mínimo recomendado passa a ser de três vezes. Entretanto, um aspecto importante a ser considerado neste caso específico é que a área de memória RAM é de 512 Mbytes, número bastante significativo para qualquer aplicação, mesmo do porte da que está em desenvolvimento. As an&a acute;lises feitas com ferramentas de monitoração indicaram que a área de swap não estava sendo utilizada com freqüência, o que indica que o tamanho da memória RAM foi suficiente. Nenhuma medida foi tom ada.

 

Ponto a ser considerado: Qual a relação entre memória RAM e área de swap, ou seja, a que razão a área de swap deve aumentar se a memória RAM também aumentar?

 

2. Monitoramento constante

 

Através de ferramentas como:

 

 

efetuou-se um acompanhamento no processamento do servidor. Através dessas ferramentas pode-se observar, principalmente nos momentos críticos, quantos, há quanto tempo e quais processos estavam sendo executados, quan to de memória estava sendo utilizada, a atividade da CPU, etc. A partir dos dados analisados é que foram tomadas as medidas apresentadas neste relatório. Alguns scripts também foram desenvolvidos com o objetivo de contabilizar dados como número de conexões, número de processos, etc. Esses scripts, todavia, precisam ser refinados para que apenas as informações realmente úteis sejam filtradas. Os logs do servidor Web e do banco de dados t ambém foram analisados com o objetivo de análise de possíveis problemas. A partir dos dados coletados, as seguintes ocorrências, entre outras, puderam ser detectadas:

 

 

3. Separação do ambiente de produção e desenvolvimento

 

Sabe-se do risco inerente no compartilhamento de recursos entre produção e desenvolvimento, já que qualquer falha provocada por programas ainda não homologados para uso dos usuários pode por em ris co o andamento de qualquer projeto. Além disso, processos em estado de espera indefinida e inconsistências criadas pelos programas ainda em desenvolvimento, compartilhamento de recursos como memória, disco e CPU significam um aumento d e sobrecarga que precisa ser suportado pelo ambiente de produção. Devido ao exposto, o ambiente de desenvolvimento foi migrado para uma outra máquina com os mesmos recursos da primeira, liberando tais recursos apenas para os usu&aacut e;rios de produção e diminuindo para zero o risco citado no início deste tópico. Percebeu-se que houve uma significativa melhora na performance após essa separação.

 

4. Realocação dos logs do banco de dados e do servidor Web

 

Com a existência de dois discos rígidos no servidor, chegou-se à conclusão de que os logs dos processos citados poderiam ser gravados em um disco distinto daquele no qual o banco, por exemplo, está mantendo os dados do sistema. O objetivo desta solução foi também o aumento de performance, pois com a existência de dois discos, a probabilidade de espera para escrita/leitura em disco tenderia a diminuir já que as leitu ras e escritas podem ocorrer em paralelo nesse caso. Essa solução foi um caso muito particular considerado, mas que com certeza pode ser estendida para outros módulos como os sistemas de arquivos do servidor, que podem ser divididos e ntre os diversos discos.

 

5. Reboots

 

Vários reboots foram executados no servidor, principalmente durante o período de compartilhamento de ambiente entre produção e desenvolvimento. O objetivo era dar um "refresh" na máquina a fim de e ncerrar possíveis conexões TCP/IP sem utilização e processos que estivessem consumindo recursos exageradamente, mas sem uma correta execução. O fato é que, num dado momento, essa iniciativa não foi m ais um boa solução, já que constatou-se que antes e depois de um determinado reboot efetuado o número de processos e conexões permaneceu quase que o mesmo. Não se descarta, entretanto, que reboots com uma periodic idade mais ou menos elevada possa ter seus benefícios para o sistema, desde que sejam planejados e efetuados obedecendo a ordem correta de desligamento da máquina: shutdown do banco de dados, shutdown de outros servidores do sistema e shutdo wn da própria máquina.

 

6. Reconfiguração de alguns deamons

 

A principal modificação no caso do servidor web foi o número de clientes atendidos pelo deamon e o aumento do time out. Essa última medida também foi tomada no caso do servidores de ftp e ht tp.

 

7. Aumento do número de processos do AIX, por usuário

 

Como os acessos ao web server e ao banco de dados são feitos apenas pelos usuários nobody e wgsuser, respectivamente, o número default de processos permitidos por usuário não estava a tendendo às necessidades. Pelo menos foi o que se achou. Como não se sabia quais as conseqüências imediatas de um aumento substancial nesse número, a idéia foi efetuar esse aumento de forma parcial e gradativa: o n&u acute;mero inicial configurado pelo sistema operacional foi de 40 processos. Na primeira modificação esse número passou para 60 e, finalmente, para 80. Após essas mudanças, houve uma significativa melhora no acesso ao si stema: o número de erros devido a time out diminuiu sensivelmente. Outra melhora observada deu-se com relação ao servidor Apache. Seu log de erros apresentava, ocasionalmente, a seguinte mensagem: "could not spawn process", apesar de ter sido configurado para atender a um grande número de conexões. Esse problema desapareceu com o aumento do no. de processos por usuário.

 

Ponto a ser considerado: analisar qual a influência no sistema operacional de um aumento do número de processos permitido para cada usuário.

 

 

8. Outras possibilidades de gargalo

 

 

 

Quase nenhuma configuração foi efetivada ou analisada para o Oracle Web Server que é quem realmente executa todo o acesso ao banco de dados para cada solicitação dos usuários. Além da mínima configuração que foi executada, a versão utilizada no sistema não é a mais atual (1.0). No ambiente de desenvolvimento foi instalada cópia da versão 2.0, mas é preciso haver uma simula ção para que se verifique quais os benefícios que esta nova versão traz sobre a primeira. Um possível benefício seria redirecionar conexões além do número limite para outro listener que seria ativado.

 

Ponto a ser considerado: analisar a performance e compatibilidade da aplicação com a versão 2.0 do Oracle Web Server em relação à versão 1.0.

 

9. Propostas para aumento da performance

 

As possíveis propostas listadas abaixo não devem ser consideradas como soluções definitivas para o projeto PADCT. Elas foram fornecidas apenas como pontos de estudo que PODEM vir a ser utilizadas caso sej a constatada sua viabilidade neste caso.

 

 

É fundamental que se saiba exatamente o impacto da utilização de qualquer um desses itens sobre o resto do sistema antes de sua utilização.

 

10. Considerações

 

Não se sabe se o servidor utilizado no projeto PADCT estava realmente em seu limite de utilização. Através do monitoramento feito, percebeu-se que muito estava sendo exigido da máquina, mas n&atild e;o houve condições de se fazer uma análise mais aprofundada a nível de configuração de sistema operacional e do banco de dados a fim de se alcançar tal limite. Para que isso possa acontecer e para que um m onitoramento eficiente seja feito os seguintes pontos devem ser considerados:

 

  1. Um planejamento prévio e uma maior integração entre as equipes de banco de dados, desenvolvimento e administração de sistemas são imprescindíveis. Vários problemas surgidos poderiam ser detectado s previamente e todo o ambiente poderia ter sido melhor projetado para acomodar o sistema de forma mais eficiente. Não houve esse planejamento e integração. Isso implica, diretamente, num estudo da natureza das aplicaçõe s envolvidas.
  2.  

    Exemplo: a não utilização de índices na base de dados. Como se sabe, os índices agilizam as consultas numa ordem de grandeza bastante considerável, o que permitiria "desafogar" a CPU, princi palmente no caso de consultas mais pesadas. Não adianta o empenho apenas no lado da arquitetura e do sistema operacional.

     

  3. Na utilização das ferramentas de monitoração, deve-se fazer uma filtragem cuidadosa das informações realmente relevantes para a análise que está sendo feita.
  4. Um estudo aprofundado sobre os aspectos de máquina, sistema operacional e banco de dados deve ser feito a fim de se identificar todos, ou ao menos os principais, parâmetros do sistema que podem ser manipulados com vistas à melhoria da performance. Para tal, é imprescindível uma boa documentação e bibliografias disponíveis.