Re: PGSQL, checkpoints, and file system syncs

From: Shaun Thomas <sthomas(at)optionshouse(dot)com>
To: 'Reza Taheri' <rtaheri(at)vmware(dot)com>, "pgsql-performance(at)postgresql(dot)org" <pgsql-performance(at)postgresql(dot)org>
Subject: Re: PGSQL, checkpoints, and file system syncs
Date: 2014-04-08 14:00:05
Message-ID: 0683F5F5A5C7FE419A752A034B4A0B97978B5EBE@sswchi5pmbx2.peak6.net
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-performance

> Is there something I can set in the PGSQL parameters or in the file system
> parameters to force a steady flow of writes to disk rather than waiting for
> a sync system call? Mounting with "commit=1" did not make a difference.

The PostgreSQL devs actually had a long talk with the Linux kernel devs over this exact issue, actually. While we wait for the results of that to bear some fruit, I'd recommend using the dirty_background_bytes and dirty_bytes settings both on the VM side, and on the host server. To avoid excessive flushes, you want to avoid having more dirty memory than the system can handle in one gulp.

The dirty_bytes setting will begin flushing disks synchronously when the amount of dirty memory reaches this amount. While dirty_background_bytes will flush in the background when the amount of dirty memory hits the specified limit. It's the background flushing that will prevent your current problems, and it should be set at the same level as the amount of write cache your system has available.

So if you are on a 1GB RAID card, set it to 1GB. Once you have 1GB of dirty memory (from a checkpoint or whatever), Linux will begin flushing.

This is a pretty well-known issue on Linux systems with large amounts of RAM. Most VM servers fit that profile, so I'm not surprised it's hurting you.

--
Shaun Thomas
OptionsHouse | 141 W. Jackson Blvd | Suite 400 | Chicago IL, 60604
312-676-8870
sthomas(at)optionshouse(dot)com

______________________________________________

See http://www.peak6.com/email_disclaimer/ for terms and conditions related to this email

In response to

Responses

Browse pgsql-performance by date

  From Date Subject
Next Message Gerardo Herzig 2014-04-08 17:33:27 Re: [PERFORM] performance drop when function argument is evaluated in WHERE clause
Previous Message Tom Lane 2014-04-08 13:55:38 Re: query against large table not using sensible index to find very small amount of data