Já observamos que no banco do V2 há queda abrupta de desempenho se o log de acessos fica maior de 2,5 milhões de registros (em nosso hw).
O log de acessos no V3 irá pelo mesmo caminho.
Também observamos similar queda significativa de desempenho no MySQL de Zabbix quando há muitos milhões de registros históricos.
A causa está no limite de cache size.
O "joelho" ocorre quando o dataset excede o tamanho do cache size num full sequential scan.
Isso faz um thrashing completo do cache.
Está simplificadamente explicado na seção "Effects of cache size" na página http://www.raj2u.net/postgresql-performance-tuning.html
Quais as soluções possíveis?
Esvaziar periodicamente as tabelas de logs é solução radical e descarta dados. Exportar ou copiar os dados a outra tabela antes de esvaziar é uma solução de contorno.
Apagar seletivamente numa tabela gigantesca é uma operação lenta demais para efeitos práticos.
Aumentar demais o(s) cache(s) é imediatista e de curto prazo.
Tabelas de logs crescem indefinidamente e em algum tempo enfrentaremos o problema novamente, apenas em outro patamar.
E se o Sistema Operacional gerencia bem os buffers, pode até prejudicar aumentar demais.
http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server
http://www.westnet.com/~gsmith/content/postgresql/pg-5minute.htm
http://wiki.postgresql.org/wiki/Number_Of_Database_Connections
http://www.anchor.com.au/hosting/dedicated/Tuning_PostgreSQL_on_your_Dedicated_Server
http://rhaas.blogspot.com.br/2012/03/tuning-sharedbuffers-and-walbuffers.html
http://packages.debian.org/pgtune
http://www.manniwood.com/postgresql_stuff/index.html
http://etutorials.org/SQL/Postgresql/Part+I+General+PostgreSQL+Use/Chapter+4.+Performance/How+PostgreSQL+Organizes+Data/
Utilizar locale=C e modificar encoding=UTF8 ou LATIN1
Essa ainda vamos testar, mas não promete ganhos estelares.
http://gmod.org/wiki/PostgreSQL_Performance_Tips
Utilizar cluster de índices sobre as tabelas.
http://www.postgresql.org/docs/8.3/static/sql-cluster.html
As queries sobre tabelas de logs acabam provocando full sequential scan. Não deve ajudar muito...
http://reorg.projects.pgfoundry.org/
O que deverá resolver para longo prazo nessa situação é PARTICIONAR TABELAS, usando triggers em vez de rules para maior desempenho e compatibilidade.
http://www.postgresql.org/docs/9.1/static/ddl-partitioning.html
http://blog.enfranchisedmind.com/2006/11/postgres-for-the-win/
http://www.day32.com/MySQL/Meetup/Presentations/postgresql_partitioning_short.pdf
http://www.webhostingskills.com/articles/freebsd_postgresql_tuning_the_database_server
Dependendo do seu hardware, terá também de fazer realocação dos tablespaces para outros discos.
Esta abordagem também é recomendada para o Zabbix com tabelas históricas gigantes
http://www.slideshare.net/xsbr/alexei-vladishev-zabbixperformancetuning
inclusive já documentado para PostgreSQL
https://www.zabbix.com/wiki/non-english/ru/partitioning_in_postgresql?s[]=partitioning
e MySQL
https://www.zabbix.com/wiki/non-english/ru/partitioning_in_mysql?s[]=partitioning
Particionar tabelas não exime da necessidade de fazer os tunings para seu cenário
http://www.techforce.com.br/news/linux_blog/postgresql_tuning_fazer_elefante_voar
Precisamos planejar um bom particionamento (e os triggers) para as tabelas do V2 e do V3.
Boa sorte.
André Felipe Machado
SUPOP/OPPAE/OPSIN/OPOSC
(51)2129-1317
Veja o tutorial do ExpressoV3
https://expressov3.serpro.gov.br/tutorial/html/index.html
-------------
-
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
"Esta mensagem do SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO), empresa pública federal regida pelo disposto na Lei Federal nº 5.615, é enviada exclusivamente a seu destinatário e pode conter informações confidenciais, protegidas por sigilo profissional. Sua utilização desautorizada é ilegal e sujeita o infrator às penas da lei. Se você a recebeu indevidamente, queira, por gentileza, reenviá-la ao emitente, esclarecendo o equívoco."
"This message from SERVIÇO FEDERAL DE PROCESSAMENTO DE DADOS (SERPRO) -- a government company established under Brazilian law (5.615/70) -- is directed exclusively to its addressee and may contain confidential data, protected under professional secrecy rules. Its unauthorized use is illegal and may subject the transgressor to the law's penalties. If you're not the addressee, please send it back, elucidating the failure."
_______________________________________________ Cisl-comunidade mailing list [email protected] http://listas.softwarelivre.org/cgi-bin/mailman/listinfo/cisl-comunidade
