Problemas de Performance

[Bráulio Bhavamitra]

Oi rodrigo e demais,

Há tempo fiquei de responder e só agora encontrei a disposição.

Em primeiro lugar, acho muito bom que se invista em mais estrutura para
encontrar
problemas antes que eles entrem em produção. Isto vai ajudar muito com
problemas
gerais, mas receio que neste caso não ajude muito...

O problema de "vazamento" de memória, como identificado por vocês, está no
ruby 1.8. A turma do twitter
teve este problema há muito tempo, e por isso decidiu mudar para o REE
(ruby compatível com o ruby mri 1.8)
Vejam os posts abaixo:
http://engineering.twitter.com/2011/03/building-faster-ruby-garbage-collector.html
http://engineering.twitter.com/2011/05/faster-ruby-kiji-update.html

Por isso, temo que investir numa estrutura de homologação possa atrasar
mais ainda a correção
do problema, que envolve a atualização do noosfero para um ruby
aperfeiçoado (1.9 ou ree).

abraços,
bráulio




2013/3/14 Rodrigo Souto <rodrigo at colivre.coop.br>

> Olá pessoal,
>
> Há algumas versões o Noosfero têm apresentado um problema recorrente de
> performance em praticamente todas as suas instalações de produção. Após
> realizarmos o monitoramento e investigação dessas redes, diagnosticamos
> o problema como sendo, principalmente, vazamento de memória. Esse
> problema é agravado pelo fato de ainda estarmos utilizando Ruby 1.8; é
> de conhecimento geral que o gerenciamento de memória na máquina virtual
> do Ruby 1.8 é deficiente, o que foi corrigido na versão 1.9.
>
> Esse diagnóstico explica e confirma o porquê do comportamento sugerido e
> aplicado por nós de reiniciar os servidores do Noosfero periodicamente
> tem "funcionado" por enquanto.
>
> Uma vez diagnosticado o problema, passamos a fazer a investigação das
> suas causas e, dada urgência da questão, demos foco a uma solução mais
> veloz e direta (essa investigação está registrada aqui:
> http://noosfero.org/Development/ActionItem2569). Porém, essa
> investigação se mostrou parcialmente infrutífera uma vez que os
> problemas com os quais nós estamos lidando estão diretamente
> relacionados com a realidade dos servidores de producão, com todos os
> seus dados, configurações e cargas de acesso reais.
>
> Tendo em vista o nível de urgência do problema, a inviabilidade de
> investigação em ambientes de teste ou desenvolvimento e um longo
> interesse nosso em melhorar a qualidade do desenvolvimento do Noosfero
> como um todo, tomamos a decisão de investir nossos esforços em uma
> solução maior, mais trabalhosa, porém, mais completa, que servirá não só
> para solucionarmos esse problema, mas também para prevenir que eles
> voltem a acontecer novamente no futuro. Essa solução será,
> majoritariamente, um aperfeiçoamento da nossa infra-estrutura,  com a
> criação de servidores de homologação, integração continua do código e
> testes de carga.
>
> Pretendemos, a partir dessa solução, ser capazes de localizar exatamente
> os locais que estão causando este vazamento de memória e corrigirmos
> esse problema.
>
> Agradeçemos a paciência de todos e saibam que nós estamos nos dedicando
> a fundo para resolver esses problemas.
>
> --
> Rodrigo Souto <rodrigo at colivre.coop.br> :: 55 71 8131-7714
> Colivre - Cooperativa de Tecnologias Livres
> http://www.colivre.coop.br/
>
> _______________________________________________
> Noosfero-br mailing list
> Noosfero-br at listas.softwarelivre.org
> http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/noosfero-br
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://listas.softwarelivre.org/pipermail/noosfero-br/attachments/20130516/8702cc52/attachment.html>