Re: [PERFORM] autovacuum hung?

[Tom Lane]

Brian Cox  writes:
> autovacuum has been running on 2 tables for > 5 hours. There tables are 
> not huge (see below). For the past ~1 hour, I've shut off all other 
> activity on this database. The other table being vacuumed has more rows 
> (1897810). Anyone have any ideas about why this is taking so long?

Are those processes actually doing anything, or just waiting?  strace
or local equivalent would be the most conclusive check.

> cemdb=# select c.oid,c.relname,l.pid,l.mode,l.granted from pg_class c 
> join pg_locks l on c.oid=l.relation order by l.pid;

This query isn't very helpful because it fails to show locks that are
not directly associated with tables.

regards, tom lane

-- 
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance

Re: [PERFORM] Scalability in postgres

[Greg Smith]

On Fri, 29 May 2009, Scott Carey wrote:


There are operations/IT people won't touch Ubuntu etc with a ten foot pole
yet for production.


The only thing I was suggesting is that because 2.6.28 is the latest 
Ubuntu kernel, that means it's gotten a lot more exposure and testing 
than, say, other options like 2.6.27 or 2.6.29.


I build a fair number of RedHat/CentOS systems with an upgraded kernel 
based on mature releases from kernel.org, and a config as close as 
possible to the original RedHat one, with the generic kernel defaults for 
all the new settings.  I keep liking that combination better than just 
using an Ubuntu version with a newer kernel.  I've seen a couple of odd 
kernel setting choices in Ubuntu releases before that motivate that 
choice; the scheduler trainwreck described at 
https://bugs.launchpad.net/ubuntu/+source/linux/+bug/188226 comes to mind.


--
* Greg Smith gsm...@gregsmith.com http://www.gregsmith.com Baltimore, MD

--
Sent via pgsql-performance mailing list (pgsql-performance@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-performance