From: | "Florian G(dot) Pflug" <fgp(at)phlo(dot)org> |
---|---|
To: | Patrick TJ McPhee <ptjm(at)interlog(dot)com> |
Cc: | pgsql-general(at)postgresql(dot)org |
Subject: | Re: Deathly slow performance on SMP red-hat system |
Date: | 2006-09-01 18:14:43 |
Message-ID: | 44F87893.9050400@phlo.org |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-general |
Patrick TJ McPhee wrote:
> % Patrick TJ McPhee wrote:
> [...]
> [the query is "select 1"]
> % > But if I turn on duration logging, I get timings like
> % > LOG: duration: 91.480 ms
>
> The logs and data are all one file system, which seems to be on a logical
> volume with a single disk sitting under it.
>
> Florian Pflug reports that he had a similar problem due to a slow RAID
> controller driver, to which I have no comment.
You could try doing:
begin;
select 1;
select 1;
...
rollback;
If this is faster, than it's committing a transaction which is slow -
remember that a statement not wrapped in begin/commit will cause
postgres to start a transaction, execute the statement, and commit
afterwards.
If this is slow too, then I'd suggest playing with postgresql.conf
parameters - e.g. try turning any logging, and the statistics collector
off. If that doesn't reveal a possible cause, then I'd suggest that
you strace the backend you're connected to, and try to see where it's
spending it's time. Since 100ms for a simple "select 1;" is way out
of bounds, I bet that it's some syscall that's taking up all the time -
probably either network or disk related.
greetings, Florian Pflug
>
> Thanks for your comments.
>
From | Date | Subject | |
---|---|---|---|
Next Message | Scott Marlowe | 2006-09-01 18:22:29 | Re: Precision of data types and functions |
Previous Message | Robert Bernier | 2006-09-01 17:05:14 | Re: Training (from Thought provoking...) |