[Resolvido] Servidor Congelando

[Lucas Aguiar 0]

Boa tarde,

 

Estou com um problema persistente em um servidor de Alta Disponibilidade. Tal servidor disponibiliza um serviço de EDI que consiste em receber dados por meio de aplicações CGI que rodam no apache, e armazenar os dados adquiridos em um banco PostgreSQL. Este servidor está virtualizado em um DataCenter (Blade DELL).

 

Com frequência, o suporte do DataCenter nos contata informando que o serviço SSH e HTTP não estão respondendo por requisições. Quando os analistas do DTC acessam o console do vCenter, notam que a máquina nem sequer responde. Como não podemos acessar via SSH devido ao congelamento, temos de reiniciar o servidor.

 

Os analistas do DataCenter nos enviaram gráficos do VmWare Workstation que acusa um grande pico no processamento, ultrapassando que ultrapassa os 80% do Pool de processamento disponibilizado. Esse pico ocorre geralmente antes do travamento do Sistema Operacional ( Logicamente ).

 

Já procuramos por detalhes nos logs (/var/log/messages e syslog) bem como nos logs do PostgreSQL, e não conseguimos localizar nenhuma informação que nos ajudasse a entender o que leva ao suposto pico de processamento.

 

A máquina possui 4 núcleos Xeon e 4 Gigas de memória. Esta configuração suporta sem nenhum problema os serviços hospedados. As aplicações são desenvolvidas em Free Pascal ( Linguagem C ), o que dispensa interpretadores e roda diretamente no núcleo do operacional. Por isso não consomem nem 5% do processamento.

 

Anteriormente, esse mesmo ambiente rodava em 2 PowerEdge T1800 Clusterizados, e por 5 anos ininterruptos não consumiram nem sequer 10% do poder de processamento das máquinas, que eram 3 vezes inferiores a atual.

 

Em outras palavras, não existe causa conhecida para o suposto pico de processamento, e o mais problemático, o congelamento do servidor. Os logs nada acusam. Gostaria por favor de uma ajuda para pelo menos traçar uma linha de reciocínio para resolver o problema.

 

Att

Lucas

[Prog 183]

Algumas informações adicionais.

 

O que é reiniciado? O sistema operacional virtualizado ou o host todo?

A versão do sistema operacional mudou?

Estes congelamentos ocorrem com que frequência?

Já colocou um sistema de monitoramento ou algo que fique de tempos em tempos logando para um arquivo texto os processos em execução? Pode ser algo com o cron mesmo.

[Lucas Aguiar 0]

Bom dia Prog,

 

A reinicialização é pertinente apenas ao host. O Blade bem como todos os outros CloudServers do Pool que se encontra o meu servidor não são afetados

 

A versão do sistema operacional não mudou. Permanece Linux Debian 2.6.32-5-686-bigmem desde sua montagem

 

O congelamento ocorre esporádicamente. Não existe uma frequência definida. Às vezes o servidor congela uma vez por semana, em outros momentos congela diariamente.

 

Já loguei os processos em execução utilizando "ps ax" e "top", bem como "free -m" para memória e "df -h" para verificar possivel aumento de disco. Porém estes logs não mostraram absolutamente nada... bem como os logs do Apache e do PostgreSQL

[Prog 183]

Não houve sequer uma alteração na aplicação? Digo, nenhuma nova funcionalidade foi criada? A aplicação já foi submetido a stress de carga (várias requisições simultâneas)? Houve algum aumento de carga na aplicação? O que definiu a mudança se no ambiente anterior a aplicação rodava bem?

 

Quando questionei sobre a versão do sistema operacional estava me referindo a versão que rodava anteriormente, nos PowerEdge T1800 para a atual. É a mesma versão nos 2 ambientes, com os mesmos softwares e módulos do Apache instalados?

 

Os outros ambientes virtualizados também rodam Debian, existe algum outro host Debian rodando neste ambiente virtualizado? Não há nada no log do sistema operacional, se ainda não analisou, de uma olhada principalmente nos arquivos messages e syslog.

 

Qual o tamanho dos logs? Qual o tamanho das partições e uso das mesmas?

[Lucas Aguiar 0]

Não houve alterações na aplicação. Os serviços rodavam ativamente desde Novembro de 2006 na Clusterização com os T1800 sem interrupções. A mudança do ambiente foi realizada devido ao custo elevado para a empresa em manter o método de Co-Location, além da preocupação com a obtenção de novos componentes para servidores já fora de linha.

 

A versão do Debian é a mesma anteriormente utilizada no Co-Location. Os módulos do apache2 sem dúvida sofreram alterações na migração. O kernell do Linux e o PostgreSQL também sofrera, alterações, e estas alterações está sendo investigada para mitigar o problema.

 

De Acordo com a companhia que fornece a virtualização, existem mais servidores Debian rodando no mesmo Blade, e esses não apresentam problemas.

 

A questão é que do meu ponto de vista, limitado diga-se de passagem, os serviços do Apache2 e do PostgreSQL deveriam indicar anomalias ou problemas nos logs de execução caso esses existissem. Mais os logs não indicam nada.

 

Já os logs do operacional, como o "messages" e o "syslog" por exemplo, são simplesmente interrompidos no momento do congelamento, e voltam a ser alimentados após a reinicialização do host. Antes do congelamento não mostram nada significativo que possa lançar luz sobre o ocorrido. O tamanho máximo alcançado por esses logs são de 60MB.

 

Passo a acreditar que a alteração do kernel mencionada, dos parâmetros "kernel.shmmax" e "kernel.smmall", junto dos outros parâmetros que dimensionam o consumo do cache pelo PostgreSQL, estão ocasionando o congelamento total do Operacional.

 

Desculpe não ter mencionado tais alterações antes, mais fui notá-las apenas ao pesquisar cabalmente todos os detalhes do operacional, visto que a modificação realizada por outro analista não foi documentada.

 

Att

[Prog 183]

...

Já os logs do operacional, como o "messages" e o "syslog" por exemplo, são simplesmente interrompidos no momento do congelamento, e voltam a ser alimentados após a reinicialização do host. Antes do congelamento não mostram nada significativo que possa lançar luz sobre o ocorrido. O tamanho máximo alcançado por esses logs são de 60MB.

...

Passo a acreditar que a alteração do kernel mencionada, dos parâmetros "kernel.shmmax" e "kernel.smmall", junto dos outros parâmetros que dimensionam o consumo do cache pelo PostgreSQL, estão ocasionando o congelamento total do Operacional.

...

 

Essas alteração da parametrização do kernel é uma requisição para o funcionamento da aplicação? Pq elas foram realizadas? Quais os valores setados?

 

O fato de não haver logs das aplicações Apache e PostgreSQL leva a crer que o problema não são com esses softwares, e um congelamento total do sistema esta mais relacionado sim a um problema crítico por parte do kernel ou um de seus módulos de controle de dispositivos (placa de rede, vídeo, disco).

 

Muito estranho este fato dos logs estarem corrompidos, esta é a melhor, senão a única, maneira de diagnosticar qualquer anomalia do ambiente.

 

Minha suspeita:

Incompatibilidade de algum módulo Debian com o VMWare.

Já pesquisou casos parecidos de VMWare e Debian?

[Lucas Aguiar 0]

Essa alteração no Kernel é um ajuste conhecido para servidores de missão crítica que rodam o PostgreSQL. Quando o PostgreSQL atende um grande fluxo de requisições, ele pode apresentar o problema "sem memória compartilhada", pois a quantidade de cache disponibilizada pelo operacional não é suficiente para atender as requisições.

 

Nesse caso, ajusta-se, naturalmente com cautela, o limiar de memória cache à ser disponibilizada pelo operacional, e ajusta-se também a quantidade dessa memória dispendida para o PostgreSQL. Segue detalhes:

 

http://www.postgresql.org/docs/8.2/static/kernel-resources.html#SYSVIPC

 

Realmente um problema com o Kernel é mais provável do que um problema com qualquer um dos serviços. Porém, como mostrado no link acima, existe uma estreita relação com o consumo de memoria do PostgreSQL (shared_buffers) e o desempenho do Operacional.

 

Realizei algumas alterações nas configurações do PostgreSQL, e agora estamos monitorando e aguardando o travamento ocorrer novamente. Logo que tiver mais detalhes posto aqui.

 

Obrigado

 

Att,

[Prog 183]

Certo, vi lá a página que você indicou sobre a parametrização das variáveis.

 

Aguardando "cenas dos próximos capítulos".

[Lucas Aguiar 0]

Bom dia,

 

Após realizada algumas alterações, conseguimos normalizar e estabilizar o servidor. De acordo com os dados de monitoramento do Nagios instalados no Cloud, bem como dos dados disponibilizados pelo vCenter (VmWare), o consumo de memória, CPU e disco baixaram significativamente, e o servidor não mais apresenta sobrecarga. Esses são os motivos para crer que atingimos o ponto crítico do cenário.

 

Em poucas palavras, tentarei explicar as definições realizadas e os motivos que levaram as alterações.

 

Como mencionado anteriormente, o vCenter acusava alto consumo de memória, processamento e IO de disco momentos antes do travamento do Cloud. Os logs do sistema operacional simplesmente eram interrompidos, e só era possível acessar os serviços após a reinicialização do host.

 

O Linux utiliza parte da memória RAM como memória de transação rápida, ou "memória compartilhada", para processar requisições de todos os processos e aplicações do operacional. A quantidade total de tal memória é definida pelo parâmetro "kernel.shmall" no "kernel" do Linux

 

O PostgreSQL, por sua vez, também se utiliza da "memória compartilhada". Ao ser iniciado, o PostgreSQL agrupa, ou aloca, uma quantidade dessa memória disponível no sistema operacional para processar suas requisições. O Limiar ou a quantidade de memória que o PostgreSQL pode alocar é definido pelo parâmetro "shared_buffers" no arquivo "postgresql.conf".

 

As configurações anteriores do nosso servidor, nesse respeito, eram:

Quantidade de "memória compartilhada" alocada pelo Linux: 256 MB.

Quantidade de "memória compartilhada" permitida para o PostgresSQL: 220 MB.

 

Podemos notar que a maior parte da "memória compartilhada" era utilizada pelo PostgreSQL. Porém esse ainda não era o caso, visto que por padrão o Debian aloca apenas 32 MB de memória para fins de compartilhamento. Vale ressaltar que essa quantidade foi aumentada para 256 MB por questões específicas já abordadas nas respostas anteriores. Em outras palavras, subtraindo 220 MB dos 256 MB disponíveis, o Debian ainda ficava com 36 MB para seu consumo, um limiar superior ao padrão.

 

O Problema estava no funcionamento do PostgreSQL. O PostgreSQL utiliza-se da "memória compartilhada" para processar tudo o que é enviado para ele. Quando toda a memória é consumida pelo processo, o PostgreSQL realiza um "checkpoint", ou seja, transfere os dados da memória para o disco. Isso geralmente ocorre quando o próprio PostgreSQL julga necessário.

 

No nosso caso, como a quantidade de memória compartilhada utilizada para o PostgreSQL foi drasticamente aumentada, a quantidade de recurso utilizada para provisionar o "checkpoint", ou o momento de "swap" do PostgreSQL também foi aumentado drasticamente.

 

Resumindo, no momento que o PostgreSQL julgava necessário o "checkpoint" ( Por isso o problema ocorria esporadicamente ), ele consumia todos os recursos do PC, causando um congelamento em todos os processos por parte do Kernel, visto que esse processo de "swap" envolve intimamente a gerência dos recursos do mesmo.

 

Sendo assim diminuímos o limiar de consumo de memória do PostgreSQL ajustando o parâmetro "shared_buffers" no e redimensionamos a frequencia dos "checkpoints" alterando o parâmetro "checkpoints_segments", ambos no arquivo "postgresql.conf".

 

Para mais detalhes desse "redimensionamento", por favor, queiram visitar o link postado anteriormente. Alí existe uma explicação conclusiva de como dimensionar o Operacional para trabalhar com o PosgreSQL. Caso precisem segue novamente o link:

 

http://www.postgresql.org/docs/8.2/static/kernel-resources.html#SYSVIPC

 

Agradeço a atenção e paciência de todos ao lerem um "resumo" tão extenso. Espero que este tópico possa ajudar outros que estão passando pela mesma situação. Agradeço particularmente nosso amigo Prog pela contribuição.

 

Att

[Prog 183]

Boa!

Problema cabuloso, ainda bem que existe documentação sobre o assunto. :)

 

Mas afinal, esses parametros do kernel foram alterados após a migração dos ambientes?

[Lucas Aguiar 0]

Sim,

 

Como a virtualização possuía mais recursos que o Co-location, pareceu correto otimizar o PostgreSQL para suportar mais requisições. Temos em vista novos processos para o mesmo servidor.

 

A questão foi que essa alteração não foi devidamente calculada...

 

Att