Re: [pgbr-geral] CPU em 100%

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-15 8:55 GMT-03:00 Tales Costa :
> Em 9 de junho de 2016 12:33, Guimarães Faria Corcete DUTRA, Leandro
>  escreveu:
>>
>> Não deixas o autovaccuum?
>
> Deixei um tempo desativado para alguns testes, mas costumo deixar ele ativo.

Bom.


> A alguma vantagem e executar manualmente e deixar o autovacuum ativo ?

Pelo contrário.  O recomendado é deixar ativo e só executar
manualmente em caso de necessidade clara, em situações excepcionais.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] CPU em 100%

[Tales Costa]

Em 9 de junho de 2016 12:33, Guimarães Faria Corcete DUTRA, Leandro <
l...@dutras.org> escreveu:

> 2016-06-09 9:12 GMT-03:00 Tales Costa :
> > Em relação ao vacuum, executo 1 vez por semana (analise e limpeza),
> porém não
> > surtiu efeito no uso de CPU.
>
> Não deixas o autovaccuum?
>
> Procure cortar o texto ao qual não responde, como saudações e assinaturas.
>
>
Guimarães,

Deixei um tempo desativado para alguns testes, mas costumo deixar ele
ativo.
A alguma vantagem e executar manualmente e deixar o autovacuum ativo ?

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

Re: [pgbr-geral] CPU em 100%

[Guimarães Faria Corcete DUTRA , Leandro]

2016-06-09 9:12 GMT-03:00 Tales Costa :
> Em relação ao vacuum, executo 1 vez por semana (analise e limpeza), porém
> surtiu efeito no uso de CPU.

Não deixas o autovaccuum?

Procure cortar o texto ao qual não responde, como saudações e assinaturas.


-- 
skype:leandro.gfc.dutra?chat  Yahoo!: ymsgr:sendIM?lgcdutra
+55 (61) 3546 7191  gTalk: xmpp:leand...@jabber.org
+55 (61) 9302 2691ICQ/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] CPU em 100%

[Tales Costa]

Em 6 de junho de 2016 10:22, Fabrízio de Royes Mello <
fabri...@timbira.com.br> escreveu:

> On 04-06-2016 12:13, Tales Costa wrote:
> > Boa tarde,
> >
> > De uns dias para cá estou enfrentando alguns problemas com um servidor
> > Postgresql + Zabbix. O pg está consumindo em muitos momentos 100% da CPU
> > do server, ocasionando o aumento da temperatura da mesma.
> >
> > Como não tenho experiência alguma com postgresql, estou na dúvida se o
> > problema é de hardware ou algo relacionado ao pg pois funciona
> > perfeitamente antes de migrar o servidor fisicamente de lugar e
> > atualizar a versão do PG e alguns outros pacotes.
> >
> > Observei que o aumento de CPU sempre ocorre quando é executado alguns
> > "select". Segue imagem do htop.
> >
> > Segue algumas informações:
> >
> > $ /usr/lib/postgresql/9.1/bin/postgres -V
> > postgres (PostgreSQL) 9.1.22
> >
> > $ uname -a
> > Linux zabbix 3.2.0-4-amd64 #1 SMP Debian 3.2.78-1 x86_64 GNU/Linux
> > # Testei também com a 4.6.1.
> >
> > $ ps aux | grep zabbixdb | wc -l
> > 63
> >
> > $ cat /etc/postgresql/9.1/main/postgresql.conf | egrep -v ^#
> >
> > data_directory = '/var/lib/postgresql/9.1/main'# use data in another
> > directory
> > hba_file = '/etc/postgresql/9.1/main/pg_hba.conf'# host-based
> > authentication file
> > ident_file = '/etc/postgresql/9.1/main/pg_ident.conf'# ident
> > configuration file
> > external_pid_file = '/var/run/postgresql/9.1-main.pid'# write an extra
> > PID file
> > listen_addresses = '*'# what IP address(es) to listen on;
> > port = 5432# (change requires restart)
> > max_connections = 120# (change requires restart)
> > unix_socket_directory = '/var/run/postgresql'# (change requires restart)
> > ssl = true# (change requires restart)
> > password_encryption = on
> > log_line_prefix = '%t '# special values:
> > autovacuum = on# Enable autovacuum subprocess?  'on'
> > log_autovacuum_min_duration = -1# -1 disables, 0 logs all actions and
> > autovacuum_max_workers = 1# max number of autovacuum subprocesses
> > autovacuum_naptime = 1min# time between autovacuum runs
> > datestyle = 'iso, dmy'
> > lc_messages = 'pt_BR.UTF-8'# locale for system error message
> > lc_monetary = 'pt_BR.UTF-8'# locale for monetary formatting
> > lc_numeric = 'pt_BR.UTF-8'# locale for number formatting
> > lc_time = 'pt_BR.UTF-8'# locale for time formatting
> > default_text_search_config = 'pg_catalog.portuguese'
> >
> > #Restante está tudo default
> >
> > [...corte...]
> >
>
> Tales,
>
> A configuração padrão do PostgreSQL é bem conservadora. Sugiro dar uma
> olhada no pgconfig [1] para tentar um tuning inicial mais adequado do
> que a configuração padrão.
>
> Outro ponto que arrisco a pensar (por conta de coleta de monitoramento)
> é que seu banco pode sofrer de estatísticas desatualizadas muito cedo
> fazendo com que o planejador tome caminhos ruins para execução das
> queries e por consequencia usando mais recursos do seu servidor. Tente
> rodar um "VACUUM ANALYZE" no seu database e observe se ocorre uma
> melhora e nos conte.
>
> Att,
>
> [1] http://www.pgconfig.org/
>
> --
>Fabrízio de Royes Mello Timbira - http://www.timbira.com.br/
>PostgreSQL: Consultoria, Desenvolvimento, Suporte 24x7 e Treinamento
>
>
Olá Fabrízio,

Não conhecia o pgconfig. Vou realizar a modificação de acordo com meu
cenário e acompanhar.
Em relação ao vacuum, executo 1 vez por semana (analise e limpeza), porém
surtiu efeito no uso de CPU.
Vou migrar o banco para outra máquina e acompanhar, se não resolver vou
considerar que seja algo de hardware.

Agradeço as dicas.

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

Re: [pgbr-geral] CPU em 100%

[Tales Costa]

Eduardo,

Vou pesquisar um pouco mais para obter tal informação.
Agradeço a dica.

--
Tales

Em 6 de junho de 2016 10:00, Eduardo Bohrer  escreveu:

> Cara bastante dificil fazer essa análise.
>
> Eu sugeriria você tentar ver que querys são essas e se de fato elas não
> são custosas.
> Dependendo do plano ou mesmo o que a query está fazendo pode
> tranquilamento uma query utilizar 100% de um core para rodar.
>
> ___
> 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] CPU em 100%

[Fabrízio de Royes Mello]

On 04-06-2016 12:13, Tales Costa wrote:
> Boa tarde,
> 
> De uns dias para cá estou enfrentando alguns problemas com um servidor
> Postgresql + Zabbix. O pg está consumindo em muitos momentos 100% da CPU
> do server, ocasionando o aumento da temperatura da mesma. 
> 
> Como não tenho experiência alguma com postgresql, estou na dúvida se o
> problema é de hardware ou algo relacionado ao pg pois funciona
> perfeitamente antes de migrar o servidor fisicamente de lugar e
> atualizar a versão do PG e alguns outros pacotes. 
> 
> Observei que o aumento de CPU sempre ocorre quando é executado alguns
> "select". Segue imagem do htop.
> 
> Segue algumas informações:
> 
> $ /usr/lib/postgresql/9.1/bin/postgres -V
> postgres (PostgreSQL) 9.1.22
> 
> $ uname -a
> Linux zabbix 3.2.0-4-amd64 #1 SMP Debian 3.2.78-1 x86_64 GNU/Linux
> # Testei também com a 4.6.1. 
> 
> $ ps aux | grep zabbixdb | wc -l
> 63
> 
> $ cat /etc/postgresql/9.1/main/postgresql.conf | egrep -v ^#
> 
> data_directory = '/var/lib/postgresql/9.1/main'# use data in another
> directory
> hba_file = '/etc/postgresql/9.1/main/pg_hba.conf'# host-based
> authentication file
> ident_file = '/etc/postgresql/9.1/main/pg_ident.conf'# ident
> configuration file
> external_pid_file = '/var/run/postgresql/9.1-main.pid'# write an extra
> PID file
> listen_addresses = '*'# what IP address(es) to listen on;
> port = 5432# (change requires restart)
> max_connections = 120# (change requires restart)
> unix_socket_directory = '/var/run/postgresql'# (change requires restart)
> ssl = true# (change requires restart)
> password_encryption = on
> log_line_prefix = '%t '# special values:
> autovacuum = on# Enable autovacuum subprocess?  'on'
> log_autovacuum_min_duration = -1# -1 disables, 0 logs all actions and
> autovacuum_max_workers = 1# max number of autovacuum subprocesses
> autovacuum_naptime = 1min# time between autovacuum runs
> datestyle = 'iso, dmy'
> lc_messages = 'pt_BR.UTF-8'# locale for system error message
> lc_monetary = 'pt_BR.UTF-8'# locale for monetary formatting
> lc_numeric = 'pt_BR.UTF-8'# locale for number formatting
> lc_time = 'pt_BR.UTF-8'# locale for time formatting
> default_text_search_config = 'pg_catalog.portuguese'
> 
> #Restante está tudo default 
> 
> [...corte...]
>

Tales,

A configuração padrão do PostgreSQL é bem conservadora. Sugiro dar uma
olhada no pgconfig [1] para tentar um tuning inicial mais adequado do
que a configuração padrão.

Outro ponto que arrisco a pensar (por conta de coleta de monitoramento)
é que seu banco pode sofrer de estatísticas desatualizadas muito cedo
fazendo com que o planejador tome caminhos ruins para execução das
queries e por consequencia usando mais recursos do seu servidor. Tente
rodar um "VACUUM ANALYZE" no seu database e observe se ocorre uma
melhora e nos conte.

Att,

[1] http://www.pgconfig.org/

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



signature.asc
Description: OpenPGP digital signature
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

Re: [pgbr-geral] CPU em 100%

[Eduardo Bohrer]

Cara bastante dificil fazer essa análise.

Eu sugeriria você tentar ver que querys são essas e se de fato elas não são
custosas.
Dependendo do plano ou mesmo o que a query está fazendo pode tranquilamento
uma query utilizar 100% de um core para rodar.
___
pgbr-geral mailing list
pgbr-geral@listas.postgresql.org.br
https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral

[pgbr-geral] CPU em 100%

[Tales Costa]

Boa tarde,

De uns dias para cá estou enfrentando alguns problemas com um servidor
Postgresql + Zabbix. O pg está consumindo em muitos momentos 100% da CPU do
server, ocasionando o aumento da temperatura da mesma.

Como não tenho experiência alguma com postgresql, estou na dúvida se o
problema é de hardware ou algo relacionado ao pg pois funciona
perfeitamente antes de migrar o servidor fisicamente de lugar e atualizar a
versão do PG e alguns outros pacotes.

Observei que o aumento de CPU sempre ocorre quando é executado alguns
"select". Segue imagem do htop.

Segue algumas informações:

$ /usr/lib/postgresql/9.1/bin/postgres -V
postgres (PostgreSQL) 9.1.22

$ uname -a
Linux zabbix 3.2.0-4-amd64 #1 SMP Debian 3.2.78-1 x86_64 GNU/Linux
# Testei também com a 4.6.1.

$ ps aux | grep zabbixdb | wc -l
63

$ cat /etc/postgresql/9.1/main/postgresql.conf | egrep -v ^#

data_directory = '/var/lib/postgresql/9.1/main' # use data in another
directory
hba_file = '/etc/postgresql/9.1/main/pg_hba.conf' # host-based
authentication file
ident_file = '/etc/postgresql/9.1/main/pg_ident.conf' # ident configuration
file
external_pid_file = '/var/run/postgresql/9.1-main.pid' # write an extra PID
file
listen_addresses = '*' # what IP address(es) to listen on;
port = 5432 # (change requires restart)
max_connections = 120 # (change requires restart)
unix_socket_directory = '/var/run/postgresql' # (change requires restart)
ssl = true # (change requires restart)
password_encryption = on
log_line_prefix = '%t ' # special values:
autovacuum = on # Enable autovacuum subprocess?  'on'
log_autovacuum_min_duration = -1 # -1 disables, 0 logs all actions and
autovacuum_max_workers = 1 # max number of autovacuum subprocesses
autovacuum_naptime = 1min # time between autovacuum runs
datestyle = 'iso, dmy'
lc_messages = 'pt_BR.UTF-8' # locale for system error message
lc_monetary = 'pt_BR.UTF-8' # locale for monetary formatting
lc_numeric = 'pt_BR.UTF-8' # locale for number formatting
lc_time = 'pt_BR.UTF-8' # locale for time formatting
default_text_search_config = 'pg_catalog.portuguese'

#Restante está tudo default

$ cat /proc/cpuinfo
processor : 0
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz
stepping : 5
microcode : 0x11
cpu MHz : 2794.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 0
cpu cores : 4
apicid : 0
initial apicid : 0
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept
vpid
bogomips : 5600.42
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 1
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz
stepping : 5
microcode : 0x11
cpu MHz : 2794.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 1
cpu cores : 4
apicid : 2
initial apicid : 2
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept
vpid
bogomips : 5599.99
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 2
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz
stepping : 5
microcode : 0x11
cpu MHz : 2794.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 2
cpu cores : 4
apicid : 4
initial apicid : 4
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc msr pae mce cx8 apic sep mtrr pge mca cmov pat
pse36 clflush dts acpi mmx fxsr sse sse2 ss ht tm pbe syscall nx rdtscp lm
constant_tsc arch_perfmon pebs bts rep_good nopl xtopology nonstop_tsc
aperfmperf pni dtes64 monitor ds_cpl vmx est tm2 ssse3 cx16 xtpr pdcm
sse4_1 sse4_2 popcnt lahf_lm ida dtherm tpr_shadow vnmi flexpriority ept
vpid
bogomips : 5599.99
clflush size : 64
cache_alignment : 64
address sizes : 36 bits physical, 48 bits virtual
power management:

processor : 3
vendor_id : GenuineIntel
cpu family : 6
model : 26
model name : Intel(R) Core(TM) i7 CPU 950  @ 3.07GHz
stepping : 5
microcode : 0x11
cpu MHz : 2794.000
cache size : 8192 KB
physical id : 0
siblings : 8
core id : 3
cpu cores : 4
apicid : 6
initial apicid : 6
fpu : yes
fpu_exception : yes
cpuid level : 11
wp : yes
flags : fpu vme de pse tsc