Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

2017-06-29 Por tôpico Euler Taveira 
Em 28 de junho de 2017 21:49, Euler Taveira  escreveu:

>
> O pg_dump faz um bloqueio (AccessShareLock) para cada tabela que irá
> copiar. Como ele faz isso numa única transação, o parâmetro
> max_locks_per_transaction deve ser no mínimo igual ao número de tabelas a
> serem copiadas.
>

Essa sentença ficou incorreta (possivelmente por falta de cafeína?). Quis
dizer que o valor de max_locks_per_transaction deve ser suficiente para que
o cálculo max_locks_per_transaction * (max_connections +
max_prepared_transactions) seja no mínimo igual ao número de tabelas a
serem copiadas. (Foi exatamente o que o Fabrizio disse no outro email).
Quanto ao cálculo correto:

max_locks_per_transaction * (max_connections + max_prepared_transactions) =
objetos_atuais

aumentando x locks para satisfazer o pg_dump teríamos:

max_locks_per_transaction' * (max_connections + max_prepared_transactions)
= objetos_atuais + x
max_locks_per_transaction' = (objetos_atuais + x) / (max_connections +
max_prepared_transactions)

Considerando os valores padrão (max_connections = 100;
max_prepared_transactions = 0 ; max_locks_per_transaction = 64),
objetos_atuais seria 6400. x = 181 esquemas x 233 tabelas = 42173.

max_locks_per_transaction' = (6400 + 42173) / (100 + 0) ~ 486

É sempre bom deixar uma margem de segurança porque
max_locks_per_transaction precisa de um reinício do serviço.


-- 
   Euler Taveira   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] ERROR: out of shared memory in pg_dump

2017-06-29 Por tôpico Fabrízio de Royes Mello 
Em 29 de junho de 2017 18:00, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:
>
>
> Fabrizio,
> obrigado pela sua reposta
> vou ajustar para 500, pois deu 432 o calculo e sei que esse banco pode
ser acrescentado mais schemas.(42000/50+64) + 64 = 432 .

Esqueci de mencionar que as "sequences" devem entrar no cálculo daquele
"número de tabelas" porque elas internamente são uma tabela.


> sobre sua duvida, hoje estamos fazendo dump como estrategia de backup, o
que está errado..(eu ja li o otimo artigo do Telles) #1.

Ok, mas como é a arquitetura desse seu database? Tipo cada schema seria
como um "cliente" ou algo do gênero?? Porque se cada schema pode ser
tratado isoladamente não teria porque vc fazer um dump de todo database em
um único pg_dump, vc poderia fazer um script para ler os schemas e fazer
dumps individuais por schema.

Vc poderia usar os Syncronized Snapshots [1] também pra não precisar ficar
fazendo esses ajustes e ter dados consistentes... obviamente que nao
conheço seu modelo e não sei se os objetos nos schemas tem dependencias
(FKs), então estou pensando em modelos com schemas isolados.


> pretendo nos próximos dias implantar backup físico\logico.

Ótimo


> como estamos com 5 servidores de banco de dados, vc teria alguma
ferramenta para recomendar que faça essa gerência de backup em vários
servidores e uma maneira mais facil?
>

Para backup físico recomendo vc dar uma olhada no pgBackRest [2] ou o
Barman [3].

Att,

[1]
https://www.postgresql.org/docs/9.5/static/functions-admin.html#FUNCTIONS-SNAPSHOT-SYNCHRONIZATION
[2] http://www.pgbackrest.org/
[3] http://www.pgbarman.org/

--
   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] ERROR: out of shared memory in pg_dump

2017-06-29 Por tôpico Douglas Fabiano Specht 
Em 29 de junho de 2017 17:45, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

>
> Em 29 de junho de 2017 11:35, Euler Taveira 
> escreveu:
> >
> > Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
> douglasfabi...@gmail.com> escreveu:
> >>>
> >>>
> >> Euler,
> >> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
> todos os schemas..?
> >
> >
> > É a quantidade de tabelas por execução do pg_dump. Então seria 181
> schemas x 233 tabelas.
> >
>
> Não é *exatamente* este valor porque o PostgreSQL cria um hash na memória
> compartilhada (TopMemoryContext) para alocar esses locks e o tamanho dela é
> definido por:
>
> max_locks_per_transaction * (max_connections + max_prepared_transactions)
>
> Quero dizer com isso que não é necessário colocar no
> "max_locks_per_transaction" o valor da multplicação que o Euler comentou
> que é demasiado e ocupara memória compartilhada sem necessidade. Em um
> cenário como o seu que são muitas tabelas para efetuar dump poderi então
> fazer o seguinte cálculo:
>
> (numero_de_tabelas / (max_connections + max_prepared_transactions)) + 64
>
> Desta forma quando rodar o dump vc terá slots suficientes para locks e
> também a folga de 64 para sua aplicacao continuar funcionando... porém eis
> que me surge uma dúvida??
>
> - Vc precisa fazer um dump de TODOS schemas ao mesmo tempo???
>
>

> Att,
>
> --
>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
>

Fabrizio,
obrigado pela sua reposta
vou ajustar para 500, pois deu 432 o calculo e sei que esse banco pode ser
acrescentado mais schemas.(42000/50+64) + 64 = 432 .
sobre sua duvida, hoje estamos fazendo dump como estrategia de backup, o
que está errado..(eu ja li o otimo artigo do Telles) #1.
pretendo nos próximos dias implantar backup físico\logico.
como estamos com 5 servidores de banco de dados, vc teria alguma ferramenta
para recomendar que faça essa gerência de backup em vários servidores e uma
maneira mais facil?

#1:https://savepoint.blog.br/2010/05/06/dump-nao-e-backup/




-- 

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

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

2017-06-29 Por tôpico Fabrízio de Royes Mello 
Em 29 de junho de 2017 11:35, Euler Taveira  escreveu:
>
> Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:
>>>
>>>
>> Euler,
>> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
todos os schemas..?
>
>
> É a quantidade de tabelas por execução do pg_dump. Então seria 181
schemas x 233 tabelas.
>

Não é *exatamente* este valor porque o PostgreSQL cria um hash na memória
compartilhada (TopMemoryContext) para alocar esses locks e o tamanho dela é
definido por:

max_locks_per_transaction * (max_connections + max_prepared_transactions)

Quero dizer com isso que não é necessário colocar no
"max_locks_per_transaction" o valor da multplicação que o Euler comentou
que é demasiado e ocupara memória compartilhada sem necessidade. Em um
cenário como o seu que são muitas tabelas para efetuar dump poderi então
fazer o seguinte cálculo:

(numero_de_tabelas / (max_connections + max_prepared_transactions)) + 64

Desta forma quando rodar o dump vc terá slots suficientes para locks e
também a folga de 64 para sua aplicacao continuar funcionando... porém eis
que me surge uma dúvida??

- Vc precisa fazer um dump de TODOS schemas ao mesmo tempo???


Att,

--
   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] ERROR: out of shared memory in pg_dump

2017-06-29 Por tôpico Euler Taveira 
Em 28 de junho de 2017 22:35, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

>
>> Euler,
> esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
> todos os schemas..?
>

É a quantidade de tabelas por execução do pg_dump. Então seria 181 schemas
x 233 tabelas.


-- 
   Euler Taveira   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] ERROR: out of shared memory in pg_dump

2017-06-28 Por tôpico Douglas Fabiano Specht 
Em 28 de junho de 2017 21:49, Euler Taveira  escreveu:

> Em 28 de junho de 2017 17:45, Douglas Fabiano Specht <
> douglasfabi...@gmail.com> escreveu:
>
>>
>> Ocorre que ao efetuar um dump, está dando o seguinte erro:
>>
>> ERROR:  out of shared memory pg_dump
>> WARNING:  out of shared memory
>> HINT increase max_locks_per_transaction
>>
>
> O pg_dump faz um bloqueio (AccessShareLock) para cada tabela que irá
> copiar. Como ele faz isso numa única transação, o parâmetro
> max_locks_per_transaction deve ser no mínimo igual ao número de tabelas a
> serem copiadas. Isso é necessário para não permitir remoção ou alteração do
> esquema enquanto a cópia estiver sendo feita. Ao alterar
> max_locks_per_transaction você precisará fazer um restart.
>
> Euler,
esse valor é para cada schema 233 tabelas ou 41000 tabelas no geral de
todos os schemas..?

-- 
>Euler Taveira   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
>



-- 

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

Re: [pgbr-geral] ERROR: out of shared memory in pg_dump

2017-06-28 Por tôpico Euler Taveira 
Em 28 de junho de 2017 17:45, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

>
> Ocorre que ao efetuar um dump, está dando o seguinte erro:
>
> ERROR:  out of shared memory pg_dump
> WARNING:  out of shared memory
> HINT increase max_locks_per_transaction
>

O pg_dump faz um bloqueio (AccessShareLock) para cada tabela que irá
copiar. Como ele faz isso numa única transação, o parâmetro
max_locks_per_transaction deve ser no mínimo igual ao número de tabelas a
serem copiadas. Isso é necessário para não permitir remoção ou alteração do
esquema enquanto a cópia estiver sendo feita. Ao alterar
max_locks_per_transaction você precisará fazer um restart.


-- 
   Euler Taveira   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] ERROR: out of shared memory in pg_dump

2017-06-28 Por tôpico Douglas Fabiano Specht 
Em 28 de junho de 2017 17:45, Douglas Fabiano Specht <
douglasfabi...@gmail.com> escreveu:

> Pessoal,
> depois dos erros que tivemos na semana passada, fizemos uma separação dos
> serviços do Postgres para 2 maquinas distintas.
> utilizei o Pgconfig.org para me recomendar e efetui as alterações
> necessárias conforme abaixo.
>
>
> # Generated by PGConfig 2.0 beta
> ## http://pgconfig.org
>
> # Memory Configuration
> shared_buffers = 3GB
> effective_cache_size = 9GB
> work_mem = 246MB
> maintenance_work_mem = 768MB
>
> # Checkpoint Related Configuration
> min_wal_size = 512MB
> max_wal_size = 2GB
> checkpoint_completion_target = 0.7
> wal_buffers = 16MB
>
> # Network Related Configuration
> listen_addresses = '*'
> max_connections = 50
>
> dados do servidor
> Debian 8.7
> Postgres 9.5.7
> Memoria do servidor 16GB
>
> Ocorre que ao efetuar um dump, está dando o seguinte erro:
>
> ERROR:  out of shared memory pg_dump
> WARNING:  out of shared memory
> HINT increase max_locks_per_transaction
>
> alguem poderia me ajudar nesse caso?
> nao alterei outras configurações.
> --
>
> Douglas Fabiano Specht
>

Pessoal,
para complementar essa base é muito grande em objetos, mas nao em dados,
temos 181 schemas com 233 tabelas em cada uma delas, o que da mais de
41.000 tabelas.
vi outros erros na internert que falam qdo existe muitos objetos, entao
pensei em quebrar esse dump e fazer algo dinamico, ou seja ler todos os
schemas e dividir em 3 ou 4 arquivos. o que acham?


-- 

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