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 >>>> <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: [<ffffffff810d40c1>] ? cpuset_print_task_mems_allowed >>>>> +0x91/0xb0 >>>>> kernel: [<ffffffff81127300>] ? dump_header+0x90/0x1b0 >>>>> kernel: [<ffffffff8122eb0c>] ? security_real_capable_noaudit+0x3c/0x70 >>>>> kernel: [<ffffffff81127782>] ? oom_kill_process+0x82/0x2a0 >>>>> kernel: [<ffffffff811276c1>] ? select_bad_process+0xe1/0x120 >>>>> kernel: [<ffffffff81127bc0>] ? out_of_memory+0x220/0x3c0 >>>>> kernel: [<ffffffff811344df>] ? __alloc_pages_nodemask+0x89f/0x8d0 >>>>> kernel: [<ffffffff8116c79a>] ? alloc_pages_vma+0x9a/0x150 >>>>> kernel: [<ffffffff8114f6fd>] ? handle_pte_fault+0x73d/0xb00 >>>>> kernel: [<ffffffff8116c69a>] ? alloc_pages_current+0xaa/0x110 >>>>> kernel: [<ffffffff8109eb00>] ? autoremove_wake_function+0x0/0x40 >>>>> kernel: [<ffffffff8114fcea>] ? handle_mm_fault+0x22a/0x300 >>>>> kernel: [<ffffffff8104d0d8>] ? __do_page_fault+0x138/0x480 >>>>> kernel: [<ffffffff8144a25e>] ? sys_recvfrom+0xee/0x180 >>>>> kernel: [<ffffffff8152ae7e>] ? mutex_lock+0x1e/0x50 >>>>> kernel: [<ffffffff8118e2ec>] ? generic_file_llseek_size+0x8c/0xd0 >>>>> kernel: [<ffffffff8152ffde>] ? do_page_fault+0x3e/0xa0 >>>>> kernel: [<ffffffff8152d395>] ? 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 do tipo, será Noperações * número de usuários executando * work_mem, então facilmente vc irá estourar o seu limite. > >>>> 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 >> >> -- >> 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 >
_______________________________________________ pgbr-geral mailing list pgbr-geral@listas.postgresql.org.br https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
