Skip site navigation (1) Skip section navigation (2)

Re: vacuum problem

From: "John R Pierce" <pierce(at)hogranch(dot)com>
To: "Gaetano Mendola" <mendola(at)bigfoot(dot)com>
Cc: "pgsql -bugs" <pgsql-bugs(at)postgresql(dot)org>
Subject: Re: vacuum problem
Date: 2004-09-11 19:25:43
Message-ID: 032701c49835$2186d670$0200a8c0@hogranch.com (view raw or flat)
Thread:
Lists: pgsql-bugs
>> About an hour after mailing that, I realized that the buggy RHEL2.1 
>> system was running with Intel Hyperthreading enabled (so it appeared as 4 
>> CPUs) while the no-problems RH8.0 system had hyperthreading enabled (we'd 
>> previously been benchmarking some multithreaded stuff both ways).   So, 
>> its *just* possible that the earlier RHEL2.1 (kernel 
>> 2.4.9-e.43enterprise) had issues which the later RH8 (2.4.20-28.8smp) 
>> were resolved.    I'll not be able to test this hypothesis until monday 
>> morning.
>
> I run RHEL2.1 on the same your HW with HT enabled and I never had a 
> problem
> with that.

are you running PGSql 7.4.x ? (we have this same issue with 7.4.2 and 
7.4.5).   fyi, my RHEL2.1 has all available up2date fixes, and I did *NOT* 
install RH's postgres RPM, rather, I fetched and built 7.4.5 from source

could you perhaps give my test program a try?   create a database 'test', a 
user 'test' with password 'test', and table 'test' as described in my 
original message, and compile and run this program:

    http://www.hogranch.com/files/PGTest.java

compile the java program with Sun J2SE JDK 1.4.x..

    $ javac PGTest.java

Temporarily disable any autovacuum cronjobs you may have, and invoke the 
program with

    $ java -cp . PGTest -r 20 -l 50 -c 4000

(postgresql.jar has to be in your CLASSPATH, or you can specify it as -cp 
.:/path/postgresql.jar .. I'm using the one that compiled with 7.4.5 and my 
jdk 1.4.x)

and let it run for several hours.   On our dual 2.8Ghz Xeon (Intel SE7501WV2 
server), it starts out around 13000mS per thousand inserts, after a hour it 
slows to 20000, and a few more hours later, its up to 40000, thats when I 
try a `vacuumdb -v -d test`   (or any other combination of vacuum options 
that include this table in this database).  It doesn't matter if the app is 
running or not.

I am unable to vacuum the freespace in this table until I stop and restart 
the postgresql service.    put your autovacuum back online when you're done 
messing.   I can not reproduce this problem on a RH8 (2.4.20.x) system


In response to

Responses

pgsql-bugs by date

Next:From: Gaetano MendolaDate: 2004-09-11 21:17:50
Subject: Re: vacuum problem
Previous:From: Gaetano MendolaDate: 2004-09-11 18:35:36
Subject: Re: vacuum problem

Privacy Policy | About PostgreSQL
Copyright © 1996-2014 The PostgreSQL Global Development Group