Re: [pgbr-geral] CPU em 100%

2016-06-06 Thread 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

Re: [pgbr-geral] CPU em 100%

2016-06-06 Thread 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