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 ?! >>>> >>>> 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 > > -- > 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
