Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-17 Por tôpico Cleiton Luiz Domazak 
2017-05-16 22:23 GMT-03:00 Franklin Anderson de Oliveira Souza <
frankli...@gmail.com>:



> Eh um sistema legado nao tem como mexer, o servidor fica com uma media de
> 160 conexoes abertas em sua maioria idle. acho que por enquanto isso nao e
> um problema serio !
>
> Quanto as minha duvida achei varias referencias no historico desde grupo,
> eu devia ter pesquisado antes de enviar este email  !!! Ja me ajudou ehehehe
>
> Em 16 de maio de 2017 21:20, Francisco Porfirio <
> francisco.porfi...@gmail.com> escreveu:
>
>>
>> Em ter, 16 de mai de 2017 às 21:38, Franklin Anderson de Oliveira Souza <
>> frankli...@gmail.com> escreveu:
>>
>>> fui incrementando ao longo dos meses, com esse valor os arquivos
>>> temporario ($PGDTA/base/pgsql_tmp/) diminuiram bastante !
>>>
>> Considere revisar suas querys no lugar de incrementar desta forma o
>> work_mem.
>>
>> Escrita de tempfile em grande quantidade não é algo muito interessante, e
>> se usar demais a work_mem você ocupa toda a memória só com ela.
>>
>> Masss... Se ainda assim você precisar disso tudo, imagino que precisará
>> rever a memória do teu Servidor,  e os parâmetros de memória do Postgres/SO
>>
>> Reforço que eu me concentraria em verificar como  poderia baixar a
>> work_mem
>>
>>>
>>> Em 16 de maio de 2017 20:17, Francisco Porfirio <
>>> francisco.porfi...@gmail.com> escreveu:
>>>

 Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza
  escreveu:

> Ola caros amigos, desculpe a falta de acentuacao !!
>
> Tenho um servidor postgresql que com uma frequencia quase que diaria o
> mesmo altera para o estado de recovery, observando o log do postgresql
> encontrei o seguinte trecho:
>
> -
> LOG:  server process (PID 2529) was terminated by signal 9: Killed
> DETAIL:  Failed process was running: select..
> LOG:  terminating any other active server processes
> WARNING:  terminating connection because of crash of another server
> process
> DETAIL:  The postmaster has commanded this server process to roll back
> the current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT:  In a moment you should be able to reconnect to the database and
> repeat your command.
> -
>
> Em seguida observando o log do CentOS encontrei o seguinte:
>
> -
> kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
> oom_adj=0, oom_score_adj=0
> kernel: postmaster cpuset=/ mems_allowed=0
> kernel: Pid: 51831, comm: postmaster Not tainted
> 2.6.32-504.8.1.el6.x86_64 #1
> kernel: Call Trace:
> kernel: [] ? cpuset_print_task_mems_allowed
> +0x91/0xb0
> kernel: [] ? dump_header+0x90/0x1b0
> kernel: [] ? security_real_capable_noaudit+0x3c/0x70
> kernel: [] ? oom_kill_process+0x82/0x2a0
> kernel: [] ? select_bad_process+0xe1/0x120
> kernel: [] ? out_of_memory+0x220/0x3c0
> kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
> kernel: [] ? alloc_pages_vma+0x9a/0x150
> kernel: [] ? handle_pte_fault+0x73d/0xb00
> kernel: [] ? alloc_pages_current+0xaa/0x110
> kernel: [] ? autoremove_wake_function+0x0/0x40
> kernel: [] ? handle_mm_fault+0x22a/0x300
> kernel: [] ? __do_page_fault+0x138/0x480
> kernel: [] ? sys_recvfrom+0xee/0x180
> kernel: [] ? mutex_lock+0x1e/0x50
> kernel: [] ? generic_file_llseek_size+0x8c/0xd0
> kernel: [] ? do_page_fault+0x3e/0xa0
> kernel: [] ? page_fault+0x25/0x30
> -
>
> Pesquisando encontrei na documentacao uma referencia a esse
> problema[1] que mostra claramente que a funcao do kernel esta matando o
> postmaster[2] deixando-o em recovery.
>
> O que eu fiz em um primeiro momento foi incrementar a memoria e depois
> em um horario mais apropriado efetuarei as alteracoes sugeridas na
> documentacao(vm.overcommit_memory, vm.overcommit_ratio, shmmax).
>
> Perguntas:
>
> 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
> passaram por isso e que decisoes tomaram?
> 2- Estou com dificuldade de mensurar o consumo de memoria do
> postgresql, qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas
> hoje disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo
> que 1/3 equivale no htop com a cor verde e 60% com a cor amarela[3], isso
> significa que esta usando toda a memoria ?!
>

Use o pg_activity para isso.

>
> Dados adicionais:
> Centos 6.6
> Postgresql 9.3.6
> kernel 2.6.32
>
> effective_cache_size = 6GB
> shared_buffers = 6GB
> work_mem = 576MB
>
 Esse valor é muito elevado, assim como o amigo já disse, é melhor vc
revisar as queries do que utilizar esse parâmetro tão alto. Caso a sua
query executa mais de 1 operação de ordenação e coisas

Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-16 Por tôpico Franklin Anderson de Oliveira Souza 
Eh um sistema legado nao tem como mexer, o servidor fica com uma media de
160 conexoes abertas em sua maioria idle. acho que por enquanto isso nao e
um problema serio !

Quanto as minha duvida achei varias referencias no historico desde grupo,
eu devia ter pesquisado antes de enviar este email  !!! Ja me ajudou ehehehe

Em 16 de maio de 2017 21:20, Francisco Porfirio <
francisco.porfi...@gmail.com> escreveu:

>
> Em ter, 16 de mai de 2017 às 21:38, Franklin Anderson de Oliveira Souza <
> frankli...@gmail.com> escreveu:
>
>> fui incrementando ao longo dos meses, com esse valor os arquivos
>> temporario ($PGDTA/base/pgsql_tmp/) diminuiram bastante !
>>
> Considere revisar suas querys no lugar de incrementar desta forma o
> work_mem.
>
> Escrita de tempfile em grande quantidade não é algo muito interessante, e
> se usar demais a work_mem você ocupa toda a memória só com ela.
>
> Masss... Se ainda assim você precisar disso tudo, imagino que precisará
> rever a memória do teu Servidor,  e os parâmetros de memória do Postgres/SO
>
> Reforço que eu me concentraria em verificar como  poderia baixar a work_mem
>
>>
>> Em 16 de maio de 2017 20:17, Francisco Porfirio <
>> francisco.porfi...@gmail.com> escreveu:
>>
>>>
>>> Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza <
>>> frankli...@gmail.com> escreveu:
>>>
 Ola caros amigos, desculpe a falta de acentuacao !!

 Tenho um servidor postgresql que com uma frequencia quase que diaria o
 mesmo altera para o estado de recovery, observando o log do postgresql
 encontrei o seguinte trecho:

 -
 LOG:  server process (PID 2529) was terminated by signal 9: Killed
 DETAIL:  Failed process was running: select..
 LOG:  terminating any other active server processes
 WARNING:  terminating connection because of crash of another server
 process
 DETAIL:  The postmaster has commanded this server process to roll back
 the current transaction and exit, because another server process exited
 abnormally and possibly corrupted shared memory.
 HINT:  In a moment you should be able to reconnect to the database and
 repeat your command.
 -

 Em seguida observando o log do CentOS encontrei o seguinte:

 -
 kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
 oom_adj=0, oom_score_adj=0
 kernel: postmaster cpuset=/ mems_allowed=0
 kernel: Pid: 51831, comm: postmaster Not tainted
 2.6.32-504.8.1.el6.x86_64 #1
 kernel: Call Trace:
 kernel: [] ? cpuset_print_task_mems_allowed+0x91/0xb0
 kernel: [] ? dump_header+0x90/0x1b0
 kernel: [] ? security_real_capable_noaudit+0x3c/0x70
 kernel: [] ? oom_kill_process+0x82/0x2a0
 kernel: [] ? select_bad_process+0xe1/0x120
 kernel: [] ? out_of_memory+0x220/0x3c0
 kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
 kernel: [] ? alloc_pages_vma+0x9a/0x150
 kernel: [] ? handle_pte_fault+0x73d/0xb00
 kernel: [] ? alloc_pages_current+0xaa/0x110
 kernel: [] ? autoremove_wake_function+0x0/0x40
 kernel: [] ? handle_mm_fault+0x22a/0x300
 kernel: [] ? __do_page_fault+0x138/0x480
 kernel: [] ? sys_recvfrom+0xee/0x180
 kernel: [] ? mutex_lock+0x1e/0x50
 kernel: [] ? generic_file_llseek_size+0x8c/0xd0
 kernel: [] ? do_page_fault+0x3e/0xa0
 kernel: [] ? page_fault+0x25/0x30
 -

 Pesquisando encontrei na documentacao uma referencia a esse problema[1]
 que mostra claramente que a funcao do kernel esta matando o postmaster[2]
 deixando-o em recovery.

 O que eu fiz em um primeiro momento foi incrementar a memoria e depois
 em um horario mais apropriado efetuarei as alteracoes sugeridas na
 documentacao(vm.overcommit_memory, vm.overcommit_ratio, shmmax).

 Perguntas:

 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
 passaram por isso e que decisoes tomaram?
 2- Estou com dificuldade de mensurar o consumo de memoria do
 postgresql, qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas
 hoje disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo
 que 1/3 equivale no htop com a cor verde e 60% com a cor amarela[3], isso
 significa que esta usando toda a memoria ?!

 Dados adicionais:
 Centos 6.6
 Postgresql 9.3.6
 kernel 2.6.32

 effective_cache_size = 6GB
 shared_buffers = 6GB
 work_mem = 576MB

>>>
>>> Me chamou muito atenção esse valor que você está usando na work_mem.
>>> Qual o seu max_connections?
>>>
>>> Com o Work_mem deste tamanho você pode estourar o uso da memória super
>>> rápido.
>>>


 [1] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
 [2] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
 [3] - https://serverfault.com/questions/180711/what-exactly-

Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-16 Por tôpico Francisco Porfirio 
Em ter, 16 de mai de 2017 às 21:38, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> fui incrementando ao longo dos meses, com esse valor os arquivos
> temporario ($PGDTA/base/pgsql_tmp/) diminuiram bastante !
>
Considere revisar suas querys no lugar de incrementar desta forma o
work_mem.

Escrita de tempfile em grande quantidade não é algo muito interessante, e
se usar demais a work_mem você ocupa toda a memória só com ela.

Masss... Se ainda assim você precisar disso tudo, imagino que precisará
rever a memória do teu Servidor,  e os parâmetros de memória do Postgres/SO

Reforço que eu me concentraria em verificar como  poderia baixar a work_mem

>
> Em 16 de maio de 2017 20:17, Francisco Porfirio <
> francisco.porfi...@gmail.com> escreveu:
>
>>
>> Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza <
>> frankli...@gmail.com> escreveu:
>>
>>> Ola caros amigos, desculpe a falta de acentuacao !!
>>>
>>> Tenho um servidor postgresql que com uma frequencia quase que diaria o
>>> mesmo altera para o estado de recovery, observando o log do postgresql
>>> encontrei o seguinte trecho:
>>>
>>> -
>>> LOG:  server process (PID 2529) was terminated by signal 9: Killed
>>> DETAIL:  Failed process was running: select..
>>> LOG:  terminating any other active server processes
>>> WARNING:  terminating connection because of crash of another server
>>> process
>>> DETAIL:  The postmaster has commanded this server process to roll back
>>> the current transaction and exit, because another server process exited
>>> abnormally and possibly corrupted shared memory.
>>> HINT:  In a moment you should be able to reconnect to the database and
>>> repeat your command.
>>> -
>>>
>>> Em seguida observando o log do CentOS encontrei o seguinte:
>>>
>>> -
>>> kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
>>> oom_adj=0, oom_score_adj=0
>>> kernel: postmaster cpuset=/ mems_allowed=0
>>> kernel: Pid: 51831, comm: postmaster Not tainted
>>> 2.6.32-504.8.1.el6.x86_64 #1
>>> kernel: Call Trace:
>>> kernel: [] ? cpuset_print_task_mems_allowed+0x91/0xb0
>>> kernel: [] ? dump_header+0x90/0x1b0
>>> kernel: [] ? security_real_capable_noaudit+0x3c/0x70
>>> kernel: [] ? oom_kill_process+0x82/0x2a0
>>> kernel: [] ? select_bad_process+0xe1/0x120
>>> kernel: [] ? out_of_memory+0x220/0x3c0
>>> kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
>>> kernel: [] ? alloc_pages_vma+0x9a/0x150
>>> kernel: [] ? handle_pte_fault+0x73d/0xb00
>>> kernel: [] ? alloc_pages_current+0xaa/0x110
>>> kernel: [] ? autoremove_wake_function+0x0/0x40
>>> kernel: [] ? handle_mm_fault+0x22a/0x300
>>> kernel: [] ? __do_page_fault+0x138/0x480
>>> kernel: [] ? sys_recvfrom+0xee/0x180
>>> kernel: [] ? mutex_lock+0x1e/0x50
>>> kernel: [] ? generic_file_llseek_size+0x8c/0xd0
>>> kernel: [] ? do_page_fault+0x3e/0xa0
>>> kernel: [] ? page_fault+0x25/0x30
>>> -
>>>
>>> Pesquisando encontrei na documentacao uma referencia a esse problema[1]
>>> que mostra claramente que a funcao do kernel esta matando o postmaster[2]
>>> deixando-o em recovery.
>>>
>>> O que eu fiz em um primeiro momento foi incrementar a memoria e depois
>>> em um horario mais apropriado efetuarei as alteracoes sugeridas na
>>> documentacao(vm.overcommit_memory, vm.overcommit_ratio, shmmax).
>>>
>>> Perguntas:
>>>
>>> 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
>>> passaram por isso e que decisoes tomaram?
>>> 2- Estou com dificuldade de mensurar o consumo de memoria do postgresql,
>>> qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas hoje
>>> disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo que 1/3
>>> equivale no htop com a cor verde e 60% com a cor amarela[3], isso significa
>>> que esta usando toda a memoria ?!
>>>
>>> Dados adicionais:
>>> Centos 6.6
>>> Postgresql 9.3.6
>>> kernel 2.6.32
>>>
>>> effective_cache_size = 6GB
>>> shared_buffers = 6GB
>>> work_mem = 576MB
>>>
>>
>> Me chamou muito atenção esse valor que você está usando na work_mem. Qual
>> o seu max_connections?
>>
>> Com o Work_mem deste tamanho você pode estourar o uso da memória super
>> rápido.
>>
>>>
>>>
>>> [1] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
>>> [2] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
>>> [3] -
>>> https://serverfault.com/questions/180711/what-exactly-do-the-colors-in-htop-status-bars-mean
>>>
>>> --
>>> foobar
>>> ___
>>> pgbr-geral mailing list
>>> pgbr-geral@listas.postgresql.org.br
>>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>> --
>> Atenciosamente
>> Francisco Porfirio Ribeiro Neto
>>
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>>
>
>
>
> --
> foobar
>

Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-16 Por tôpico Franklin Anderson de Oliveira Souza 
fui incrementando ao longo dos meses, com esse valor os arquivos temporario
($PGDTA/base/pgsql_tmp/) diminuiram bastante !

Em 16 de maio de 2017 20:17, Francisco Porfirio <
francisco.porfi...@gmail.com> escreveu:

>
> Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza <
> frankli...@gmail.com> escreveu:
>
>> Ola caros amigos, desculpe a falta de acentuacao !!
>>
>> Tenho um servidor postgresql que com uma frequencia quase que diaria o
>> mesmo altera para o estado de recovery, observando o log do postgresql
>> encontrei o seguinte trecho:
>>
>> -
>> LOG:  server process (PID 2529) was terminated by signal 9: Killed
>> DETAIL:  Failed process was running: select..
>> LOG:  terminating any other active server processes
>> WARNING:  terminating connection because of crash of another server
>> process
>> DETAIL:  The postmaster has commanded this server process to roll back
>> the current transaction and exit, because another server process exited
>> abnormally and possibly corrupted shared memory.
>> HINT:  In a moment you should be able to reconnect to the database and
>> repeat your command.
>> -
>>
>> Em seguida observando o log do CentOS encontrei o seguinte:
>>
>> -
>> kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
>> oom_adj=0, oom_score_adj=0
>> kernel: postmaster cpuset=/ mems_allowed=0
>> kernel: Pid: 51831, comm: postmaster Not tainted
>> 2.6.32-504.8.1.el6.x86_64 #1
>> kernel: Call Trace:
>> kernel: [] ? cpuset_print_task_mems_allowed+0x91/0xb0
>> kernel: [] ? dump_header+0x90/0x1b0
>> kernel: [] ? security_real_capable_noaudit+0x3c/0x70
>> kernel: [] ? oom_kill_process+0x82/0x2a0
>> kernel: [] ? select_bad_process+0xe1/0x120
>> kernel: [] ? out_of_memory+0x220/0x3c0
>> kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
>> kernel: [] ? alloc_pages_vma+0x9a/0x150
>> kernel: [] ? handle_pte_fault+0x73d/0xb00
>> kernel: [] ? alloc_pages_current+0xaa/0x110
>> kernel: [] ? autoremove_wake_function+0x0/0x40
>> kernel: [] ? handle_mm_fault+0x22a/0x300
>> kernel: [] ? __do_page_fault+0x138/0x480
>> kernel: [] ? sys_recvfrom+0xee/0x180
>> kernel: [] ? mutex_lock+0x1e/0x50
>> kernel: [] ? generic_file_llseek_size+0x8c/0xd0
>> kernel: [] ? do_page_fault+0x3e/0xa0
>> kernel: [] ? page_fault+0x25/0x30
>> -
>>
>> Pesquisando encontrei na documentacao uma referencia a esse problema[1]
>> que mostra claramente que a funcao do kernel esta matando o postmaster[2]
>> deixando-o em recovery.
>>
>> O que eu fiz em um primeiro momento foi incrementar a memoria e depois em
>> um horario mais apropriado efetuarei as alteracoes sugeridas na documentacao
>> (vm.overcommit_memory, vm.overcommit_ratio, shmmax).
>>
>> Perguntas:
>>
>> 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
>> passaram por isso e que decisoes tomaram?
>> 2- Estou com dificuldade de mensurar o consumo de memoria do postgresql,
>> qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas hoje
>> disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo que 1/3
>> equivale no htop com a cor verde e 60% com a cor amarela[3], isso significa
>> que esta usando toda a memoria ?!
>>
>> Dados adicionais:
>> Centos 6.6
>> Postgresql 9.3.6
>> kernel 2.6.32
>>
>> effective_cache_size = 6GB
>> shared_buffers = 6GB
>> work_mem = 576MB
>>
>
> Me chamou muito atenção esse valor que você está usando na work_mem. Qual
> o seu max_connections?
>
> Com o Work_mem deste tamanho você pode estourar o uso da memória super
> rápido.
>
>>
>>
>> [1] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
>> [2] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
>> [3] - https://serverfault.com/questions/180711/what-exactly-
>> do-the-colors-in-htop-status-bars-mean
>>
>> --
>> foobar
>> ___
>> pgbr-geral mailing list
>> pgbr-geral@listas.postgresql.org.br
>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>
> --
> Atenciosamente
> Francisco Porfirio Ribeiro Neto
>
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>



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

Re: [pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-16 Por tôpico Francisco Porfirio 
Em ter, 16 de mai de 2017 às 17:50, Franklin Anderson de Oliveira Souza <
frankli...@gmail.com> escreveu:

> Ola caros amigos, desculpe a falta de acentuacao !!
>
> Tenho um servidor postgresql que com uma frequencia quase que diaria o
> mesmo altera para o estado de recovery, observando o log do postgresql
> encontrei o seguinte trecho:
>
> -
> LOG:  server process (PID 2529) was terminated by signal 9: Killed
> DETAIL:  Failed process was running: select..
> LOG:  terminating any other active server processes
> WARNING:  terminating connection because of crash of another server process
> DETAIL:  The postmaster has commanded this server process to roll back the
> current transaction and exit, because another server process exited
> abnormally and possibly corrupted shared memory.
> HINT:  In a moment you should be able to reconnect to the database and
> repeat your command.
> -
>
> Em seguida observando o log do CentOS encontrei o seguinte:
>
> -
> kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
> oom_adj=0, oom_score_adj=0
> kernel: postmaster cpuset=/ mems_allowed=0
> kernel: Pid: 51831, comm: postmaster Not tainted 2.6.32-504.8.1.el6.x86_64
> #1
> kernel: Call Trace:
> kernel: [] ? cpuset_print_task_mems_allowed+0x91/0xb0
> kernel: [] ? dump_header+0x90/0x1b0
> kernel: [] ? security_real_capable_noaudit+0x3c/0x70
> kernel: [] ? oom_kill_process+0x82/0x2a0
> kernel: [] ? select_bad_process+0xe1/0x120
> kernel: [] ? out_of_memory+0x220/0x3c0
> kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
> kernel: [] ? alloc_pages_vma+0x9a/0x150
> kernel: [] ? handle_pte_fault+0x73d/0xb00
> kernel: [] ? alloc_pages_current+0xaa/0x110
> kernel: [] ? autoremove_wake_function+0x0/0x40
> kernel: [] ? handle_mm_fault+0x22a/0x300
> kernel: [] ? __do_page_fault+0x138/0x480
> kernel: [] ? sys_recvfrom+0xee/0x180
> kernel: [] ? mutex_lock+0x1e/0x50
> kernel: [] ? generic_file_llseek_size+0x8c/0xd0
> kernel: [] ? do_page_fault+0x3e/0xa0
> kernel: [] ? page_fault+0x25/0x30
> -
>
> Pesquisando encontrei na documentacao uma referencia a esse problema[1]
> que mostra claramente que a funcao do kernel esta matando o postmaster[2]
> deixando-o em recovery.
>
> O que eu fiz em um primeiro momento foi incrementar a memoria e depois em
> um horario mais apropriado efetuarei as alteracoes sugeridas na 
> documentacao(vm.overcommit_memory,
> vm.overcommit_ratio, shmmax).
>
> Perguntas:
>
> 1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
> passaram por isso e que decisoes tomaram?
> 2- Estou com dificuldade de mensurar o consumo de memoria do postgresql,
> qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas hoje
> disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo que 1/3
> equivale no htop com a cor verde e 60% com a cor amarela[3], isso significa
> que esta usando toda a memoria ?!
>
> Dados adicionais:
> Centos 6.6
> Postgresql 9.3.6
> kernel 2.6.32
>
> effective_cache_size = 6GB
> shared_buffers = 6GB
> work_mem = 576MB
>

Me chamou muito atenção esse valor que você está usando na work_mem. Qual o
seu max_connections?

Com o Work_mem deste tamanho você pode estourar o uso da memória super
rápido.

>
>
> [1] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
> [2] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
> [3] -
> https://serverfault.com/questions/180711/what-exactly-do-the-colors-in-htop-status-bars-mean
>
> --
> foobar
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

-- 
Atenciosamente
Francisco Porfirio Ribeiro Neto
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] oom-killer (out of memory killer) matando postmaster !

2017-05-16 Por tôpico Franklin Anderson de Oliveira Souza 
Ola caros amigos, desculpe a falta de acentuacao !!

Tenho um servidor postgresql que com uma frequencia quase que diaria o
mesmo altera para o estado de recovery, observando o log do postgresql
encontrei o seguinte trecho:

-
LOG:  server process (PID 2529) was terminated by signal 9: Killed
DETAIL:  Failed process was running: select..
LOG:  terminating any other active server processes
WARNING:  terminating connection because of crash of another server process
DETAIL:  The postmaster has commanded this server process to roll back the
current transaction and exit, because another server process exited
abnormally and possibly corrupted shared memory.
HINT:  In a moment you should be able to reconnect to the database and
repeat your command.
-

Em seguida observando o log do CentOS encontrei o seguinte:

-
kernel: postmaster invoked oom-killer: gfp_mask=0x280da, order=0,
oom_adj=0, oom_score_adj=0
kernel: postmaster cpuset=/ mems_allowed=0
kernel: Pid: 51831, comm: postmaster Not tainted 2.6.32-504.8.1.el6.x86_64
#1
kernel: Call Trace:
kernel: [] ? cpuset_print_task_mems_allowed+0x91/0xb0
kernel: [] ? dump_header+0x90/0x1b0
kernel: [] ? security_real_capable_noaudit+0x3c/0x70
kernel: [] ? oom_kill_process+0x82/0x2a0
kernel: [] ? select_bad_process+0xe1/0x120
kernel: [] ? out_of_memory+0x220/0x3c0
kernel: [] ? __alloc_pages_nodemask+0x89f/0x8d0
kernel: [] ? alloc_pages_vma+0x9a/0x150
kernel: [] ? handle_pte_fault+0x73d/0xb00
kernel: [] ? alloc_pages_current+0xaa/0x110
kernel: [] ? autoremove_wake_function+0x0/0x40
kernel: [] ? handle_mm_fault+0x22a/0x300
kernel: [] ? __do_page_fault+0x138/0x480
kernel: [] ? sys_recvfrom+0xee/0x180
kernel: [] ? mutex_lock+0x1e/0x50
kernel: [] ? generic_file_llseek_size+0x8c/0xd0
kernel: [] ? do_page_fault+0x3e/0xa0
kernel: [] ? page_fault+0x25/0x30
-

Pesquisando encontrei na documentacao uma referencia a esse problema[1] que
mostra claramente que a funcao do kernel esta matando o postmaster[2]
deixando-o em recovery.

O que eu fiz em um primeiro momento foi incrementar a memoria e depois em
um horario mais apropriado efetuarei as alteracoes sugeridas na
documentacao(vm.overcommit_memory,
vm.overcommit_ratio, shmmax).

Perguntas:

1 - Gostaria de saber de voces se me raciocinio esta correto, se ja
passaram por isso e que decisoes tomaram?
2- Estou com dificuldade de mensurar o consumo de memoria do postgresql,
qual a melhor abordagem ?! Pelo comando htop vejo dos 32 gigas hoje
disponiveis (antes era 24 aumentei para 32) 98% esta ocupada, sendo que 1/3
equivale no htop com a cor verde e 60% com a cor amarela[3], isso significa
que esta usando toda a memoria ?!

Dados adicionais:
Centos 6.6
Postgresql 9.3.6
kernel 2.6.32

effective_cache_size = 6GB
shared_buffers = 6GB
work_mem = 576MB


[1] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
[2] - https://www.postgresql.org/docs/9.3/static/kernel-resources.html
[3] -
https://serverfault.com/questions/180711/what-exactly-do-the-colors-in-htop-status-bars-mean

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