PostgreSQL 9.0 High Performance Accelerate your PostgreSQL system and avoid the common pitfalls that can slow it down Gregory Smith BIRMINGHAM - MUMBAI PostgreSQL 9.0 High Performance Copyright © 2010 Packt Publishing All rights reserved. No part of this book may be reproduced, stored in a retrieval system, or transmitted in any form or by any means, without the prior written permission of the publisher, except in the case of brief quotations embedded in critical articles or reviews. Every effort has been made in the preparation of this book to ensure the accuracy of the information presented. However, the information contained in this book is sold without warranty, either express or implied. Neither the author, nor Packt Publishing, and its dealers and distributors will be held liable for any damages caused or alleged to be caused directly or indirectly by this book. Packt Publishing has endeavored to provide trademark information about all of the companies and products mentioned in this book by the appropriate use of capitals. However, Packt Publishing cannot guarantee the accuracy of this information. First published: October 2010 Production Reference: 1141010 Published by Packt Publishing Ltd. 32 Lincoln Road Olton Birmingham, B27 6PA, UK. ISBN 978-1-849510-30-1 www.packtpub.com Cover Image by Asher Wishkerman (a.wishkerman@mpic.de) Credits Author Gregory Smith Reviewers Kevin Grittner Jim Mlodgenski Scott Marlowe Acquisition Editor Sarah Cullington Development Editors Hyacintha D'Souza Mayuri Kokate Technical Editors Sakina Kaydawala Alfred John Indexer Hemangini Bari Tejal Daruwale Editorial Team Leader Mithun Sehgal Project Team Leader Lata Basantani Project Coordinator Srimoyee Ghoshal Proofreader Aaron Nash Production Coordinator Aparna Bhagat Cover Work Aparna Bhagat About the Author Gregory Smith is a Principal Consultant for international database professional services rm 2ndQuadrant, and founder of the company's rst United States ofce. Writing about PostgreSQL represents his second foray into teaching database performance tuning. Greg wrote a small, free e-book titled Progress Performance FAQ in 1995, covering the basics of how to make the Progress 4GL and its associated database run faster. In 2001, he converted exclusively to using PostgreSQL 7.0 for projects, and has been watching the complexity of problems the database is capable of solving increase with every release since. Greg has contributed feature additions to every PostgreSQL version since 8.3. He's also the creator of a growing set of add-on tools for the database, currently including pgtune, pgbench-tools, peg, and 2warm. I was able to focus on the material in this book well enough to do it justice only through the support provided by Simon Riggs and the rest of the 2ndQuadrant staff around the world. The exposure to interesting problems to solve, and resources to solve them, has made working with 2ndQuadrant staff and clients a fertile source for PostgreSQL performance ideas over the last year. The writing schedule pace needed to deliver a current book covering a major new database release just after it ships is grueling. I'd never have made it through so many weeks of working all seven days without the support of my family: Judy, Jerry, and Amanda. Finally, the material in this book only exists because of the hundreds of contributors to the PostgreSQL project. And without the free sharing of ideas on mailing lists like pgsql-performance and pgsql- hackers the last few years, I'd never have been able to collect up such a wide survey of common performance issues. Whether it was having my own questions answered, or carefully considering how to answer someone else's, the interaction on those mailing lists has been vital to forming the ideas of this book. About the Reviewers Kevin Grittner has worked in the computer industry since 1972. While he has lled many roles during decades of consulting, working with databases has been a major focus—particularly in terms of optimization and providing frameworks for efcient application development against a database. In the mid 80s, he was the architect and primary author of the PROBER Database and Development Environment, which was never released commercially but enjoyed widespread use in certain vertical markets, such as re departments, hospitals, and probation and parole agencies. Jim Mlodgenski is Chief Architect at EnterpriseDB. He is one of EnterpriseDB's rst employees, having joined the company in May, 2005. Over several years, Jim has been responsible for key activities such as sales engineering, professional services, strategic technology solutions delivery, and customer education. Prior to joining EnterpriseDB, Jim was a partner and architect at Fusion Technologies, a technology services company. For nearly a decade, Jim developed early designs and concepts for Fusion's consulting projects and specialized in Oracle application development, web development, and open source information architectures. I want to thank my wonderful wife Stacie and awesome son Paul for supporting me. Scott Marlowe has over 25 years of experience in software development, system administration, and database development. His rst program was a gradebook program for the Air Force and he's been hooked ever since.Scott works for Edline/Schoolfusion as a systems administrator and DBA. I'd like to thank my two sons for being the greatest kids in the world, and my best friend Darren for all the expertise and knowledge we've shared in the last decade or so. Table of Contents Preface 1 Chapter 1: PostgreSQL Versions 7 Performance of historical PostgreSQL releases 8 Choosing a version to deploy 9 Upgrading to a newer major version 9 Upgrades to PostgreSQL 8.3+ from earlier ones 10 Minor version upgrades 11 PostgreSQL or another database? 12 PostgreSQL tools 12 PostgreSQL contrib 13 Finding contrib modules on your system 13 Installing a contrib module from source 14 Using a contrib module 15 pgFoundry 15 Additional PostgreSQL-related software 16 PostgreSQL application scaling lifecycle 16 Performance tuning as a practice 17 Summary 19 Chapter 2: Database Hardware 21 Balancing hardware spending 21 CPUs 21 Memory 22 Disks 23 RAID 24 Drive error handling 26 Hard drive reliability studies 27 Drive firmware and RAID 27 SSDs 28 Table of Contents [ ii ] Disk controllers 29 Hardware and Software RAID 29 Recommended disk controllers 30 Attached storage—SAN and NAS 32 Reliable controller and disk setup 34 Write-back caches 34 Sources of write-back caching 35 Disk controller monitoring 36 Disabling drive write caches 37 Performance impact of write-through caching 38 Summary 39 Chapter 3: Database Hardware Benchmarking 41 CPU and memory benchmarking 41 memtest86+ 42 STREAM memory testing 42 STREAM and Intel vs. AMD 43 CPU benchmarking 44 Sources of slow memory and processors 45 Physical disk performance 47 Random access and I/Os Per Second 47 Sequential access and ZCAV 48 Short stroking 49 Commit rate 49 PostgreSQL test_fsync 50 INSERT rate 50 Windows commit rate 50 Disk benchmarking tools 50 hdtune 51 Short stroking tests 52 IOPS 53 Unpredictable performance and Windows 54 dd 55 bonnie++ 56 bonnie++ 2.0 57 bonnie++ ZCAV 58 sysbench 60 Seek rate 61 fsync commit rate 61 Complicated disk benchmarks 62 Sample disk results 63 Disk performance expectations 65 Sources of slow disk and array performance 65 Summary 67 Table of Contents [ iii ] Chapter 4: Disk Setup 69 Maximum filesystem sizes 69 Filesystem crash recovery 70 Journaling filesystems 71 Linux filesystems 72 ext2 72 ext3 73 ext4 75 XFS 75 Other Linux filesystems 77 Write barriers 77 Drive support for barriers 78 Filesystem support for barriers 79 General Linux filesystem tuning 79 Read-ahead 79 File access times 80 Read caching and swapping 81 Write cache sizing 81 I/O scheduler elevator 82 Solaris and FreeBSD filesystems 84 Solaris UFS 85 FreeBSD UFS2 86 ZFS 87 Windows filesystems 89 FAT32 89 NTFS 89 Adjusting mounting behaviour 90 Disk layout for PostgreSQL 91 Symbolic links 91 Tablespaces 91 Database directory tree 92 Temporary files 93 Disk arrays, RAID, and disk layout 94 Disk layout guidelines 96 Summary 97 Chapter 5: Memory for Database Caching 99 Memory units in the postgresql.conf 99 Increasing UNIX shared memory parameters for larger buffer sizes 100 Kernel semaphores 102 Estimating shared memory allocation 102 Inspecting the database cache 104 Installing pg_buffercache into a database 105 Database disk layout 106 [...]... that your PostgreSQL destination is /usr/local /postgresql and that there's a directory there named source you put the source code into (this is not intended to be a typical or recommended structure you should use): $ cd /usr/local /postgresql/ source $ cd contrib/pg_buffercache/ $ make $ make install /bin/mkdir -p '/usr/local /postgresql/ lib /postgresql' /bin/mkdir -p '/usr/local /postgresql/ share /postgresql/ contrib'... '/usr/local /postgresql/ share /postgresql/ contrib' /bin/sh / /config/install-sh -c -m 755 pg_buffercache.so '/usr/local/ postgresql/ lib /postgresql/ pg_buffercache.so' /bin/sh / /config/install-sh -c -m 644 /uninstall_pg_buffercache.sql '/usr/local /postgresql/ share /postgresql/ contrib' /bin/sh / /config/install-sh -c -m 644 pg_buffercache.sql '/usr/local/ postgresql/ share /postgresql/ contrib' [ 14 ] Chapter 1 It's also possible to build and install... related to less popular PostgreSQL features Be sure to read the documentation of the upgrade tool very carefully Starting in PostgreSQL 9.0, this module is included with the core database, with the name changed to pg_upgrade While all in-place upgrades have some risk and need careful testing, in many cases, pg_upgrade will take you from 8.3 or 8.4 to 9.0 and hopefully beyond The PostgreSQL development... Common Problems includes a reference guide to what performance- related features were added to each major version of PostgreSQL, from 8.1 through 9.0 You might discover that one of the features only available in a very recent version is compelling to you, and therefore have a strong preference to use that one Many of these version-specific changes are also highlighted throughout the book Upgrading to a... pg_restore can be a much better alternative in newer PostgreSQL versions that include a version with parallel restore capabilities [] PostgreSQL Versions If you are using a system that doesn't easily allow you to run more than one system with PostgreSQL version at a time, such as the current RedHat Linux RPM packages, getting both old and new versions of PostgreSQL installed on your system at the same... emulation of DTrace 410 412 412 [ xii ] Table of Contents Performance related features by version Aggressive PostgreSQL version upgrades 8.1 8.2 8.3 8.4 9.0 413 413 415 415 416 417 419 Summary 424 Replication Queries and EXPLAIN Database development Configuration and monitoring Tools Internals Index 419 420 421 422 423 423 427 [ xiii ] Preface PostgreSQL has become an increasingly viable database platform... their application is running for fear that a change in the database will cause a problem This should never be the case for PostgreSQL The policy of the PostgreSQL project described at http://www .postgresql. org/support/versioning states very clearly: While upgrades always have some risk, PostgreSQL minor releases fix only frequently-encountered security and data corruption bugs to reduce the risk of upgrading... report of a problem to one of the PostgreSQL mailing lists is resolved in the latest minor version update compatible with that installation, and upgrading to that version is all that's needed to make the issue go away [ 11 ] PostgreSQL Versions PostgreSQL or another database? There are certainly situations where other database solutions will perform better For example, PostgreSQL is missing features needed... still have a performance advantage worth paying for There are also several PostgreSQL- derived databases that include features, making them more appropriate for data warehouses and similar larger systems Examples include Greenplum, Aster Data, and Netezza For some types of web applications, you can only get acceptable performance by cutting corners on the data integrity features in ways that PostgreSQL. .. ground between those two extremes, PostgreSQL performance in 8.3 reached a point where it's more likely you'll run into the limitations of your hardware or application design before the database is your limiting factor Moreover, some of PostgreSQL' s traditional strengths, like its ability to handle complicated queries well and its heavy programmability, are all still there PostgreSQL tools If you're used . PL/Proxy 393 Sharding 394 Scaling with GridSQL 395 Summary 396 Chapter 16: Avoiding Common Problems 399 Bulk loading 399 Loading methods 399 External loading programs 400 Tuning for bulk loads 401 Skipping. 87 Windows filesystems 89 FAT32 89 NTFS 89 Adjusting mounting behaviour 90 Disk layout for PostgreSQL 91 Symbolic links 91 Tablespaces 91 Database directory tree 92 Temporary files 93 Disk arrays, RAID,. PostgreSQL 9. 0 High Performance Accelerate your PostgreSQL system and avoid the common pitfalls that can slow it down Gregory Smith BIRMINGHAM - MUMBAI PostgreSQL 9. 0 High Performance Copyright