Marlon,

   Não tenho tanta experiência como muitos na lista, mais acho que poderia
começar logando mais informações do BD. Algumas configurações que acho boas
para verificar:
--- Confs ---
#Coletando mais informações
logging_collector = on
client_min_messages = log
log_min_messages = log
log_temp_files = 0
log_lock_waits = on
log_autovacuum_min_duration = 0

# Gravar planos de consulta com mais de 3 segundos
shared_preload_libraries = 'auto_explain'
custom_variable_classes = 'auto_explain'
auto_explain.log_min_duration = '3s'
--- fim ---

   Creio que a partir dos logs pode saber o real motivo da alta utilização
do CPU.

Abraços,
Aldrey Galindo

Em 25 de agosto de 2010 15:01, marlon david de souza
<[email protected]>escreveu:

>  Mais dois detalhes que eu esqueci de citar:
>
>
>
> ·         O *vacuumdb* é rodado diariamente (um *full* e outro *analyse*)
>
> ·         Não está logando nenhum comando SQL (auditoria)
>
> ·         Eles estão usando RAID tipo 5
>
>
>
> *De:* [email protected] [mailto:
> [email protected]] *Em nome de *marlon david de
> souza
> *Enviada em:* quarta-feira, 25 de agosto de 2010 14:42
> *Para:* [email protected]
> *Assunto:* [pgbr-geral] Lentidão em servidor de dados
>
>
>
> Boa tarde a todos,
>
>
>
>   Estou com uma situação em um cliente em que servidor de dados está muito
> lento.
>
>   Já tentei várias coisas, mas nada funcionou. Talvez alguém da lista possa
> dar uma luz.
>
>
>
>   O cliente possui as seguintes configurações:
>
>
>
> ·         Processadores: 02 Processadores Intel ® Xeon Quad Core HT -
> "Nehalem-EP" 5520, TDP 80w, Cache 8MB, 2,27GHz
>
> ·         Placa Mãe: Intel ® Server Board Dual Xeon, Modelo S5500BC
>
> ·         Chipset Intel ® S5500 (Tylersburg)
>
> ·         Memoria: 16 GB Kingston ® DDR3-1333 (8x 2GB)
>
> ·         RAID-5: 4 discos de 500 GB SATA 3.0, Seagate ® Barracuda ® 7200
> RPM
>
> ·         Controladora RAID-5: Intel ® Activation Key AXXRAKSW5 - Raid-5
> SATA
>
> ·         Placa de Video Incorporada: Server Engine LLC Pilot II, 8 MB
>
> ·         Placas de Rede Gigabit com Tecnologia I/O Acceleration: 02
> Placas Intel ® Gigabit 82575EB
>
> ·         Solução Térmica: 02 Dissipadores Intel ® STS100A (Ativos)
>
> ·         Servidor Linux dedicado
>
> ·         OpenSUSE 11.0 64 bits
>
> ·         Partição com ext3
>
> ·         PostgreSQL 8.2.4 compilado na própria máquina
>
> ·         Média de 55 conexões simultâneas
>
>
>
>   Dá para notar que pela configuração existente, lentidão no servidor não
> deveria ser algo comum.
>
>
>
>   O que acontece é o seguinte: quando o servidor passa de 40 conexões, o
> sistema começa a ficar lento. Qualquer tipo de consulta passa a consumir
> 100% de CPU.
>
>
>
>   Pelo comando *top* to Linux, observei que o primeiro parâmetro *
> LoadAverage* fica entre 2,8 a 4,0. No entanto, o problema não é o acesso a
> disco pois o parâmetro *wa* está quase sempre abaixo de 1%.
>
>   Também não está utilizando memória *swap* e o PostgreSQL não está
> criando arquivos temporários para as consultas (pgsql_temp)
>
>   Já revi várias vezes o arquivo postgresql.conf e, aparentemente, está
> tudo Ok.
>
>   Não existe uma consulta em específico que torna o servidor lento.
> Qualquer consulta que demanda mais recurso torna o servidor lento. É como se
> o núcleo da CPU utilizado para a consulta não conseguisse dar conta do
> processamento e atrasasse os demais núcleos.
>
>
>
>   Será que o problema está no hardware, no Linux ou no PostgreSQL?
>
>
>
>   O PostgreSQL trabalha bem com o HT habilitado?
>
>
>
>
>
>
>
> *Sem mais, agreço antecipadamente a atenção*
>
> * *
>
> *Marlon David de Souza*
>
> *Desenvolvedor*
>
>
>
> _______________________________________________
> pgbr-geral mailing list
> [email protected]
> 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