From: | Dan Harris <fbsd(at)drivefaster(dot)net> |
---|---|
To: | pgsql-performance(at)postgresql(dot)org |
Subject: | Re: Table locking problems? |
Date: | 2005-08-09 20:51:18 |
Message-ID: | 2764B744-4CDC-4F2C-99C4-2948D37A9D23@drivefaster.net |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-performance |
On Aug 10, 2005, at 12:49 AM, Steve Poe wrote:
> Dan,
>
> Do you mean you did RAID 1 + 0 (RAID 10) or RAID 0 + 1? Just a
> clarification, since RAID 0 is still a single-point of failure even if
> RAID1 is on top of RAID0.
Well, you tell me if I stated incorrectly. There are two raid
enclosures with 7 drives in each. Each is on its own bus on a dual-
channel controller. Each box has a stripe across its drives and the
enclosures are mirrors of each other. I understand the controller
could be a single point of failure, but I'm not sure I understand
your concern about the RAID structure itself.
>
> How many users are connected when your update / delete queries are
> hanging? Have you done an analyze verbose on those queries?
Most of the traffic is from programs we run to do analysis of the
data and managing changes. At the time I noticed it this morning,
there were 10 connections open to the database. That rarely goes
above 20 concurrent. As I said in my other response, I believe that
the log will only contain the query at the point the query finishes,
so if it never finishes...
>
> Have you made changes to the postgresql.conf? kernel.vm settings? IO
> scheduler?
I set shmmax appropriately for my shared_buffers setting, but that's
the only kernel tweak.
>
> If you're not doing so already, you may consider running sar
> (iostat) to
> monitor when the hanging occurs if their is a memory / IO bottleneck
> somewhere.
>
I will try that. Thanks
From | Date | Subject | |
---|---|---|---|
Next Message | John A Meinel | 2005-08-09 21:51:22 | Re: Table locking problems? |
Previous Message | Dan Harris | 2005-08-09 20:42:57 | Re: Table locking problems? |