Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

On Wed, Feb 10, 2016 at 2:15 PM, Andres Freund <andres@anarazel.de> wrote:

Afaik that's not the case on any recent operating system/hardware. So
perhaps we should just remove all of those blurbs, or just replace them
with something like "on some older systems the effective resolution of
sleep delays is limited to multiples of 10 milliseconds"?

Or just remove it entirely. Really, I can't see that that's likely to
matter when it does apply. Also, don't forget to do the same with
bgwriter_delay.

commit_delay doesn't have any guidance like this, where it could
certainly matter, because optimal settings are rarely greater than 10
milliseconds.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Mon, Feb 15, 2016 at 11:23 AM, Peter Geoghegan <pg@heroku.com> wrote:

commit_delay doesn't have any guidance like this, where it could
certainly matter, because optimal settings are rarely greater than 10
milliseconds.

Actually, it does, but it's in "29.4. WAL Configuration", not next to
the documentation for commit_delay.

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Feb 10, 2016 at 4:15 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

Several places in our docs have blurbs like

Note that on many systems, the effective resolution of sleep delays is
10 milliseconds; setting <varname>wal_writer_delay</> to a value that
is not a multiple of 10 might have the same results as setting it to
the next higher multiple of 10.

Afaik that's not the case on any recent operating system/hardware. So
perhaps we should just remove all of those blurbs, or just replace them
with something like "on some older systems the effective resolution of
sleep delays is limited to multiples of 10 milliseconds"?

I guess we should probably explain what is actually happening, namely
that the precise sleep duration is delegated to the operating system
scheduler which may cause the process to sleep longer than requested.

merlin

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On February 16, 2016 3:09:16 AM GMT+01:00, Merlin Moncure

I guess we should probably explain what is actually happening, namely
that the precise sleep duration is delegated to the operating system
scheduler which may cause the process to sleep longer than requested.

In not really seeing why: This is reference documentation about config parameters and such, not an OS development guide. Additionally most of these parameters actually aren't get sensitive about slightly increased sleep times/timeouts.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

Several places in our docs have blurbs like

Note that on many systems, the effective resolution of sleep delays is
10 milliseconds; setting <varname>wal_writer_delay</> to a value that
is not a multiple of 10 might have the same results as setting it to
the next higher multiple of 10.

Afaik that's not the case on any recent operating system/hardware. So
perhaps we should just remove all of those blurbs, or just replace them
with something like "on some older systems the effective resolution of
sleep delays is limited to multiples of 10 milliseconds"?

Hmm, is that true? What we do we think the resolution is on modern
systems? I would not have guessed that to be inaccurate.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On February 16, 2016 9:06:57 AM GMT+01:00, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund <andres@anarazel.de>
wrote:

Hi,

Several places in our docs have blurbs like

Note that on many systems, the effective resolution of sleep delays

is

10 milliseconds; setting <varname>wal_writer_delay</> to a value

that

is not a multiple of 10 might have the same results as setting it to
the next higher multiple of 10.

Afaik that's not the case on any recent operating system/hardware. So
perhaps we should just remove all of those blurbs, or just replace

them

with something like "on some older systems the effective resolution

of

sleep delays is limited to multiples of 10 milliseconds"?

Hmm, is that true? What we do we think the resolution is on modern
systems? I would not have guessed that to be inaccurate.

Depends in a lot of factors. The biggest being how busy you're system is. On an mostly idle system (i.e. workout so CPUs being overcommitted) you can get resolutions considerably below one millisecond. HPET can get you very low latencies, making OS scheduling latencies the dominant factor, but one that can be tuned.

Andres

--- 
Please excuse brevity and formatting - I am writing this on my mobile phone.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On 2016-02-16 09:13:09 +0100, Andres Freund wrote:

What we do we think the resolution is on modern

systems? I would not have guessed that to be inaccurate.

Depends in a lot of factors. The biggest being how busy you're system
is. On an mostly idle system (i.e. workout so CPUs being
overcommitted) you can get resolutions considerably below one
millisecond. HPET can get you very low latencies, making OS scheduling
latencies the dominant factor, but one that can be tuned.

To back up my claim on this, read man 7 time
(e.g. http://linux.die.net/man/7/time), especially "The software clock,
HZ, and jiffies" and "High-resolution timers". To quote the most salient
point:

Before Linux 2.6.21, the accuracy of timer and sleep system calls (see
below) was also limited by the size of the jiffy.

Since Linux 2.6.21, Linux supports high-resolution timers (HRTs),
optionally configurable via CONFIG_HIGH_RES_TIMERS. On a system that
supports HRTs, the accuracy of sleep and timer system calls is no longer
constrained by the jiffy, but instead can be as accurate as the hardware
allows (microsecond accuracy is typical of modern hardware).

Andres

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund <andres@anarazel.de> wrote:

On 2016-02-16 09:13:09 +0100, Andres Freund wrote:

What we do we think the resolution is on modern

systems? I would not have guessed that to be inaccurate.

Depends in a lot of factors. The biggest being how busy you're system
is. On an mostly idle system (i.e. workout so CPUs being
overcommitted) you can get resolutions considerably below one
millisecond. HPET can get you very low latencies, making OS scheduling
latencies the dominant factor, but one that can be tuned.

To back up my claim on this, read man 7 time
(e.g. http://linux.die.net/man/7/time), especially "The software clock,
HZ, and jiffies" and "High-resolution timers". To quote the most salient
point:

Interesting, thanks.

--
Robert Haas
EnterpriseDB: http://www.enterprisedb.com
The Enterprise PostgreSQL Company

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

Robert Haas <robertmhaas@gmail.com> writes:

On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund <andres@anarazel.de> wrote:

To back up my claim on this, read man 7 time
(e.g. http://linux.die.net/man/7/time), especially "The software clock,
HZ, and jiffies" and "High-resolution timers". To quote the most salient
point:

Interesting, thanks.

Yeah. "grep resolution /proc/timer_list" on my RHEL6 box says that the
timers all have 1ns resolution!

Given this, I'm on board with just removing the weasel-wording about
timer resolution, except maybe for commit_delay where useful values
are small enough that it's a hazard on old systems.

regards, tom lane

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 16, 2016 at 12:06 AM, Robert Haas <robertmhaas@gmail.com> wrote:

On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund <andres@anarazel.de> wrote:

Hi,

Several places in our docs have blurbs like

Note that on many systems, the effective resolution of sleep delays is
10 milliseconds; setting <varname>wal_writer_delay</> to a value that
is not a multiple of 10 might have the same results as setting it to
the next higher multiple of 10.

Afaik that's not the case on any recent operating system/hardware. So
perhaps we should just remove all of those blurbs, or just replace them
with something like "on some older systems the effective resolution of
sleep delays is limited to multiples of 10 milliseconds"?

Hmm, is that true? What we do we think the resolution is on modern
systems? I would not have guessed that to be inaccurate.

time perl -le 'my $wait=0.00001; select undef,undef,undef,$wait
foreach (1..1/$wait*1); warn "should be 1 second"'

On CentOS 6.7 (not exactly modern) and Ubuntu Trusty, if I ask for 10
microsecond delays, I get between 70 and 100 microseconds delays
(depending on the VM software, mostly, it seems). So at least 100
fold better than the 10ms.

Of course if processes are fighting over CPU, you might do worse.

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers

On Tue, Feb 16, 2016 at 7:10 AM, Tom Lane <tgl@sss.pgh.pa.us> wrote:

Given this, I'm on board with just removing the weasel-wording about
timer resolution, except maybe for commit_delay where useful values
are small enough that it's a hazard on old systems.

+1, but I'd move the guidance for commit_delay's effective resolution
from "29.4. WAL Configuration" to where commit_delay is introduced,
"18.5. Write Ahead Log".

--
Peter Geoghegan

--
Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-hackers