Re: Deathly slow performance on SMP red-hat system

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.
>

In response to

Responses

Browse pgsql-general by date

  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...)