Bom dia, Fabrízio, Acho esse assunto muito interessante, se houvesse um treinamento na Timbira sobre essa relação do Postgres com memória linux internamente, ou seja, calcular no momento como está o buffer cache, shared memory e média de overcommit, explorando melhor o arquivo vminfo do linux, eu aderia. Obrigado por responder esses tipos de tópicos sempre me ajuda bastante.
Abraço. De: "Fabrízio de Royes Mello" <[email protected]> Para: "Comunidade PostgreSQL Brasileira" <[email protected]> Enviadas: Quinta-feira, 20 de abril de 2017 18:10:08 Assunto: Re: [pgbr-geral] Database is in recovery mode Em 20 de abril de 2017 17:55, Tiago José Adami < [email protected] > escreveu: > > > > > Nem preciso te dizer que deves atualizar pra 9.4.11... > > Sabia que a primeira coisa que me diriam seria para atualizar ;) > > E concordo plenamente, mas a instalação é do repositório oficial da > Amazon que está desatualizado. Por enquanto uma GMUD para incluir > outro repo ainda não foi discutida. > Faz parte... > >> (...) > >> WARNING,57P02,"terminating connection because of crash of another > >> server process","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.","In a > >> moment you should be able to reconnect to the database and repeat your > >> command." > >> (...) > > > > Só tem essa informação no LOG?? Essa informação que vc pegou não é a causa > > e > > sim o efeito... vasculhe seu log por mais informações. > > Estou vasculhando pela 3a vez os logs, mas não há nenhuma informação > adicional. Estas mensagens ocorre logo após a execução de um SQL > SELECT qualquer. > Isso é sintoma mesmo de OOMKiller como o colega Felipe mencionou anteriormente. > > > > Eu arrisco que vc pode estar passando por algum "overcommit_memory" ou > > coisa > > parecida. Esse linux tem swap e como está o overcommit_memory? > > O OOM e overcommit estão com os valores padrão > > vm.oom_dump_tasks = 1 > vm.oom_kill_allocating_task = 0 > vm.overcommit_kbytes = 0 > vm.overcommit_memory = 0 > vm.overcommit_ratio = 50 > Bingo... > O servidor não tem Swap. > Vejo que não é esse seu problema, mas não custaria nada ter uma área de swap para alguma emergência. > Estava quase enviando o e-mail quando fui checar novamente o > /var/log/messages. Agradeço também ao colega Felipe Pereira (obrigado > pelas dicas), desta vez encontrei a causa mortis: > > Apr 20 18:00:47 ip-172-16-4-27 kernel: [238117.075735] Killed process > 2485 (postmaster) total-vm:2124064kB, anon-rss:272232kB, file-rss:4kB, > shmem-rss:1588240kB > Bingo... > A questão é: mesmo tendo uma quantidade de memória livre que fica > sempre entre 3 e 4 GB (livre, o resto é cache + usada), como isso pode > estar acontecendo? > Isso é por conta do "overcommit_ratio = 50" que indica que foi solicitado alocar mais memória que o "total de swap + 50% da RAM" [1] ... como vc nao tem swap entao ele tentou alocar mais que RAM/2 e o kernel matou... Att, [1] https://www.kernel.org/doc/Documentation/vm/overcommit-accounting -- Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/ PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento _______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
