Loading
PostgreSQL Performance Tuning
Tweak your hardware to get the most from this open-source database.
The physical nature of disk drives makes their performance characteristics different from the other storage areas mentioned in this article. The other storage areas can access any byte with equal speed. Disk drives, with their spinning platters and moving heads, access data near the head's current position much faster than data farther away.
Moving the disk head to another cylinder on the platter takes quite a bit of time. UNIX kernel developers know this. When storing a large file on disk, they try to place the pieces of the file near each other. For example, suppose a file requires ten blocks on disk. The operating system may place blocks 1-5 on one cylinder and blocks 6-10 on another cylinder. If the file is read from beginning to end, only two head movements are required—one to get to the cylinder holding blocks 1-5, and another to get to blocks 6-10. However, if the file is read non-sequentially, e.g., blocks 1,6,2,7,3,8,4,9,5,10; ten head movements are required. As you can see, with disks, sequential access is much faster than random access. This is why PostgreSQL prefers sequential scans to index scans if a significant portion of the table needs to be read. This also highlights the value of the cache.
The disk head moves around quite a bit during database activity. If too many read/write requests are made, the drive can become saturated, causing poor performance (Vmstat and sar can provide information on the amount of activity on each disk drive).
One solution to disk saturation is to move some of the PostgreSQL data files to other disks. Remember, moving the files to other filesystems on the same disk drive does not help. All filesystems on a drive use the same disk heads. Database access can be spread across disk drives in several ways:
Moving Databases—initlocation allows you to create databases on different drives.
Moving Tables—symbolic links allow you to move tables and indexes to different drives. Movement should only be done while PostgreSQL is shut down. Also, PostgreSQL doesn't know about the symbolic links, so if you delete the table and recreate it, it will be created in the default location for that database. In 7.1, pg_database.oid and pg_class.relfilenode map database, table and index names to their numeric filenames.
Moving Indexes—symbolic links allow moving indexes to different drives from their heap tables. This allows an index scan to be performed on one disk while a second disk performs heap lookups.
Moving Joins—symbolic links allow the movement of joined tables to separate disks. If tables A and B are joined, lookups of table A can be performed on one drive while lookups of table B can be done on a second drive.
Moving Log—symbolic links can be used to move the pg_xlog directory to a different disk drive. (Pg_xlog exists in PostgreSQL releases 7.1 and later.) Unlike other writes, PostgreSQL log writes must be flushed to disk before completing a transaction. The cache cannot be used to delay these writes. Having a separate disk for log writes allows the disk head to stay on the current log cylinder so writes can be performed without head movement delay. You can use the postgres -F parameter to prevent log writes from being flushed to disk, but an operating system crash may require a restore from backup.
Other options include the use of RAID features to spread a single filesystem across several drives.
Fortunately, PostgreSQL doesn't require much tuning. Most parameters are automatically adjusted to maintain optimum performance. Cache size and sort size are two parameters administrators can control to make better use of available memory. Disk access can also be spread across drives. Other parameters may be set in share/postgresql.conf.sample. You can copy this file to data/postgresql.conf to experiment with some of PostgreSQL's even more exotic parameters.
______________________
White Paper
Fabric-Based Computing Enables Optimized Hyperscale Data Centers
Today’s modular x86 servers are compute-centric, designed as a least common denominator to support a wide range of IT workloads. Those generic, virtualized IT workloads have much different resource optimization requirements than hyperscale and cloud applications. They have resulted in a “one size fits all” enterprise IT architecture that is not optimized for a specific set of IT workloads, and especially not emerging hyperscale workloads, such as web applications, big data, and object storage. In this report, you will learn how shifting the focus from traditional compute-centric IT architectures to an innovative disaggregated fabric-based architecture can optimize and scale your data center.
Sponsored by AMD
White Paper
Red Hat White Paper: Using an Open Source Framework to Catch the Bad Guy
Built-in forensics, incident response, and security with Red Hat Enterprise Linux 6
Every security policy provides guidance and requirements for ensuring adequate protection of information and data, as well as high-level technical and administrative security requirements for a system in a given environment. Traditionally, providing security for a system focuses on the confidentiality of the information on it. However, protecting the data integrity and system and data availability is just as important. For example, when processing United States intelligence information, there are three attributes that require protection: confidentiality, integrity, and availability.
Learn more about catching the bad guy in this free white paper.
Sponsored by DLT Solutions
- RSS Feeds
- Making Linux and Android Get Along (It's Not as Hard as It Sounds)
- New Products
- Drupal Is a Framework: Why Everyone Needs to Understand This
- A Topic for Discussion - Open Source Feature-Richness?
- Home, My Backup Data Center
- Validate an E-Mail Address with PHP, the Right Way
- Tech Tip: Really Simple HTTP Server with Python
- New Products
- Trying to Tame the Tablet
- git-annex assistant
3 hours 34 min ago - direct cable connection
3 hours 56 min ago - Agreed on AirDroid. With my
4 hours 7 min ago - I just learned this
4 hours 11 min ago - enterprise
4 hours 41 min ago - not living upto the mobile revolution
7 hours 32 min ago - Deceptive Advertising and
8 hours 8 min ago - Let\'s declare that you have
8 hours 9 min ago - Alterations in Contest Due
8 hours 10 min ago - At a numbers mindset, your
8 hours 11 min ago
Enter to Win an Adafruit Prototyping Pi Plate Kit for Raspberry Pi
It's Raspberry Pi month at Linux Journal. Each week in May, Adafruit will be giving away a Pi-related prize to a lucky, randomly drawn LJ reader. Winners will be announced weekly.
Fill out the fields below to enter to win this week's prize-- a Prototyping Pi Plate Kit for Raspberry Pi.
Congratulations to our winners so far:
- 5-8-13, Pi Starter Pack: Jack Davis
- 5-15-13, Pi Model B 512MB RAM: Patrick Dunn
- Next winner announced on 5-21-13!
Free Webinar: Linux Backup and Recovery
Most companies incorporate backup procedures for critical data, which can be restored quickly if a loss occurs. However, fewer companies are prepared for catastrophic system failures, in which they lose all data, the entire operating system, applications, settings, patches and more, reducing their system(s) to “bare metal.” After all, before data can be restored to a system, there must be a system to restore it to.
In this one hour webinar, learn how to enhance your existing backup strategies for better disaster recovery preparedness using Storix System Backup Administrator (SBAdmin), a highly flexible bare-metal recovery solution for UNIX and Linux systems.
Developer Poll
Comments
Found this article useful
I found this updated PostgreSQL Tuning article very useful.
This guide was very helpful.
This guide was very helpful. Please ignore the ignorant posts saying otherwise. I'd be scared to have those people managing my data.
A brief overview for database system
This article is performance tunning for newbie, nothing to be used as day-a-day book. But one question is important, no one that must tune the pgsql is really newbie about db system. ;-(
Breno Leitao
Re: PostgreSQL Performance Tuning
Hello,
After learning this great article which provides the reader with some very useful and basic understandings of the data path in postgreSQL backend, I must say I have been a little shock by the comments I saw from people who are just waiting others to do what they should also be trying to do. These kinds of comments do not look like an encouragment to Bruce who deserves a lot of credit for the simplicity of his writing, and above all for his willingness toi help others.
Thanks Bruce, your article help explain easily some basic backgrounds required to tune wisely a PostgreSQL database.
Paul
Re: PostgreSQL Performance Tuning
HELLO! CAN SOMEONE TELL ME WHAT THIS ARTICLE IS ABOUT. I EXPECTED TO OPTIMIZE MY DATABASE AFTER READING THIS ARTICLE BUT IT SEEMS THAT I WAS BETTER-OFF WITHOUT READING IT!!!!
Re: PostgreSQL Performance Tuning
I was hoping to learn what the vacuum and vacuum analyze commands do, maybe read about the performance benefits of using them or find out other methods to make my queries run faster. I guess the guy just wanted to advertise his book. Thanks for nothing.
Re: PostgreSQL Performance Tuning
not only is not really about PostgreSQL specifically, but it also has incorrect links.
Re: PostgreSQL Performance Tuning
This document should be called General Overview of Performance Tuning. It provides almost no technical detail or insight into the tuning process. I would like to see an article which delves deeper into the issue and provides some real numbers from real applications on some real hardware. After reading the article, one is no more enabled to do any tuning on a PostgreSQL DB than if one didn't read the article at all. I am disappointed.
Re: PostgreSQL Performance Tuning
This is a test from mso without cookies.