Em 15 de maio de 2013 10:02, Flavio Henrique Araque Gurgel <
[email protected]> escreveu:

> Em 15-05-2013 09:42, Filho Arrais escreveu:
>
>  Não entendi porque não chegou no email. Algo de errado?
>>
>
> O e-mail chegou sim.
>

E que pra mim não tinha chegado, desculpem-me.


> O que está errado é que você quer uma configuração genérica e isso não
> existe.
>
> Podemos tentar ajudar um pouco aqui, mas tuning assim é melhor você ler
> mais e aprender um pouco. São centenas de variáveis e cenários. Não há
> fórmula mágica.
>
> Seu sistema está com algum tipo de lentidão identificada?
>
> Com o passar das horas, ele perde um pouco do rendimento, vou chutar ai
uns 10% na hora de retorna as informações solicitadas.


>
>      Utilizamos um sistema que tem como base de dados o PostreSQL 8.4.
>>
>>     Migrei para um novo servidor, por falta de tempo e conhecimento,
>>     utilizei o mesmo postrgresql.conf
>>
>>     Gostaria de discutir com os senhores que tem mais conhecimento,
>>     sobretudo em ambientes reais de produção, quais ajustes podem ser
>>     realizados no PostgreSQL e se os atuais parâmetros estão aceitáveis
>>     para o nosso cenário.
>>
>>     Estou com a seguinte configuração.
>>
>>       Dois Processadores Intel Xeon E5-2650 0  2.00GHz ( total de 32 core)
>>       24 GB de memória RAM
>>       8 Discos SAS 15k com dois grupos de RAID10 ( primeiro Raid10 pro
>>     sistema operacional e PG_XLOG em partições distintas, segundo Raid10
>>     unicamente pro PGDATA)
>>
>
> Você fez mais ou menos certo.
> O ideal seria que o disco (ou RAID) pro pg_xlog fosse só pra ele.
> O S.O. você pode colocar num SATA, por exemplo.
>
> OK.

>
>
>        Sistema Operacional: Ubuntu Server 13.04
>>       Kernel: 3.8.0-19-generic
>>       Sistema de arquivo: EXT4
>>       PostgreSQL: 8.4.17
>>
>
> Bom. Atualizado na série.
>
> OK

>
>
>>     A quantidade de usuários do sistema é de 180, porém o número de
>>     conexões simultâneas está por volta de 200.
>>
>
> Considere usar um pool como o PgBouncer. Seu sistema é feito em que
> linguagem?

Irei pesquisar o PgBouncer. O sistema é feito em WinDev.


>
>      Logo abaixo, segue as configurações do postgresql.conf e sysctl.conf
>>
>>     ==============================**==============================**
>> ==========
>>
>>     postgresql.conf
>>
>>     listen_addresses = '*'
>>     port = 5432
>>     max_connections = 300
>>
>
> Vide pergunta acima.
>
>      shared_buffers = 6144MB
>>
>
> Muito. Seu sistema faz o que? Que tipo de carga?


É um sistema para transportadora.

Faz toda a parte de Gestão Corporativa. Gestão de Frotas, Contabilidade,
Sped Contábil, Fiscal e FCont, CT-e, NF-e, Intregração com sistema de
rastreamento de veículos.



>      temp_buffers = 64MB
>>     work_mem = 96MB
>>
>
> Não dá pra precisar aqui porque você usa este valor.
>
>      maintenance_work_mem = 70MB
>>
>
> Aqui também não. Qual o tamanho de suas tabelas?


As 10 maiores são essas, no total a base ultrapassa 30 GB

1  "3676 MB"
2  "3623 MB"
3  "3147 MB"
4  "2253 MB"
5  "2108 MB"
6  "1598 MB"
7  "1159 MB"
8  "906 MB"
9  "692 MB"
10 "614 MB"




>
>      fsync = on
>>     full_page_writes = on
>>     wal_buffers = 2048kB
>>
>
> Qual o wal_sync_method?


Esse parâmetro não está sendo utilizado.

>
>      checkpoint_segments = 48
>>     checkpoint_timeout = 45min
>>
>
> Furado. 45 minutos é um exagero tremendo.
> Procure ficar na faixa dos 5 minutos e ajustar checkpoint_segments para
> mais. Considere logar os checkpoints para saber se estão começando por
> tempo ou falta de segmentos e depois ajuste o valor.
>
>      effective_cache_size = 5461MB
>>
>
> Coloque aqui sua memória RAM + eventuais caches de disco da controladora.
>
>
>      log_filename = 'postgresql-%a.log'
>>     log_line_prefix = '[ %u@%h %d - %t ] '
>>     autovacuum_max_workers = 3
>>
>
> Pode ser necessário mais. Considere log_autovacuum = 0 para saber o que
> acontece com seu banco.
>
>      autovacuum_naptime = 40min
>>
>
> Isto é um erro brutal.
> Volte pros 60s default.
>
>
>      datestyle = 'iso, dmy'
>>     client_encoding = LATIN1
>>     lc_messages = 'C'
>>     lc_monetary = 'pt_BR.UTF-8'
>>     lc_numeric = 'pt_BR.UTF-8'
>>     lc_time = 'pt_BR.UTF-8'
>>     default_text_search_config = 'pg_catalog.portuguese'
>>
>
> Isto aqui depende só de sua aplicação e não tem relaço com desempenho.
>
Essa parte eu poderia ter omitido, perdão.

>
>      deadlock_timeout = 3s
>>
>
> Por quê?
>
Também não sei o porque desse valor.

>
>      add_missing_from = on
>>
>
> Sua aplicação é ruim?
>
Não é ruim, também não é das melhores. Temos um servidor aplicação onde
utilizamos um atalho nas máquinas, porém a conexão com o banco é feita via
ODBC.

>
>      default_with_oids = on
>>
>
> Sua aplicação foi feita para PostgreSQL 7.4 ou anterior?
>
Essa informação eu não sei, suspeito que tenha sida projeta a partir do
PostreSQL 8.2.3

>
>      escape_string_warning = off
>>
>>     Tive olhando no
>>     
>> wiki.postgresql.org/wiki/**Tuning_Your_PostgreSQL_Server<http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server>
>>     
>> <http://wiki.postgresql.org/**wiki/Tuning_Your_PostgreSQL_**Server<http://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server>>
>> que
>>
>>     o shared_buffers  pode receber  1/4 da memoria (dependendo do
>>     ambiente), por isso esse valor de "6144 MB"
>>
>
> Muito. Considere no máximo 4GiB para sistemas comuns. Mais só em caso
> muito especiais e menos se seu sistema for mais de relatórios e menos OLTP.


Considero os dois, relatórios e OLTP. Qual a sugestão?


>
>>     ==============================**==============================**
>> =======
>>
>>     No sysctl.conf
>>
>>     kernel.shmmax = 16823421610
>>
>
> Só depende de seu shared_buffers, precisa ser maior que ele e só.
>
>      kernel.shmall = 16823421610
>>
>
> Sem influência neste caso.
>
>
>      De acordo com o manual do ERP, o cálculo desse valor seria:
>>
>>     kernel.shmmax = TOTAL_RAM_EM_BYTES / 3 * 2
>>     kernel.shmall    = TOTAL_RAM_EM_BYTES / 3 * 2
>>
>
> Tudo completamente errado. Veja o que escrevi acima.
> Acho que você precisa ler bastante.
>
>
Flávio, é esse tipo de informação que eu preciso, esse pontapé inicial.

Eu postei a configuração que o ERP fez no banco anterior, após migrar pra o
novo servidor adotei a mesma configuração ( for falta de conhecimento, como
ajuste necessário e provisoria), porém acho que não está das mais corretas,
he he.

Postei esperando justamente a resposta que você deu.

[]s
>
>
> ______________________________**____
> Flavio Henrique A. Gurgel
> Líder de Projetos Especiais
> Consultoria, Projetos & Treinamentos 4LINUX
> Tel1: +55-11.2125-4747 ou 2125-4748
> www.4linux.com.br
> email: [email protected]
> ______________________________
> FREE SOFTWARE SOLUTIONS
> ______________________________**_________________
> pgbr-geral mailing list
> [email protected].**org.br<[email protected]>
> https://listas.postgresql.org.**br/cgi-bin/mailman/listinfo/**pgbr-geral<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

Responder a