Re: [pgbr-geral] Como analisar a causa out of memory?
Em 9 de julho de 2013 19:03, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 17:55, Luiz Carlos L. Nogueira Jr. wrote: Pessoal, Apesar de eu não ter acreditado, parece que resolveu mudei o overcommit_ratio de 50 pra 100 e 6 horas sem out of memory Eu não recomendaria utilizar 100 (apesar que alguns artigos recomendarem). Eu deixaria alguma memória para ser utilizada pelo SO e alguma outra aplicação acessório. Por isso, eu recomendaria *não* utilizar 100 mas um valor próximo. É polêmico mesmo... eu costumo usar 80%. No caso aqui, como o swap é muito pequeno, o risco é maior. Aumentando o swap a conta fica melhor. -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
[pgbr-geral] Como analisar a causa out of memory?
Pessoal, Tem como analisar o motivo do out of memory com o despejo que aparece no log? O estranho é que quando ele aparece nem entrei ainda no swap e tenho vários buffers livres (free -m). Estou com a versão 9.1.9 Máquina: 8 cores, 32GB, 6GB shared_buffers, 20MB work_mem. Isso ocorre mais quando tenho muitos processos idle in transaction, mas não obrigatoriamente. Detail: Failed on request of size 40. Statement: select distinct classejudi0_.id_classe_judicial as id1_291_0_, classejudi1_.id_classe_judicial as id1_291_1_, classejudi0_.in_ativo as in2_291_0_, classejudi0_.ds_classe_judicial as ds3_291_0_, classejudi0_.id_classe_judicial_pai as id36_291_0_, classejudi0_.ds_classe_judicial_sigla as ds6_291_0_, classejudi0_.cd_classe_judicial as cd7_291_0_, classejudi0_.cd_classe_outro as cd8_291_0_, classejudi0_.in_complementar as in9_291_0_, classejudi0_.in_controla_valor_causa as in10_291_0_, classejudi0_.in_designa_aud_errovc as in11_291_0_, classejudi0_.in_exige_autoridade as in12_291_0_, classejudi0_.in_exige_numeracao_propria as in13_291_0_, classejudi0_.id_fluxo as id37_291_0_, classejudi0_.ds_icone as ds14_291_0_, classejudi0_.in_ignora_compensacao as in15_291_0_, classejudi0_.in_ignora_prevencao as in16_291_0_, classejudi0_.in_incidental as in17_291_0_, classejudi0_.in_inicial as in18_291_0_, classejudi0_.in_jus_postulandi as in19_291_0_, classejudi0_.ds_mensagem as ds22_291_0_, classejudi0_.ds_natureza as ds23_291_0_, classejudi0_.ds_norma as ds24_291_0_, classejudi0_.in_exige_pauta as in25_291_0_, classejudi0_.nr_piso_valor_causa as nr26_291_0_, classejudi0_.id_polo_ativo as id38_291_0_, classejudi0_.id_polo_passivo as id39_291_0_, classejudi0_.in_possui_custa as in27_291_0_, classejudi0_.in_possui_filhos as in28_291_0_, classejudi0_.tp_processo_referencia as tp29_291_0_, classejudi0_.in_reclama_polo_passivo as in30_291_0_, classejudi0_.in_recursal as in31_291_0_, classejudi0_.in_exige_revisor as in32_291_0_, classejudi0_.in_segredo_justica as in33_291_0_, classejudi0_.nr_teto_valor_causa as nr34_291_0_, classejudi0_.id_tipo_audiencia as id40_291_0_, classejudi0_.vl_peso as vl35_291_0_, classejudi1_.in_ativo as in2_291_1_, classejudi1_.ds_classe_judicial as ds3_291_1_, classejudi1_.id_classe_judicial_pai as id36_291_1_, classejudi1_.ds_classe_judicial_sigla as ds6_291_1_, classejudi1_.cd_classe_judicial as cd7_291_1_, classejudi1_.cd_classe_outro as cd8_291_1_, classejudi1_.in_complementar as in9_291_1_, classejudi1_.in_controla_valor_causa as in10_291_1_, classejudi1_.in_designa_aud_errovc as in11_291_1_, classejudi1_.in_exige_autoridade as in12_291_1_, classejudi1_.in_exige_numeracao_propria as in13_291_1_, classejudi1_.id_fluxo as id37_291_1_, classejudi1_.ds_icone as ds14_291_1_, classejudi1_.in_ignora_compensacao as in15_291_1_, classejudi1_.in_ignora_prevencao as in16_291_1_, classejudi1_.in_incidental as in17_291_1_, classejudi1_.in_inicial as in18_291_1_, classejudi1_.in_jus_postulandi as in19_291_1_, classejudi1_.ds_mensagem as ds22_291_1_, classejudi1_.ds_natureza as ds23_291_1_, classejudi1_.ds_norma as ds24_291_1_, classejudi1_.in_exige_pauta as in25_291_1_, classejudi1_.nr_piso_valor_causa as nr26_291_1_, classejudi1_.id_polo_ativo as id38_291_1_, classejudi1_.id_polo_passivo as id39_291_1_, classejudi1_.in_possui_custa as in27_291_1_, classejudi1_.in_possui_filhos as in28_291_1_, classejudi1_.tp_processo_referencia as tp29_291_1_, classejudi1_.in_reclama_polo_passivo as in30_291_1_, classejudi1_.in_recursal as in31_291_1_, classejudi1_.in_exige_revisor as in32_291_1_, classejudi1_.in_segredo_justica as in33_291_1_, classejudi1_.nr_teto_valor_causa as nr34_291_1_, classejudi1_.id_tipo_audiencia as id40_291_1_, classejudi1_.vl_peso as vl35_291_1_, classejudi1_.id_classe_judicial_pai as id36_0__, classejudi1_.id_classe_judicial as id1_0__ from tb_classe_judicial classejudi0_ left outer join tb_classe_judicial classejudi1_ on classejudi0_.id_classe_judicial=classejudi1_.id_classe_judicial_pai where classejudi0_.id_classe_judicial_pai is null order by classejudi0_.ds_classe_judicial, classejudi1_.ds_classe_judicial, classejudi1_.ds_classe_judicial asc TopMemoryContext: 88840 total in 12 blocks; 4008 free (10 chunks); 84832 used Operator lookup cache: 24576 total in 2 blocks; 11888 free (5 chunks); 12688 used Prepared Queries: 24576 total in 2 blocks; 15984 free (5 chunks); 8592 used TopTransactionContext: 8192 total in 1 blocks; 7328 free (0 chunks); 864 used MessageContext: 24576 total in 2 blocks; 14192 free (5 chunks); 10384 used CFuncHash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used Operator class cache: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used smgr relation table: 24576 total in 2 blocks; 9808 free (4 chunks); 14768 used TransactionAbortContext: 32768 total in 1 blocks; 32736 free (0 chunks); 32 used Portal hash: 8192 total in 1 blocks; 1680 free (0 chunks); 6512 used PortalMemory: 8192 total in 1 blocks; 7888 free (0 chunks); 304 used PortalHeapMemory:
Re: [pgbr-geral] Como analisar a causa out of memory?
On 09-07-2013 08:43, Luiz Carlos L. Nogueira Jr. wrote: [*não* abra outro assunto; isso bagunça o histórico] O estranho é que quando ele aparece nem entrei ainda no swap e tenho vários buffers livres (free -m). Estou com a versão 9.1.9 Máquina: 8 cores, 32GB, 6GB shared_buffers, 20MB work_mem. Isso ocorre mais quando tenho muitos processos idle in transaction, mas não obrigatoriamente. Como você não continuou a outra thread, eu não vou buscá-la aqui e talvez esteja perguntando algo que já está lá mas... (i) qual o valor do parâmetro do kernel vm.overcommit_memory? sysctl vm.overcommit_memory (ii) qual o valor do parâmetro do kernel vm.overcommit_ratio? sysctl vm.overcommit_ratio (ii) olhe nos logs do SO se há entradas do OOM killer grep -i kill /var/log/messages* (iii) há alguma outro serviço concorrendo com o postgres nesta máquina? (iv) você já executou um analisador de memória (por exemplo memtest)? (v) qual a versão do kernel utilizada? -- Euler Taveira 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] Como analisar a causa out of memory?
É pq eu atualizei o postgres (9.1.6-9.1.9), que foi a última solução, mas que não deu resultado, por isso abri outro post (i) qual o valor do parâmetro do kernel vm.overcommit_memory? sysctl vm.overcommit_memory vm.overcommit_memory = 2 (ii) qual o valor do parâmetro do kernel vm.overcommit_ratio? sysctl vm.overcommit_ratio vm.overcommit_ratio = 50 (ii) olhe nos logs do SO se há entradas do OOM killer grep -i kill /var/log/messages* nada (iii) há alguma outro serviço concorrendo com o postgres nesta máquina? Não (iv) você já executou um analisador de memória (por exemplo memtest)? Não - Pedirei ao pessoal de SO (v) qual a versão do kernel utilizada? Linux spdbpostgre01 2.6.32-279.14.1.el6.x86_64 #1 SMP Mon Oct 15 13:44:51 EDT 2012 x86_64 x86_64 x86_64 GNU/Linux Em 9 de julho de 2013 09:43, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 08:43, Luiz Carlos L. Nogueira Jr. wrote: [*não* abra outro assunto; isso bagunça o histórico] O estranho é que quando ele aparece nem entrei ainda no swap e tenho vários buffers livres (free -m). Estou com a versão 9.1.9 Máquina: 8 cores, 32GB, 6GB shared_buffers, 20MB work_mem. Isso ocorre mais quando tenho muitos processos idle in transaction, mas não obrigatoriamente. Como você não continuou a outra thread, eu não vou buscá-la aqui e talvez esteja perguntando algo que já está lá mas... (i) qual o valor do parâmetro do kernel vm.overcommit_memory? sysctl vm.overcommit_memory (ii) qual o valor do parâmetro do kernel vm.overcommit_ratio? sysctl vm.overcommit_ratio (ii) olhe nos logs do SO se há entradas do OOM killer grep -i kill /var/log/messages* (iii) há alguma outro serviço concorrendo com o postgres nesta máquina? (iv) você já executou um analisador de memória (por exemplo memtest)? (v) qual a versão do kernel utilizada? -- Euler Taveira 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
On 09-07-2013 08:43, Luiz Carlos L. Nogueira Jr. wrote: Estou com a versão 9.1.9 Máquina: 8 cores, 32GB, 6GB shared_buffers, 20MB work_mem. Mais alguns dados que acabei esquecendo de perguntar... (i) quanto de swap você tem? (ii) qual o resultado de EXPLAIN ANALYZE da consulta? (iii) qual a saída do comando ulimit -s (iv) qual o valor do parâmetro vm.swapiness? sysctl vm.swappiness (v) qual a saída do comando cat /proc/meminfo (vi) além do erro da alocação de memória, aparece alguma mensagem próximo a ela indicando a queda de um processo servidor ou mesmo algum outro erro relevante a questão? Algo como terminating connection because of crash of another server process ou traduzindo finalizando conexão por causa de uma queda de um outro processo servidor -- Euler Taveira 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] Como analisar a causa out of memory?
(i) quanto de swap você tem? *free -m total used free sharedbuffers cached Mem: 32110 16735 15374 0 31 9884 -/+ buffers/cache: 6819 25290 Swap: 2559 11 2548 * (ii) qual o resultado de EXPLAIN ANALYZE da consulta? (iii) qual a saída do comando ulimit -s *10240 * (iv) qual o valor do parâmetro vm.swapiness? sysctl vm.swappiness *vm.swappiness = 60* (v) qual a saída do comando cat /proc/meminfo *MemTotal: 32880848 kB MemFree:15200452 kB Buffers: 32868 kB Cached: 10172808 kB SwapCached: 1164 kB Active: 9905792 kB Inactive:6899428 kB Active(anon):8541080 kB Inactive(anon): 1672148 kB Active(file):1364712 kB Inactive(file): 5227280 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2621424 kB SwapFree:2609624 kB Dirty: 2120 kB Writeback: 0 kB AnonPages: 6592876 kB Mapped: 3573064 kB Shmem: 3613776 kB Slab: 153124 kB SReclaimable: 93848 kB SUnreclaim:59276 kB KernelStack:3480 kB PageTables: 352516 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:19061848 kB Committed_AS: 13609336 kB VmallocTotal: 34359738367 kB VmallocUsed: 328592 kB VmallocChunk: 34359340400 kB HardwareCorrupted: 0 kB AnonHugePages: 3411968 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M:33544192 kB * (vi) além do erro da alocação de memória, aparece alguma mensagem próximo a ela indicando a queda de um processo servidor ou mesmo algum outro erro relevante a questão? Algo como terminating connection because of crash of another server process ou traduzindo finalizando conexão por causa de uma queda de um outro processo servidor *Não* Em 9 de julho de 2013 10:29, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 08:43, Luiz Carlos L. Nogueira Jr. wrote: Estou com a versão 9.1.9 Máquina: 8 cores, 32GB, 6GB shared_buffers, 20MB work_mem. Mais alguns dados que acabei esquecendo de perguntar... (i) quanto de swap você tem? (ii) qual o resultado de EXPLAIN ANALYZE da consulta? (iii) qual a saída do comando ulimit -s (iv) qual o valor do parâmetro vm.swapiness? sysctl vm.swappiness (v) qual a saída do comando cat /proc/meminfo (vi) além do erro da alocação de memória, aparece alguma mensagem próximo a ela indicando a queda de um processo servidor ou mesmo algum outro erro relevante a questão? Algo como terminating connection because of crash of another server process ou traduzindo finalizando conexão por causa de uma queda de um outro processo servidor -- Euler Taveira 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Esqueci o explain analyze *Unique (cost=70.19..71.87 rows=9 width=480) (actual time=1.734..2.069 rows=145 loops=1) - Sort (cost=70.19..70.21 rows=9 width=480) (actual time=1.730..1.781 rows=145 loops=1) Sort Key: classejudi0_.ds_classe_judicial, classejudi1_.ds_classe_judicial, classejudi0_.id_classe_judicial, classejudi1_.id_classe_judicial, classejudi0_.in_ativo, classejudi0_.id_classe_judicial_pai, classejudi0_.ds_classe_judicial_sigla, classejudi0_.cd_classe_judicial, classejudi0_.cd_classe_outro, classejudi0_.in_complementar, classejudi0_.in_controla_valor_causa, classejudi0_.in_designa_aud_errovc, classejudi0_.in_exige_autoridade, classejudi0_.in_exige_numeracao_propria, classejudi0_.id_fluxo, classejudi0_.ds_icone, classejudi0_.in_ignora_compensacao, classejudi0_.in_ignora_prevencao, classejudi0_.in_incidental, classejudi0_.in_inicial, classejudi0_.in_jus_postulandi, classejudi0_.ds_mensagem, classejudi0_.ds_natureza, classejudi0_.ds_norma, classejudi0_.in_exige_pauta, classejudi0_.nr_piso_valor_causa, classejudi0_.id_polo_ativo, classejudi0_.id_polo_passivo, classejudi0_.in_possui_custa, classejudi0_.in_possui_filhos, classejudi0_.tp_processo_referencia, classejudi0_.in_reclama_polo_passivo, classejudi0_.in_recursal, classejudi0_.in_exige_revisor, classejudi0_.in_segredo_justica, classejudi0_.nr_teto_valor_causa, classejudi0_.id_tipo_audiencia, classejudi0_.vl_peso, classejudi1_.in_ativo, classejudi1_.id_classe_judicial_pai, classejudi1_.ds_classe_judicial_sigla, classejudi1_.cd_classe_judicial, classejudi1_.cd_classe_outro, classejudi1_.in_complementar, classejudi1_.in_controla_valor_causa, classejudi1_.in_designa_aud_errovc, classejudi1_.in_exige_autoridade, classejudi1_.in_exige_numeracao_propria, classejudi1_.id_fluxo, classejudi1_.ds_icone, classejudi1_.in_ignora_compensacao, classejudi1_.in_ignora_prevencao, classejudi1_.in_incidental, classejudi1_.in_inicial, classejudi1_.in_jus_postulandi, classejudi1_.ds_mensagem, classejudi1_.ds_natureza, classejudi1_.ds_norma, classejudi1_.in_exige_pauta, classejudi1_.nr_piso_valor_causa, classejudi1_.id_polo_ativo, classejudi1_.id_polo_passivo, classejudi1_.in_possui_custa, classejudi1_.in_possui_filhos, classejudi1_.tp_processo_referencia, classejudi1_.in_reclama_polo_passivo, classejudi1_.in_recursal, classejudi1_.in_exige_revisor, classejudi1_.in_segredo_justica, classejudi1_.nr_teto_valor_causa, classejudi1_.id_tipo_audiencia, classejudi1_.vl_peso Sort Method: quicksort Memory: 74kB - Hash Right Join (cost=25.21..70.04 rows=9 width=480) (actual time=0.075..0.961 rows=145 loops=1) Hash Cond: ((classejudi1_.id_classe_judicial_pai)::integer = (classejudi0_.id_classe_judicial)::integer) - Seq Scan on tb_classe_judicial classejudi1_ (cost=0.00..42.36 rows=636 width=240) (actual time=0.006..0.344 rows=636 loops=1) - Hash (cost=25.10..25.10 rows=9 width=240) (actual time=0.055..0.055 rows=9 loops=1) Buckets: 1024 Batches: 1 Memory Usage: 2kB - Bitmap Heap Scan on tb_classe_judicial classejudi0_ (cost=4.32..25.10 rows=9 width=240) (actual time=0.018..0.041 rows=9 loops=1) Recheck Cond: (id_classe_judicial_pai IS NULL) - Bitmap Index Scan on tb_classe_judicial_id_classe_judicial_pai_idx (cost=0.00..4.32 rows=9 width=0) (actual time=0.011..0.011 rows=9 loops=1) Index Cond: (id_classe_judicial_pai IS NULL) Total runtime: 2.269 ms * Em 9 de julho de 2013 10:38, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: (i) quanto de swap você tem? *free -m total used free sharedbuffers cached Mem: 32110 16735 15374 0 31 9884 -/+ buffers/cache: 6819 25290 Swap: 2559 11 2548 * (ii) qual o resultado de EXPLAIN ANALYZE da consulta? (iii) qual a saída do comando ulimit -s *10240 * (iv) qual o valor do parâmetro vm.swapiness? sysctl vm.swappiness *vm.swappiness = 60* (v) qual a saída do comando cat /proc/meminfo *MemTotal: 32880848 kB MemFree:15200452 kB Buffers: 32868 kB Cached: 10172808 kB SwapCached: 1164 kB Active: 9905792 kB Inactive:6899428 kB Active(anon):8541080 kB Inactive(anon): 1672148 kB Active(file):1364712 kB Inactive(file): 5227280 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2621424 kB SwapFree:2609624 kB Dirty: 2120 kB Writeback: 0 kB AnonPages: 6592876 kB Mapped: 3573064 kB Shmem: 3613776 kB Slab: 153124 kB SReclaimable: 93848 kB SUnreclaim:59276 kB KernelStack:3480 kB PageTables: 352516 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB
Re: [pgbr-geral] Como analisar a causa out of memory?
(ii) qual o valor do parâmetro do kernel vm.overcommit_ratio? sysctl vm.overcommit_ratio vm.overcommit_ratio = 50 Ahá!!! Vale à pena aumentar para 80 ou mesmo 100. Vale à pena pesquisar como o parâmetro funciona. Note que aumentar este parâmetro só vale para servidores dedicados. Se tiver algum outro serviço rodando junto, tem que avaliar. Sinceramente, não sei se isso resolveria meu problema, pois não está nem perto de estourar a memória RAM, nem entrou no swap ainda. O servidor é dedicado. Eu tô achando que isso tem a ver com o hibernate e as operações demoradas idle in transaction que ele faz. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Esse EXPLAIN foi obtido no mesmo banco de dados que ocorreu o problema? Não me parece o mesmo do TopMemoryContext. *Pior que é.* Se quiserem os logs de ontem, mando sem problema. Em 9 de julho de 2013 11:25, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 10:41, Luiz Carlos L. Nogueira Jr. wrote: Esqueci o explain analyze [Evite top-posting. Se você esqueceu de algo responda o meu email original ao invés do seu email subsequente. Isso deixa o histórico mais organizado.] Esse EXPLAIN foi obtido no mesmo banco de dados que ocorreu o problema? Não me parece o mesmo do TopMemoryContext. CommitLimit:19061848 kB Committed_AS: 13609336 kB Você pode estar chegando próximo ao limite de overcommit. Aconselho aumentar o vm.overcommit_ratio para algo em torno de 70, 75 ou 80. Uma outra alternativa para ambientes não controlados e/ou limitados é utilizar vm.overcommit_memory=0. Outra sugestão é definir que o OOM killer *não* pode matar processos do postgres. Apesar de você ter dito que isso não está nos logs mas receio que isso esteja acontecendo (pelos valores apresentados). Configure OOM_ADJ para -1000 no script de inicialização do SO ou, se tem um script próprio, faça isso no seu script: echo -1000 /proc/numdopid/oom_score_adj onde numdopid é o pid do processo pai do postgres. Pegando um gancho, como está a carga (aka load) dessa máquina? -- Euler Taveira 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Em 9 de julho de 2013 10:38, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: (i) quanto de swap você tem? *free -m total used free sharedbuffers cached Mem: 32110 16735 15374 0 31 9884 -/+ buffers/cache: 6819 25290 Swap: 2559 11 2548 * Este valor de Swap é um pouco baixo. Eu costumo pensar em pelo menos 50% da RAM disponível. Não é um pecado grava, mas seria bom ter pelo menos 16GB. Veja, que se você tiver um surto de conexões encavalando de repente... a quantidade de memória utilizada por conexão pode fazer o consumo aumentar muito de repente. ** (ii) qual o resultado de EXPLAIN ANALYZE da consulta? (iii) qual a saída do comando ulimit -s *10240 * (iv) qual o valor do parâmetro vm.swapiness? sysctl vm.swappiness *vm.swappiness = 60* (v) qual a saída do comando cat /proc/meminfo *MemTotal: 32880848 kB MemFree:15200452 kB Buffers: 32868 kB Cached: 10172808 kB SwapCached: 1164 kB Active: 9905792 kB Inactive:6899428 kB Active(anon):8541080 kB Inactive(anon): 1672148 kB Active(file):1364712 kB Inactive(file): 5227280 kB Unevictable: 0 kB Mlocked: 0 kB SwapTotal: 2621424 kB SwapFree:2609624 kB Dirty: 2120 kB Writeback: 0 kB AnonPages: 6592876 kB Mapped: 3573064 kB Shmem: 3613776 kB Slab: 153124 kB SReclaimable: 93848 kB SUnreclaim:59276 kB KernelStack:3480 kB PageTables: 352516 kB NFS_Unstable: 0 kB Bounce:0 kB WritebackTmp: 0 kB CommitLimit:19061848 kB Committed_AS: 13609336 kB VmallocTotal: 34359738367 kB VmallocUsed: 328592 kB VmallocChunk: 34359340400 kB HardwareCorrupted: 0 kB AnonHugePages: 3411968 kB HugePages_Total: 0 HugePages_Free:0 HugePages_Rsvd:0 HugePages_Surp:0 Hugepagesize: 2048 kB DirectMap4k: 10240 kB DirectMap2M:33544192 kB * Aqui parece Ok. Mas o importante é saber como isto está momentos antes da queda e logo depois da queda. Quando eu quero investigar isso e não tenho uma ferramenta descente de monitoramento, eu deixo um JOB coletando isso direto de X em X segundos. (vi) além do erro da alocação de memória, aparece alguma mensagem próximo a ela indicando a queda de um processo servidor ou mesmo algum outro erro relevante a questão? Algo como terminating connection because of crash of another server process ou traduzindo finalizando conexão por causa de uma queda de um outro processo servidor *Não* Minha recomendação, para garantir que o processo server não caia é usar o -DLINUX_OOM_SCORE_ADJ=0 Vide: http://www.postgresql.org/docs/current/static/kernel-resources.html#LINUX-MEMORY-OVERCOMMIT -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Minha recomendação, para garantir que o processo server não caia é usar o -DLINUX_OOM_SCORE_ADJ=0 *O processo server não cai* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Em 9 de julho de 2013 11:25, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: (ii) qual o valor do parâmetro do kernel vm.overcommit_ratio? sysctl vm.overcommit_ratio vm.overcommit_ratio = 50 Ahá!!! Vale à pena aumentar para 80 ou mesmo 100. Vale à pena pesquisar como o parâmetro funciona. Note que aumentar este parâmetro só vale para servidores dedicados. Se tiver algum outro serviço rodando junto, tem que avaliar. Sinceramente, não sei se isso resolveria meu problema, pois não está nem perto de estourar a memória RAM, nem entrou no swap ainda. O servidor é dedicado. Eu tô achando que isso tem a ver com o hibernate e as operações demoradas idle in transaction que ele faz. Com este valor em 50 não vai entrar no Swap nunca!!! Leia sobre o parâmetro... resumindo ele diz que o usuário postgres pode usar no máximo 50% da memória total. Eu sei que parece idiota... mas existe toda uma polêmica em torno disso que não vou discutir agora. Por isso num servidor dedicado vale à pena aumentar para 80% ou até mais. -- Atenciosamente, Fábio Telles Rodriguez blog: http:// http://www.midstorm.org/~telles/shttp://tellesr.wordpress.com/ avepoint.blog.br e-mail / gtalk / MSN: fabio.tel...@gmail.com Skype: fabio_telles Timbira - A empresa brasileira de Postgres http://www.timbira.com.br ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Por coincidância, um pouco antes disso, começou a dar o out of memory free -m total used free sharedbuffers cached Mem: 32110 25108 7002 0 48 13086 -/+ buffers/cache: 11972 20137 Swap: 2559 11 2548 Vamos reiniciar o postgres pq a tendência a partir de agora é deteriorar o banco. Fiz sysctl -w vm.overcommit_ratio=100 Em 9 de julho de 2013 11:33, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: Minha recomendação, para garantir que o processo server não caia é usar o -DLINUX_OOM_SCORE_ADJ=0 *O processo server não cai* ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
On 09-07-2013 11:27, Luiz Carlos L. Nogueira Jr. wrote: Esse EXPLAIN foi obtido no mesmo banco de dados que ocorreu o problema? Não me parece o mesmo do TopMemoryContext. *Pior que é.* Hmm... tenho 3 hipóteses (nesta ordem): (i) configuração inadequada do overcommit (vamos ver se a mudança para um dos valores sugeridos é efetiva) e OOM killer; (ii) problema de hardware (analise a memória); (iii) bug no postgres (neste último caso, seria necessário um caso de teste com dados sintéticos ou reais que possa ser reproduzido em outras máquinas). Repetindo, como está o load da máquina no momento do problema? -- Euler Taveira 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] Como analisar a causa out of memory?
Repetindo, como está o load da máquina no momento do problema? *Qual comando você quer que use? Sou meio verde em linux* Em 9 de julho de 2013 11:54, Euler Taveira eu...@timbira.com.br escreveu: On 09-07-2013 11:27, Luiz Carlos L. Nogueira Jr. wrote: Esse EXPLAIN foi obtido no mesmo banco de dados que ocorreu o problema? Não me parece o mesmo do TopMemoryContext. *Pior que é.* Hmm... tenho 3 hipóteses (nesta ordem): (i) configuração inadequada do overcommit (vamos ver se a mudança para um dos valores sugeridos é efetiva) e OOM killer; (ii) problema de hardware (analise a memória); (iii) bug no postgres (neste último caso, seria necessário um caso de teste com dados sintéticos ou reais que possa ser reproduzido em outras máquinas). Repetindo, como está o load da máquina no momento do problema? -- Euler Taveira 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Deixa começar a dar problema de novo que vejo. 2 horas depois do overcommit_ratio e não deu mais. Vamos esperar. Em 9 de julho de 2013 12:00, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: Repetindo, como está o load da máquina no momento do problema? *Qual comando você quer que use? Sou meio verde em linux* Em 9 de julho de 2013 11:54, Euler Taveira eu...@timbira.com.brescreveu: On 09-07-2013 11:27, Luiz Carlos L. Nogueira Jr. wrote: Esse EXPLAIN foi obtido no mesmo banco de dados que ocorreu o problema? Não me parece o mesmo do TopMemoryContext. *Pior que é.* Hmm... tenho 3 hipóteses (nesta ordem): (i) configuração inadequada do overcommit (vamos ver se a mudança para um dos valores sugeridos é efetiva) e OOM killer; (ii) problema de hardware (analise a memória); (iii) bug no postgres (neste último caso, seria necessário um caso de teste com dados sintéticos ou reais que possa ser reproduzido em outras máquinas). Repetindo, como está o load da máquina no momento do problema? -- Euler Taveira 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 ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Em 9 de julho de 2013 13:53, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: Deixa começar a dar problema de novo que vejo. 2 horas depois do overcommit_ratio e não deu mais. Vamos esperar. Sua consulta utiliza a função crosstab ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Charles, *Não* Em 9 de julho de 2013 14:05, Charles Viana charles.vi...@gmail.comescreveu: Em 9 de julho de 2013 13:53, Luiz Carlos L. Nogueira Jr. lcnogueir...@gmail.com escreveu: Deixa começar a dar problema de novo que vejo. 2 horas depois do overcommit_ratio e não deu mais. Vamos esperar. Sua consulta utiliza a função crosstab ? ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
Pessoal, Apesar de eu não ter acreditado, parece que resolveu mudei o overcommit_ratio de 50 pra 100 e 6 horas sem out of memory Agradecido a todos envolvidos. ___ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
Re: [pgbr-geral] Como analisar a causa out of memory?
On 09-07-2013 17:55, Luiz Carlos L. Nogueira Jr. wrote: Pessoal, Apesar de eu não ter acreditado, parece que resolveu mudei o overcommit_ratio de 50 pra 100 e 6 horas sem out of memory Eu não recomendaria utilizar 100 (apesar que alguns artigos recomendarem). Eu deixaria alguma memória para ser utilizada pelo SO e alguma outra aplicação acessório. Por isso, eu recomendaria *não* utilizar 100 mas um valor próximo. -- Euler Taveira 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