Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Edson Lidorio 



On 24-04-2017 11:47, Fabrízio de Royes Mello wrote:


Em 24 de abril de 2017 11:06, Edson F. Lidorio > escreveu:

>
> Fabrízio bom dia,
>
> Para Debian, precisa também fazer alguma configuração adicional?
>

Com relação a SELinux?

--
   Fabrízio de Royes Mello 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

sim, e outras se possivél...
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Database is in recovery mode

2017-04-24 Por tôpico Felipe Pereira 
Em 24 de abril de 2017 16:46, Tiago José Adami  escreveu:

> Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello
>  escreveu:
> > 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
>
> Agradeço pela ajuda, Fabrízio.
>
> Inicialmente fiquei confuso porque no /var/log/messages não haviam
> entradas do OOM Killer. Mas durante a redação da resposta eu fui
> conferir se havia algo desta vez e lá estava o registro.
>
> Sobre o problema: não estava exatamente no overcommit_ratio = 50 [1]
> porque o outro parâmetro overcommit_memory estava no padrão heurístico
> - valor 0. A realidade era que o servidor estava no limite de
> utilização de memória. O total de memória em cache passou a ser
> reduzido a meros 1 ou 2 GBs pouco antes do OOM entrar em ação.
>
> Com mais de 96 conexões ativas e executando comandos SQL sem parar, em
> um momento os 16 GB de memória RAM chegaria no limite. A solução
> encontrada foi criar uma partição SWAP de 10 GB. Tão logo foi criada,
> passou a ser preenchida em até 30% nos momentos de maior utilização,
> sendo liberada nos momentos de "bonanza".
>
> Achei um artigo convincente que dá detalhes de como funcionam estes
> parâmetros do Kernel [2] dando exemplos, mas baseando-se na
> configuração overcommit_memory=2, o que limita de forma parametrizada
> o total que um processo pode alocar além do limite real.
>
> Talvez já esteja entrando em uma nova thread, mas quando falamos de um
> servidor dedicado do PostgreSQL, qual seria a recomendação? Tunar o
> overcommit conforme mostra o artigo [2] ou manter os padrões?
>
> [1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
> [2] http://engineering.pivotal.io/post/Virtual_memory_settings_
> in_Linux_-_The_problem_with_Overcommit/
>
> TIAGO J. ADAMI
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
>


Boa tarde Tiago,

Eu acho que estes parâmetros, servem para fazer o que você fez, ou seja,
dar uma sobrevida aos momentos de pico do seu servidor.

Caso eles não estejam configurados, o OOM poderá matar seus processos (como
você experimentou) ou (caso você configure os parâmetros de memória do
PostgreSQL para baixo) você poderá sofrer um erro de Out of Memory do
servidor para o client.

Em outras palavras, estamos apenas administrando recursos que já chegaram
ao seu limite, a verdadeira solução seria:

1. Realizar um tuning das queries para que elas utilizem menos memória
2. Aumentar a quantidade de memória RAM do servidor

Respondendo diretamente sua pergunta, eu gosto de tunar, pois assim você
tem a oportunidade de verificar o uso de swap (como você fez) e, sendo
constante, ter argumentos técnicos para recomendar a compra de mais RAM.

[]'s

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

Re: [pgbr-geral] Database is in recovery mode

2017-04-24 Por tôpico Tiago José Adami 
Em 20 de abril de 2017 18:10, Fabrízio de Royes Mello
 escreveu:
> 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

Agradeço pela ajuda, Fabrízio.

Inicialmente fiquei confuso porque no /var/log/messages não haviam
entradas do OOM Killer. Mas durante a redação da resposta eu fui
conferir se havia algo desta vez e lá estava o registro.

Sobre o problema: não estava exatamente no overcommit_ratio = 50 [1]
porque o outro parâmetro overcommit_memory estava no padrão heurístico
- valor 0. A realidade era que o servidor estava no limite de
utilização de memória. O total de memória em cache passou a ser
reduzido a meros 1 ou 2 GBs pouco antes do OOM entrar em ação.

Com mais de 96 conexões ativas e executando comandos SQL sem parar, em
um momento os 16 GB de memória RAM chegaria no limite. A solução
encontrada foi criar uma partição SWAP de 10 GB. Tão logo foi criada,
passou a ser preenchida em até 30% nos momentos de maior utilização,
sendo liberada nos momentos de "bonanza".

Achei um artigo convincente que dá detalhes de como funcionam estes
parâmetros do Kernel [2] dando exemplos, mas baseando-se na
configuração overcommit_memory=2, o que limita de forma parametrizada
o total que um processo pode alocar além do limite real.

Talvez já esteja entrando em uma nova thread, mas quando falamos de um
servidor dedicado do PostgreSQL, qual seria a recomendação? Tunar o
overcommit conforme mostra o artigo [2] ou manter os padrões?

[1] https://www.kernel.org/doc/Documentation/sysctl/vm.txt
[2] 
http://engineering.pivotal.io/post/Virtual_memory_settings_in_Linux_-_The_problem_with_Overcommit/

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

Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Leandro Guimarães Faria Corcete DUTRA 
Le 24 avril 2017 08:23:04 GMT-03:00, "Edson F. Lidorio"  
a écrit :
> 
>O problema, era o selinux do CentOS, desabilitei o selinux, apliquei as
>pemissões novamente e o PostgreSQL iniciou normalmente.

Com os problemas catastróficos de segurança recentemente aqui expostos, eu 
pensaria três vezes, antes de desabilitar segurança.



-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191 (Net)gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691 (Vivo) ICQ/AIM: aim:GoIM?screenname=61287803
BRAZIL GMT−3  MSN: msnim:chat?contact=lean...@dutra.fastmail.fm
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Fabrízio de Royes Mello 
Em 24 de abril de 2017 11:06, Edson F. Lidorio 
escreveu:
>
> Fabrízio bom dia,
>
> Para Debian, precisa também fazer alguma configuração adicional?
>

Com relação a SELinux?

--
   Fabrízio de Royes Mello 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] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Edson F. Lidorio 

Em 2017-04-24 09:39, Fabrízio de Royes Mello escreveu:

Em 24 de abril de 2017 08:23, Edson F. Lidorio 
escreveu:



O problema, era o selinux do CentOS, desabilitei o selinux  e

apliquei as pemissões novamente e o PostgreSQL iniciou normalmente.


Comandos usados:
# sudo /usr/sbin/setenforce 0
# sudo chown postgres /var/lib/pgsql/9.6/
#  sudo chown postgres:postgres /var/lib/pgsql/9.6/data
# chmod 700 /var/lib/pgsql/9.6/
# sudo systemctl start postgresql-9.6

Observação: Pesquisando no google, percebi que tem mais pessoa com

esse problema. É um problema com CentOS e PostgreSQL, que não se dao
muito bem.




Também já fiz isso inúmeras vezes, porém acredito que o correto
seria configurar adequadamente o SELinux conforme um pequeno exemplo
na doc do RHEL [1].

Att,

[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/sect-Managing_Confined_Services-PostgreSQL-Configuration_Examples.html
[1]

--
   Fabrízio de Royes Mello Timbira -
http://www.timbira.com.br/ [2]
   PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e
Treinamento

Links:
--
[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/sect-Managing_Confined_Services-PostgreSQL-Configuration_Examples.html
[2] 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


Fabrízio bom dia,

Para Debian, precisa também fazer alguma configuração adicional?

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

Re: [pgbr-geral] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Fabrízio de Royes Mello 
Em 24 de abril de 2017 08:23, Edson F. Lidorio 
escreveu:
>
> O problema, era o selinux do CentOS, desabilitei o selinux  e apliquei as
pemissões novamente e o PostgreSQL iniciou normalmente.
>
> Comandos usados:
> # sudo /usr/sbin/setenforce 0
> # sudo chown postgres /var/lib/pgsql/9.6/
> #  sudo chown postgres:postgres /var/lib/pgsql/9.6/data
> # chmod 700 /var/lib/pgsql/9.6/
> # sudo systemctl start postgresql-9.6
>
> Observação: Pesquisando no google, percebi que tem mais pessoa com esse
problema. É um problema com CentOS e PostgreSQL, que não se dao muito bem.
>

Também já fiz isso inúmeras vezes, porém acredito que o correto seria
configurar adequadamente o SELinux conforme um pequeno exemplo na doc do
RHEL [1].

Att,


[1]
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/6/html/Managing_Confined_Services/sect-Managing_Confined_Services-PostgreSQL-Configuration_Examples.html

--
   Fabrízio de Royes Mello 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] Database is in recovery mode

2017-04-24 Por tôpico Fabrízio de Royes Mello 
Em 24 de abril de 2017 08:53, Daniel Luiz da Silva 
escreveu:

> 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.
>
>
Bom dia Daniel,

Que bom que ajudo de alguma forma... assim estamos então cumprindo nosso
papel enquanto comunidade...

Falando sobre a Timbira, já possuímos treinamento OnLine de Tuning do
PostgreSQL [1] onde em uma parte do mesmo abordamos justamente do Sistema
Operacional, que no caso deste treinamento é o Linux (ainda não temos
preparado para Windows). Se tiver mais dúvidas sobre a timbira podes entrar
em contato via comerc...@timbira.com.br.

Att,


[1] https://www.sympla.com.br/postgresql-tuning__115174

-- 
   Fabrízio de Royes Mello 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] Database is in recovery mode

2017-04-24 Por tôpico Daniel Luiz da Silva 
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"  
Para: "Comunidade PostgreSQL Brasileira"  
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 < adam...@gmail.com > 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 
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] Recuperar Base PostgreSQL pasta data

2017-04-24 Por tôpico Edson F. Lidorio 
 

On 21-04-2017 19:47, Osvaldo Kussama wrote: 

> Em 21/04/2017, Edson Lidorio escreveu:
> 
>> Sim, é a mesma versão 9.6.2
> 
> Pelo que entendi de sua mensagem original o PostgreSQL não estava
> devidamente parado no momento do crash. Repare no item 1:
> 
> "The database server must be shut down in order to get a usable backup."
> 
> Osvaldo
> ___
> pgbr-geral mailing list
> pgbr-geral@listas.postgresql.org.br
> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral [1]

O problema, era o selinux do CentOS, desabilitei o selinux e apliquei as
pemissões novamente e o PostgreSQL iniciou normalmente.

 Comandos usados:
 # sudo /usr/sbin/setenforce 0
 # sudo chown postgres /var/lib/pgsql/9.6/
 # sudo chown postgres:postgres /var/lib/pgsql/9.6/data
 # chmod 700 /var/lib/pgsql/9.6/
 # sudo systemctl start postgresql-9.6

 Observação: Pesquisando no google, percebi que tem mais pessoa com esse
problema. É um problema com CentOS e PostgreSQL, que não se dao muito
bem.

 Obrigado a todos 

Links:
--
[1] 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