LinuxFest Northwest 2014

Seattle Postgres Users Group 1st Tuesday of Every Month @ 7PM 1100 Eastlake, Seattle, WA http://www.SeaPUG.org http://www.meetup.com/Seattle-Postgres-User-Group-SEAPUG/

SeaPUG is Hosted by:

Tuning Postgres 9.x Servers By Lloyd Albin

4/26/2014 1 Tuning Postgres 9.x Servers

This presentation is based on • PostgreSQL 9.0 High Performance by Gregory

Smith

• pgTune by Gregory Smith

• Blog by Robert Haas http://rhaas.blogspot.com/2012/03/tuning-sharedbuffers-and-walbuffers.html

• Five Steps to PostgreSQL Performance by Josh Berkus – Used for flavor of database. http://www.pgexperts.com/document.html?id=36

4/26/2014 2 Tuning Postgres 9.x Servers

What to Tune These are the items we are going to cover:

shared_buffers

effective_cache_size

work_mem

checkpoint_segments

wal_buffers

maintenance_work_mem

4/26/2014 3 Tuning Postgres 9.x Servers

Additional Items These items are used to understand the total RAM situation:

max_connections

autovacuum_max_workers

block_size

Other Information:

Total Server RAM

VM RAM

max_locks_per_transactions

max_prepared_transactions

wal_block_size

Database Size

4/26/2014 4 Tuning Postgres 9.x Servers

What is your Flavor of Database Web Application (Web)

DB smaller than RAM

90% or more “one-liner” queries

Online Transaction Processing (OLTP)

DB slightly larger than RAM to 1TB

20-40% small data write queries, some large transactions

Data Warehouse (DW)

Large to huge databases (100GB to 100TB)

Large complex reporting queries

Large bulk loads of data

Also called “Decision Support” or “Business Intelligence”

4/26/2014 5 Tuning Postgres 9.x Servers

Shared Buffers 4/26/2014 6 Tuning Postgres 9.x Servers

shared_buffers The "lore" for sizing shared_buffers generally specifies a suggestion in terms of a percentage of system RAM. Some advocate only 10-15%. The thorough academic exploration in the paper "Tuning Database Configuration Parameters with iTuned" at http://www.cs.duke.edu/~shivnath/papers/ituned.pdf found 40 percent optimal on a 1 GB system being tested on a wide range of queries. And occasionally reports appear where 60 percent or more of total RAM turns out to be optimal. – Page 116

Generally, if you have a server where OS overhead is small relative to total memory (any modern system with 1 GB or more of RAM), giving the database 25 percent of total RAM is a reasonable starting setting for shared_buffers in the middle of the effective range. It may not be optimal, but it's unlikely to be so high that double buffering becomes an issue. And it's likely to be far better than the tiny default forced on the database by the low shared memory parameters of typical operating system kernel defaults. – Page 117

4/26/2014 7 Tuning Postgres 9.x Servers

shared_buffers Very large systems: Experiments on systems with large amounts of RAM suggest that likely due to internal partitioning issues in the buffer cache (which haven't been adjusted since PostgreSQL 8.4), setting it larger than approximately 8 GB can be counterproductive. If you have a system with a very large amount of RAM, there is not much information available on where cache sizing breaks down, but it's likely in the multiple gigabyte range. On servers with 8 GB or more of RAM, you might start with only 2 GB dedicated to the database, and only resize upward if cache inspection suggests it's likely to be productive. – Page 118

4/26/2014 8 Tuning Postgres 9.x Servers

shared_buffers For shared_buffers, the quick answer is to allocate about 25% of system memory to shared_buffers, as recommended by the official documentation and by the wiki article on Tuning Your PostgreSQL server, but not more than about 8GB on Linux or 512MB on Windows, and sometimes less. However, I've recently become aware of a number of cases which suggest that higher values may perform much better. PostgreSQL uses the operating system's memory for caching, but, as recent performance results have shown, there can be a huge performance benefit to having the entire database in shared_buffers as opposed to merely having it in RAM. Several EnterpriseDB customers or potential customers have reported excellent results from cranking up shared_buffers to very large values, even giving PostgreSQL the lion's share of system memory for its own use. This flies in the face of some conventional wisdom that PostgreSQL doesn't handle large shared_buffers settings well, but enough people have reported good results that it seems worth taking this strategy seriously. – Robert Haas

4/26/2014 9 Tuning Postgres 9.x Servers

shared_buffers Use 25% of RAM up to 8GB unless you can fit your entire database + room for queries within 50% of RAM. I use 8GB for the query space.

If you can’t fit your entire database in memory, the other thing to look at is can you fit the portion that you use on a daily basis in memory such as Paul Gross said that Braintree does with their database.

PgTune: Web, OLTP, DW, Mixed - 25% of RAM Desktop – 6.25% of RAM

4/26/2014 10 Tuning Postgres 9.x Servers

effective_cache_size

I use 72% of RAM.

PgTune: Web, OLTP, DW, Mixed - 75% of RAM Desktop – 25% of RAM

4/26/2014 11 Tuning Postgres 9.x Servers

The same rough rule of thumb that would put shared_buffers at 25 percent of system memory would set effective_cache_size to between 50 and 75 percent of RAM. – Page 131

work_mem

I use RAM / max_connections. This is one of the most important setting for how your server calculates the query plan.

PgTune: Web, OLTP, - RAM / max_connections DW, Mixed - RAM / max_connections / 2 Desktop – RAM / max_connections / 6

4/26/2014 12 Tuning Postgres 9.x Servers

In practice, there aren't that many sorts going on in a typical query, usually only one or two. And not every client that's active will be sorting at the same time. The normal guidance for work_mem is to consider how much free RAM is around after shared_buffers is allocated (the same OS caching size figure needed to compute effective_cache_size), divide by max_connections, and then take a fraction of that figure; a half of that would be an aggressive work_mem value. In that case, only if every client had two sorts active all at the same time would the server be likely to run out of memory, which is an unlikely scenario. – Page 142

The future of work_mem

4/26/2014 13 Tuning Postgres 9.x Servers

On 05/21/13 21:13, Simon Riggs wrote:

I worked up a small patch to support Terabyte setting for memory. Which is OK, but it only works for 1TB, not for 2TB or above.

Which highlights that since we measure things in kB, we have an inherent limit of 2047GB for our memory settings. It isn't beyond belief we'll want to go that high, or at least won't be by end 2014 and will be annoying sometime before 2020.

Solution seems to be to support something potentially bigger than INT for GUCs. So we can reclassify GUC_UNIT_MEMORY according to the platform we're on.

Opinions?

-- Simon Riggs http://www.2ndQuadrant.com/ PostgreSQL Development, 24x7 Support, Training & Services

On 05/21/13 21:47, Galvin Flower wrote: I suspect it should be fixed before it starts being a problem, for 2 reasons: 1. best to panic early while we have time (or more prosaically: doing it soon gives us more time to get it right without undue pressure) 2. not able to cope with 2TB and above might put off companies with seriously massive databases from moving to Postgres Probably an idea to check what other values should be increased as well. Cheers, Gavin

maintenance_work_mem

I use 25% of RAM / autovacuum_max_workers.

PgTune: Web, OLTP, Mixed, Desktop - RAM / 16 DW - RAM / 8

4/26/2014 14 Tuning Postgres 9.x Servers

Assuming you haven't increased the number of autovacuum workers, a typical high setting for this value on a modern server would be at five percent of the total RAM, so that even five such processes wouldn't exceed a quarter of available memory. This works out to approximately 50 MB of maintainance_work_mem per GB of server RAM. – Page 135

checkpoint_segments

I use 100 for our databases, but otherwise would recommend using 32.

PgTune: Web – 8 OLTP, Mixed - 16 DW – 64 Desktop - 3

4/26/2014 15 Tuning Postgres 9.x Servers

The general rule of thumb you can extract here is that for every 32 checkpoint segments, expect at least 1 GB of WAL files to accumulate. As database crash recovery can take quite a while to process even that much data, 32 is as high as you want to make this setting for anything but a serious database server. The default of 3 is very low for most systems though; even a small install should consider an increase to at least 10.

Normally, you'll only want a value greater than 32 on a smaller server when doing bulk-loading, where it can help performance significantly and crash recovery isn't important. Databases that routinely do bulk loads may need a higher setting. – Page 137

wal_buffers

I use 32 MB for the wal buffers.

PG Tune: 512 * checkpoint_segments

4/26/2014 16 Tuning Postgres 9.x Servers

While the documentation on wal_buffers suggests that the default of 64 KB is sufficient as long as no single transaction exceeds that value, in practice write-heavy benchmarks see optimal performance at higher values than you might expect from that, at least 1 MB or more. With the only downside being the increased use of shared memory, and as there's no case where more than a single WAL segment could need to be buffered, given modern server memory sizes the normal thing to do nowadays is to just set:

wal_buffers=16MB

Then forget about it as a potential bottleneck or item to tune further. Only if you're tight on memory should you consider a smaller setting. – Page 138

Calculating memory Connections = 1800 + 270 * max_locks_per_transaction

Autovacuum workers = connections mem * autovacuum_max_workers

Prepared transactions = (770 + 270 * max_locks_per_transaction) * max_prepared_transactions

Shared disk buffers = (block_size + 208) * (shared_buffers / block_size)

WAL buffers = (wal_block_size + 8) * (wal_buffers / wal_block_size)

Fixed space requirements = 770kB

Total shared memory = sum of the above memory

4/26/2014 17 Tuning Postgres 9.x Servers

Excel Spreadsheet Fill in: Database size VM RAM Machine RAM max_connections max_locks_per_transaction autovacuum_max_workers

What I am looking for is not going over 50% of the VM RAM.

This server is now running queries in half the time due to being aggressively tuned vers conservatively tuned.

4/26/2014 18 Tuning Postgres 9.x Servers

Basic Tuning Dedicated Server

Database Size (GB) 36

RAM (GB) 128 128

shared_buffers (GB) 50 25% 50%

max_connections 400

Start Server with above parms

effective_cache_size (GB) 96 75% 50-75%

work_mem (MB) 327 50%

maintenance_work_mem (GB) 10 25% 50

checkpoint_segments 100 32

wal_buffers (MB) 32 512

max_locks_per_transaction 1500

autovacuum_max_workers 3

max_prepared_transactions 0

block_size (bytes) 8192

wal_block_size (bytes) 8192

Shared Memory Usage

Conenctions (MB) 155.1818848

Autovacuum workers (MB) 1.163864136

Prepared transactions (MB) 0

Shared disk buffers (GB) 51.26953125

WAL buffers (MB) 32.03125

Fixed space requirements (kB) 770

Total Shared Memory (GB) 51.45422749 40% of VM RAM

40% of Physical RAM

Excel Spreadsheet This server has a larger database and is running in a VM. The other VM is running the webserver.

This server is now running about 25% faster.

4/26/2014 19 Tuning Postgres 9.x Servers

Basic Tuning Dedicated Server

Database Size (GB) 86

RAM (GB) 48 80

shared_buffers (GB) 20 25%

max_connections 150

Start Server with above parms

effective_cache_size (GB) 34 72% 50-75%

work_mem (MB) 327 50%

maintenance_work_mem (GB) 1 25% 50

checkpoint_segments 100 32

wal_buffers (MB) 32 512

max_locks_per_transaction 150

autovacuum_max_workers 10

max_prepared_transactions 0

block_size (bytes) 8192

wal_block_size (bytes) 8192

Shared Memory Usage

Conenctions (MB) 6.051063538

Autovacuum workers (MB) 0.403404236

Prepared transactions (MB) 0

Shared disk buffers (GB) 20.5078125

WAL buffers (MB) 32.03125

Fixed space requirements (kB) 770

Total Shared Memory (GB) 20.54613054 43% of VM RAM

26% of Physical RAM