Load = carga da máquina. Um load alto significa que sua máquina está com muitos processos no momento, e isso pode ter vários motivos. Só que ninguém é mais qualificado do que voce para saber o motivo do problema. Voce conhece o sistema, tente usar seu conhecimento e analisar os processos da máquina. Utilize o comando top, com ele vc ve o status da maquina com os processos mais ativos e em execuçao no momento. Liste os processos com ps auxw e veja o que está rolando e quantos processos estao sendo executados. Acho que é isso, existem muitas outras formas de analisar a situaçao mas o basico é por ai.
Grande abraço! Em 16 de março de 2010 15:40, "André Ormenese ( Yahoo )" < [email protected]> escreveu: > No dmesg e no /var/log/messages aparece esta mensagem : > > BUG: soft lockup - CPU#1 stuck for 10s! [postmaster:13264] > CPU 1: > Modules linked in: ipv6 xfrm_nalgo crypto_api dm_mirror dm_multipath > scsi_dh video hwmon backlight sbs i2c_ec button battery asus_acpi > acpi_memhotplug ac parport_pc lp parport snd_hda_intel snd_seq_dummy > snd_seq_oss snd_seq_midi_event snd_seq snd_seq_device snd_pcm_oss > snd_mixer_oss snd_pcm snd_timer snd_page_alloc snd_hwdep i2c_i801 snd > i2c_core soundcore e1000 e1000e pcspkr dm_raid45 dm_message dm_region_hash > dm_log dm_mod dm_mem_cache ata_piix libata sd_mod scsi_mod raid1 ext3 jbd > uhci_hcd ohci_hcd ehci_hcd > Pid: 13264, comm: postmaster Not tainted 2.6.18-128.2.1.el5 #1 > RIP: 0010:[<ffffffff80064cb2>] [<ffffffff80064cb2>] > .text.lock.spinlock+0x0/0x30 > RSP: 0000:ffff810107f33f08 EFLAGS: 00000282 > RAX: 0000000000298fb7 RBX: ffffffff802fae80 RCX: ffff810107f33f30 > RDX: ffff810021080780 RSI: ffff81000100e8e0 RDI: ffffffff802faf00 > RBP: ffff810107f33e80 R08: 0000000000000246 R09: ffffffff803c3fb0 > R10: 0000000000000a66 R11: 0000000000000a66 R12: ffffffff8005dc8e > R13: ffff81000100e8e0 R14: ffffffff80077533 R15: ffff810107f33e80 > FS: 00002aff76b105b0(0000) GS:ffff810107f07840(0000) > knlGS:0000000000000000 > CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033 > CR2: 00002aff7a363180 CR3: 000000006003d000 CR4: 00000000000006e0 > > Call Trace: > <IRQ> [<ffffffff8009bb88>] __rcu_process_callbacks+0x8c/0x1a1 > [<ffffffff8009bcc0>] rcu_process_callbacks+0x23/0x43 > [<ffffffff80092411>] tasklet_action+0x89/0xfd > [<ffffffff80011fc3>] __do_softirq+0x89/0x133 > [<ffffffff8005e2fc>] call_softirq+0x1c/0x28 > [<ffffffff8006cada>] do_softirq+0x2c/0x85 > [<ffffffff8005dc8e>] apic_timer_interrupt+0x66/0x6c > <EOI> > > E várias outras relacionadas a este BUG: soft lockup .... postmaster, > swapper .... > > Mar 15 10:55:47 cl-t130-372cl kernel: BUG: soft lockup - CPU#0 stuck for > 10s! [swapper:0] > Mar 15 10:55:47 cl-t130-372cl kernel: CPU 0:M > > No crontab não tem nada pesado sendo chamado. > > O que vc quer dizer com load (desculpe) ???? > > > > > Em 16/3/2010 14:32, Oliver Thies escreveu: > > Olá, > O banco executar menos consultas e levar um tempo maior para cada consulta > pode ser algum processo na máquina que esteja deixando-a lenta. > Como está seu load? > Algum cronjob no período? > Algo em /var/log/messages? > dmesg? > > Abs > > > Em 16 de março de 2010 14:20, JotaComm <[email protected]> escreveu: > >> Olá, >> >> Em 16 de março de 2010 09:28, "André Ormenese ( Yahoo )" < >> [email protected]> escreveu: >> >> Bom dia a todos !!! >>> >>> Estou utilizando o pgfouine para analisar como está a utilização de um >>> banco com problemas de performance. >>> >>> Após analisar os resultados e gráficos ainda tenho algumas dúvidas, por >>> exemplo : >>> Em determinado período do dia, alguma coisa acontece que a quantidade de >>> queries executadas pelo banco diminui, e o tempo de execução sobe >>> absurdamente. Gostaria de identificar qual execução acabou deixando o >>> banco tão lento assim, mas pelo pgfouine não consegui. >>> >> >> Talvez pelo log de atividades (pg_log) seja mais fácil de identificar >> isso. >> >>> >>> Até tem uma opção do pgfouine para filtrar o log por horário, mas ainda >>> não consegui me acertar com a sintaxe, se alguém já utilizou este >>> parâmetro com sucesso, por favor, me manda um exemplo. >>> >>> E se alguém sabe de alguma consulta ao catálogo ou qualquer outra coisa >>> que me ajude a identificar o que causou a lentidão agradeço. >>> >>> Só para vcs terem ideia, na execução de um simples SET SESSION >>> CHARACTERISTICS AS TRANSACTION ISOLATION LEVEL READ UNCOMMITTED, no pico >>> da lentidão o pgfouine me informa que o tempo de execução ficou em >>> 9,704.42 segundos. >>> >>> Obrigado a todos >>> >>> André >>> >>> >>> >>> _______________________________________________ >>> pgbr-geral mailing list >>> [email protected] >>> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >>> >> >> >> []s >> -- >> JotaComm >> http://jotacomm.wordpress.com >> >> _______________________________________________ >> pgbr-geral mailing list >> [email protected] >> https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral >> >> > > _______________________________________________ > pgbr-geral mailing > [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 > >
_______________________________________________ pgbr-geral mailing list [email protected] https://listas.postgresql.org.br/cgi-bin/mailman/listinfo/pgbr-geral
