Database Administrators Stack Exchange is a question and answer site for database professionals who wish to improve their database skills and learn from others in the community. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm running a Postgres 9.1 database on a Debian Squeeze server. It's a paravirtualized XEN guest system with 4G RAM and 1 CPU core, based on a i7-2600 host system with Linux software-RAID1.

I'm trying to get a feel for how fast/slow my setup is, and am running pgbench. This is the command I've been running to initialize pgbench:

pgbench -i -s 100 -U jboss -p 5432 -h project2_core

The first 5000000 tuples run by very quickly, but then it gets slower and slower. Now, it displayed

10000000 tuples done.

for a very long time (10 minutes or so) with no CPU load, and also RAM is not an issue. Only then, it continued with

set primary key...

and some NOTICEs about primary keys.

My question: is this runtime to be expected, or must I suspect there's something wrong with my system?

share|improve this question
Do you get the same results on an other run? – dezso Sep 26 '12 at 11:02
Are there any other processes, deamons, guests, etc running on the host? Asking about relative performance on a complex system such as this is like comparing apples and oranges, and it doesn't really get you anywhere. Try running a real load and determining if the response you get is acceptable. This will tell you if your system serves your needs. – Max Vernon Sep 27 '12 at 3:27

I'd look at how you have your IO stack set up, which you say nothing about in the question. It sounds like actually committing the rows is taking a really long time. Virtual file systems on top of other file systems often display the worst characteristics of both layers.

You also should try doing an actual test run, as well as just populating a database.

share|improve this answer

If it is dropping off after a large number of writes, my guess is that the first ones are all getting cached and the drop in performance is due to cache misses. You will get better performance by allocating more RAM.

BTW, virtualized databases are tricky, performance-wise. There could be all kinds of other things that could be issues, including disk I/O bottlenecks and you will have a fair bit of trouble troubleshooting this. My recommendation always is to run databases directly on the host OS. Virtualization usually adds needless complexity and there are better ways to consolidate PostgreSQL servers than virtualization.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.