I am wondering if your wait is caused by contention between
pg_autovacuum and the DELETE that is running. Your large Pg blocksize
(32K) *may* be contributing to any possible contention as well. Maybe
try disabling pg_autovacuum to see if there is any change in behaviour.
Also going through my
Hello,
We're having a substantial problem with our FreeBSD 5.2 database
server
running PostgreSQL - it's getting a lot of traffic (figure about 3,000
queries per second), but queries are slow, and it's seemingly waiting
on
other things than CPU time
Could this be a 5.2 performance issue ?
In
Josh Berkus wrote:
Forget hyperthreading. Look at their postgresql.conf settings. 8mb shared
mem, 16mb sort mem per connection for 512 connections, default
effective_cache_size.
Umm...its 64Mb shared buffers isn't it ?
However agree completely with general thrust of message
Darcy Buskermolen wrote:
-- Forwarded Message --
Subject: FreeBSD, PostgreSQL, semwait and sbwait!
Date: March 23, 2004 12:02 pm
From: Jason Coene [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hello all,
We're having a substantial problem with our FreeBSD 5.2 database server
running
-- Forwarded Message --
Subject: FreeBSD, PostgreSQL, semwait and sbwait!
Date: March 23, 2004 12:02 pm
From: Jason Coene [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Hello all,
We're having a substantial problem with our FreeBSD 5.2 database server
running PostgreSQL - it's
Darcy Buskermolen [EMAIL PROTECTED] writes:
The database server is a dual P4-2.8 w/ HT enabled (kernel finds 4
processors), 2GB RAM, 4 disk Serial ATA on 3ware RAID, gigabit Ethernet
connection to web servers. It's running FreeBSD 5.2 and PostgreSQL 7.4.1.
Hm. What happens if you turn off
Darcy,
I suggest getting this person over here instead.They have a *lot* to learn
about tuning PostgreSQL.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
---(end of broadcast)---
TIP 4: Don't 'kill -9' the postmaster
Tom,
Hm. What happens if you turn off the hyperthreading?
Forget hyperthreading. Look at their postgresql.conf settings. 8mb shared
mem, 16mb sort mem per connection for 512 connections, default
effective_cache_size.
--
-Josh Berkus
Aglio Database Solutions
San Francisco
Josh Berkus [EMAIL PROTECTED] writes:
Forget hyperthreading. Look at their postgresql.conf settings. 8mb shared
mem, 16mb sort mem per connection for 512 connections, default
effective_cache_size.
They could well be going into swap hell due to the oversized sort_mem,
but that didn't
