Обсуждение: Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?

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"?

Greetings,

Andres Freund

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

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

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

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.

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

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
CPUsbeing 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.

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

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

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

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.

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