Re: [pgbr-geral] Lentidão no Postgres 9.5

2016-09-12 Por tôpico Irineu Raymundo 

Em 08/09/2016 17:01, Fabrízio de Royes Mello escreveu:

On 08-09-2016 09:43, Irineu Raymundo wrote:

Bom dia pessoal,

Estou com um problema de lentidão numa rotina...
Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11
índices.

Segue abaixo a rotina:

TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
REINDEX TABLE senda.ind_03_03_04_01_lev;

Porque o REINDEX em uma tabela que vc recém efetuou um TRUNCATE? O
TRUNCATE recria todos datafiles envolvidos (heap e btree).



VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;

Aqui vc efetua um VACUUM FULL novamente e talvez sem necessidade,
principalmente pelo fato da "senda.ind_03_03_04_01_lev" ter sido
truncada anteriormente. Será que as demais tabelas não são truncadas
junto com as anteriores devido ao "CASCADE"???



SET temp_buffers=3;

Setando dessa forma vc está informando ao PostgreSQL para usar ~234,38MB
= (3*8kB)/1024.


SELECT senda.ins_mat_lev_cria_indices();
SELECT senda.ins_mat_lev_1('98');
SELECT senda.ins_mat_lev_2('98');
SELECT senda.ins_mat_lev_3('98');
SELECT senda.ins_mat_lev_4('98');
SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);


Dificil te ajudar sem saber exatamente o que essas PLs fazem.



Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função
descarrega os registros( 2 milhões) das temporáriad para as tabelas
UNLOGGED e aí que trava de vez em quando.


Precisamos de mais detalhes para poder ajudar!

Att,



Antes de mandar os códigos-fonte das Pls(que são enormes) resolvi 
revisar toda a rotina levando em conta os comentários do Fabrízio.
Tirei o REINDEX  depois do CASCADE, diminui o valor do temp_buffer da 
sessão e a rotina estabilizou, não trava mais.


Obrigado  pela ajuda!!!

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Fabrízio de Royes Mello 
On 08-09-2016 09:43, Irineu Raymundo wrote:
> Bom dia pessoal,
> 
> Estou com um problema de lentidão numa rotina, se alguém puder me dar
> uma luz do que eu poderia investigar fico imensamente agradecido.
> 
> O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"
> 
> A trava aparentemente de forma aleatória, executa 2 dias normalmente e
> parece que do nada trava na última função e fica mais de 4 horas sendo
> obrigado a derrubar.
> 
> Conferi quando trava e não tem nenhuma outra instrução que poderia faz
> um lock nas tabelas.
> 
> Basicamente ela cria tabelas temporárias, faz os cálculos necessários e
> escreve numa tabela não logada(UNLOGGED) para poder imprimir o relatório
> via ODBC.
> Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11
> índices.
> 
> Segue abaixo a rotina:
> 
> TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
> TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
> REINDEX TABLE senda.ind_03_03_04_01_lev;

Porque o REINDEX em uma tabela que vc recém efetuou um TRUNCATE? O
TRUNCATE recria todos datafiles envolvidos (heap e btree).


> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
> VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;

Aqui vc efetua um VACUUM FULL novamente e talvez sem necessidade,
principalmente pelo fato da "senda.ind_03_03_04_01_lev" ter sido
truncada anteriormente. Será que as demais tabelas não são truncadas
junto com as anteriores devido ao "CASCADE"???


> SET temp_buffers=3;

Setando dessa forma vc está informando ao PostgreSQL para usar ~234,38MB
= (3*8kB)/1024.

> SELECT senda.ins_mat_lev_cria_indices();
> SELECT senda.ins_mat_lev_1('98');
> SELECT senda.ins_mat_lev_2('98');
> SELECT senda.ins_mat_lev_3('98');
> SELECT senda.ins_mat_lev_4('98');
> SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);
> 

Dificil te ajudar sem saber exatamente o que essas PLs fazem.


> Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função
> descarrega os registros( 2 milhões) das temporáriad para as tabelas
> UNLOGGED e aí que trava de vez em quando.
> 

Precisamos de mais detalhes para poder ajudar!

Att,

-- 
   Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Guimarães Faria Corcete DUTRA , Leandro 
2016-09-08 9:43 GMT-03:00 Irineu Raymundo :
>
> Estou com um problema de lentidão numa rotina, se alguém puder me dar uma
> luz do que eu poderia investigar fico imensamente agradecido.

Cadê os planos de execução?


> O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc
> (Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"
[…]
> Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função
> descarrega os registros( 2 milhões) das temporáriad para as tabelas UNLOGGED
> e aí que trava de vez em quando.

Que função?  Qual a definição dela (código-fonte) e quais as
estruturas dos objetos envolvidos?


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] Lentidão no Postgres 9.5

2016-09-08 Por tôpico Irineu Raymundo 

Bom dia pessoal,

Estou com um problema de lentidão numa rotina, se alguém puder me dar 
uma luz do que eu poderia investigar fico imensamente agradecido.


O banco é : "PostgreSQL 9.5.4 on x86_64-pc-linux-gnu, compiled by gcc 
(Ubuntu 5.4.0-6ubuntu1~16.04.2) 5.4.0 20160609, 64-bit"


A trava aparentemente de forma aleatória, executa 2 dias normalmente e 
parece que do nada trava na última função e fica mais de 4 horas sendo 
obrigado a derrubar.


Conferi quando trava e não tem nenhuma outra instrução que poderia faz 
um lock nas tabelas.


Basicamente ela cria tabelas temporárias, faz os cálculos necessários e 
escreve numa tabela não logada(UNLOGGED) para poder imprimir o relatório 
via ODBC.
Essa tabela fica com mais ou menos 2 milhões de registros, e tem uns 11 
índices.


Segue abaixo a rotina:

TRUNCATE senda.ind_03_03_04_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_lev CASCADE;
TRUNCATE senda.ind_03_03_04_01_01_a1_lev;
REINDEX TABLE senda.ind_03_03_04_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_01_a1_lev;
VACUUM FULL ANALYZE senda.ind_03_03_04_01_lev;
VACUUM FULL ANALYZE senda.ind_03_03_03_02_oc;
SET temp_buffers=3;
SELECT senda.ins_mat_lev_cria_indices();
SELECT senda.ins_mat_lev_1('98');
SELECT senda.ins_mat_lev_2('98');
SELECT senda.ins_mat_lev_3('98');
SELECT senda.ins_mat_lev_4('98');
SELECT senda.mat_marca_cliente_lev('98','LEVMAT',NULL,1256);

Até esse ponto vai tranquilo, coisa de 5 minutos,  a próxima função 
descarrega os registros( 2 milhões) das temporáriad para as tabelas 
UNLOGGED e aí que trava de vez em quando.



Irineu Raymundo

Senda engenharia de Dados.

___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral