2ndQuadrant is now part of EDB

Bringing together some of the world's top PostgreSQL experts.

2ndQuadrant | PostgreSQL
Mission Critical Databases
  • Contact us
  • EN
    • FR
    • IT
    • ES
    • DE
    • PT
  • Support & Services
  • Products
  • Downloads
    • Installers
      • Postgres Installer
      • 2UDA – Unified Data Analytics
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
  • Postgres Learning Center
    • Webinars
      • Upcoming Webinars
      • Webinar Library
    • Whitepapers
      • Business Case for PostgreSQL Support
      • Security Best Practices for PostgreSQL
    • Blog
    • Training
      • Course Catalogue
    • Case Studies
      • Performance Tuning
        • BenchPrep
        • tastyworks
      • Distributed Clusters
        • ClickUp
        • European Space Agency (ESA)
        • Telefónica del Sur
        • Animal Logic
      • Database Administration
        • Agilis Systems
      • Professional Training
        • Met Office
        • London & Partners
      • Database Upgrades
        • Alfred Wegener Institute (AWI)
      • Database Migration
        • International Game Technology (IGT)
        • Healthcare Software Solutions (HSS)
        • Navionics
    • Books
      • PostgreSQL 11 Administration Cookbook
      • PostgreSQL 10 Administration Cookbook
      • PostgreSQL High Availability Cookbook – 2nd Edition
      • PostgreSQL 9 Administration Cookbook – 3rd Edition
      • PostgreSQL Server Programming Cookbook – 2nd Edition
      • PostgreSQL 9 Cookbook – Chinese Edition
    • Videos
    • Events
    • PostgreSQL
      • PostgreSQL – History
      • Who uses PostgreSQL?
      • PostgreSQL FAQ
      • PostgreSQL vs MySQL
      • The Business Case for PostgreSQL
      • Security Information
      • Documentation
  • About Us
    • About 2ndQuadrant
    • 2ndQuadrant’s Passion for PostgreSQL
    • News
    • Careers
    • Team Profile
  • Blog
  • Menu Menu
You are here: Home1 / Blog2 / Greg's PlanetPostgreSQL3 / PGEast, Hardware Benchmarking, and the PG Performance Farm
2ndQuadrant Press

PGEast, Hardware Benchmarking, and the PG Performance Farm

March 11, 2010/0 Comments/in Greg's PlanetPostgreSQL, PostgreSQL, United States News /by 2ndQuadrant Press

Today is the deadline for the special room rate at the hotel hosting this month’s PostgreSQL Conference East 2010.  If you’ve been procrastinating booking a spot at the conference, as of tomorrow that will start costing you.

My talk is on Database Hardware Benchmarking and is scheduled for late afternoon on the first day, Thursday March 25th.  Those who might have seen this talk before, either live at PGCon 2009 or via the video link available there, might be wondering if I’m going to drag out the same slides and talk again.  Not the case; while the general philosophy of the talk (“trust no one, run your own benchmarks”) stays the same, the examples and test mix suggested have been updated to reflect another year worth of hardware advances, PostgreSQL work, and my own research during that time.  The Intel vs. AMD situation in particular has changed quite a bit, requiring a new set of memory benchmarks to really follow what’s going on now.

And PostgreSQL 9.0 fixed a major problem that kept it from normally delivering accurate results on Linux, due to a kernel regression that made much worse an already far too common situation:  it’s easy for a single pgbench client to become the bottleneck when running it, rather than the database itself.  The review I did for multi-threaded pgbench (which can also be multi-process pgbench on systems that don’t support threads) suggested a solid >30% speedup even on systems that didn’t have the bad kernel incompatibility on them.  Subsequent testing suggests it can easily take 8 pgbench processes to get full throughput out of even inexpensive modern processors under recent Linux kernels.  I’ll go over exactly how that ends up playing out on such systems, and how this new feature makes it possible again to use pgbench as the primary way to measure CPU performance running the database.

Recently I’ve also made an updated to the git repo for pgbench-tools that adds working support for PostgreSQL 8.4 and basic 9.0 compatibility, and the next update will include support for the multi-threaded option now that I’ve mapped out how that needs to work.  This is all leading somewhere.  Once we have accurate measurements for PostgreSQL performance that are CPU limited on the server side, something that hasn’t often been the case for over two years now, those again become a useful way to monitor for performance regressions in the PostgreSQL codebase.  The tests included will need to expand for that to cover more eventually, but for now we’ve reached a point where pgbench can be used to find regressions that impact how fast simple SELECT statements execute.  I know that works as expected, because every time I accidentally build PostgreSQL with assertions on that’s caught because I see the average processing rate drop dramatically.

Once I’ve got a couple of systems setup here to test for such regressions, the question becomes how to automate what I’m doing, and then to do the same thing against a wider range of build checkouts.  Ideally, you’d be able to see a graph of average SELECT performance each day, broken down by version, so that when a commit that reduced it was introduced it would immediately be obvious when the performance dropped.  This is the dream goal for building a performance farm similar to the PostgreSQL buildfarm.    The pieces are almost all together now:  my pgbench parts are wrapping up, extensions to the buildfarm to make it speak directly to git are moving along (not a requirement, but nobody working on this project wants to use CVS if we can avoid it), and the main thing missing at this point is someone to put the time in to integrate what I’ve been doing into a buildfarm-like client.

And it looks like we now have a corporate sponsor willing to help with that chunk of work, who I’ll let take credit for when we’re all done, and that’s scheduled to happen this summer.  I fully expect that PostgreSQL 9.1 development, and 9.0 backpatching, is going to happen with an early performance farm in place to guard against performance regressions.  If we can backport the new multi-threaded pgbench to older PostgreSQL versions we might include them in the mix as well.  I already have a backport of the 8.3 pgbench, which has a lot of improvements, I maintain just for testing 8.2 systems.  With pgbench as a fairly standalone contrib module, it’s possible to build a later one different from the rest of the system, so long as it doesn’t expect newer database features to exist too.

If that’s something you’re interested in, my talk at the conference is going to map out the foundations I expect it to be built on.  Regardless, hope you can make it to conference and enjoy the long list of talks being presented there.

Share this entry
  • Share on Facebook
  • Share on Twitter
  • Share on WhatsApp
  • Share on LinkedIn
0 replies

Leave a Reply

Want to join the discussion?
Feel free to contribute!

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

Search

Get in touch with us!

Recent Posts

  • Random Data December 3, 2020
  • Webinar: COMMIT Without Fear – The Beauty of CAMO [Follow Up] November 13, 2020
  • Full-text search since PostgreSQL 8.3 November 5, 2020
  • Random numbers November 3, 2020
  • Webinar: Best Practices for Bulk Data Loading in PostgreSQL [Follow Up] November 2, 2020

Featured External Blogs

Tomas Vondra's Blog

Our Bloggers

  • Simon Riggs
  • Alvaro Herrera
  • Andrew Dunstan
  • Craig Ringer
  • Francesco Canovai
  • Gabriele Bartolini
  • Giulio Calacoci
  • Ian Barwick
  • Marco Nenciarini
  • Mark Wong
  • Pavan Deolasee
  • Petr Jelinek
  • Shaun Thomas
  • Tomas Vondra
  • Umair Shahid

PostgreSQL Cloud

2QLovesPG 2UDA 9.6 backup Barman BDR Business Continuity community conference database DBA development devops disaster recovery greenplum Hot Standby JSON JSONB logical replication monitoring OmniDB open source Orange performance PG12 pgbarman pglogical PG Phriday postgres Postgres-BDR postgres-xl PostgreSQL PostgreSQL 9.6 PostgreSQL10 PostgreSQL11 PostgreSQL 11 PostgreSQL 11 New Features postgresql repmgr Recovery replication security sql wal webinar webinars

Support & Services

24/7 Production Support

Developer Support

Remote DBA for PostgreSQL

PostgreSQL Database Monitoring

PostgreSQL Health Check

PostgreSQL Performance Tuning

Database Security Audit

Upgrade PostgreSQL

PostgreSQL Migration Assessment

Migrate from Oracle to PostgreSQL

Products

HA Postgres Clusters

Postgres-BDR®

2ndQPostgres

pglogical

repmgr

Barman

Postgres Cloud Manager

SQL Firewall

Postgres-XL

OmniDB

Postgres Installer

2UDA

Postgres Learning Center

Introducing Postgres

Blog

Webinars

Books

Videos

Training

Case Studies

Events

About Us

About 2ndQuadrant

What does 2ndQuadrant Mean?

News

Careers 

Team Profile

© 2ndQuadrant Ltd. All rights reserved. | Privacy Policy
  • Twitter
  • LinkedIn
  • Facebook
  • Youtube
  • Mail
Trade-offs in Hot Standby Deployments Installing Greenplum Single Node Edition on Amazon’s EC2
Scroll to top
×