Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Tue, Feb 16, 2016 at 7:10 AM, Tom Lane 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Tue, Feb 16, 2016 at 12:06 AM, Robert Haas wrote: > On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund 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 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.1; 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
Robert Haas writes: > On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Tue, Feb 16, 2016 at 3:50 AM, Andres Freund 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On February 16, 2016 9:06:57 AM GMT+01:00, Robert Haas wrote: >On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund >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 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Wed, Feb 10, 2016 at 5:15 PM, Andres Freund 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 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Wed, Feb 10, 2016 at 4:15 PM, Andres Freund 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 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Mon, Feb 15, 2016 at 11:23 AM, Peter Geoghegan 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
Re: [HACKERS] Remove or weaken hints about "effective resolution of sleep delays is 10 ms"?
On Wed, Feb 10, 2016 at 2:15 PM, Andres Freund 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
[HACKERS] 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 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 -- Sent via pgsql-hackers mailing list (pgsql-hackers@postgresql.org) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-hackers