From: | Patric de Waha <lists(at)p-dw(dot)com> |
---|---|
To: | |
Cc: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Two questions.. shared_buffers and long reader issue |
Date: | 2007-07-11 20:48:51 |
Message-ID: | 46954233.4050807@p-dw.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
Ok thanks.
iostat confirmed it's an IO bottleneck.
Will add some discs to the RAID unit.
Used 4 Raptor discs in Raid 10 until now.
best regards,
patric
Tom Lane wrote:
> Patric de Waha <lists(at)p-dw(dot)com> writes:
>
>> Postgres is running on a dedicated server P4 DualCore, 4 Gig Ram.
>>
>
> When you don't even mention your disk hardware, that's a bad sign.
> In a database server the disk is usually more important than the CPU.
>
>
>> Why do long readers influence the rest of the transactions in such a
>> heavy way?
>> Any configuration changes which can help here?
>> Is it a disc-IO bottleneck thing?
>>
>
> Very possibly. Have you spent any time watching "vmstat 1" output
> to get a sense of whether your I/O is saturated?
>
>
>> WAL files are located on another disc than the dbase itself.
>>
>
> That's good, but it only relates to update performance not SELECT
> performance.
>
>
>> effective_cache_size = 5000
>>
>
> That's way too small for a 4G machine. You could probably stand to
> boost maintenance_work_mem too. However, neither of these have any
> immediate relationship to your problem.
>
> regards, tom lane
>
From | Date | Subject | |
---|---|---|---|
Next Message | Tom Lane | 2007-07-11 21:54:45 | Re: TRUNCATE TABLE |
Previous Message | Tom Lane | 2007-07-11 20:35:31 | Re: Weird row estimate |