>> 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