Re: High SYS CPU - need advise - Mailing list pgsql-general

From Jeff Janes
Subject Re: High SYS CPU - need advise
Date
Msg-id CAMkU=1w3fq_oEDPGd17BEK2bKFvsG3+TuEB7Vb7Gc8ikmK9ipA@mail.gmail.com
Whole thread Raw
In response to Re: High SYS CPU - need advise  (Merlin Moncure <mmoncure@gmail.com>)
Responses Re: High SYS CPU - need advise  (Merlin Moncure <mmoncure@gmail.com>)
List pgsql-general
On Thu, Nov 15, 2012 at 2:44 PM, Merlin Moncure <mmoncure@gmail.com> wrote:

>>> select(0, NULL, NULL, NULL, {0, 1000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 1000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 1000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 2000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 3000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 4000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 6000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 7000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 8000})  = 0 (Timeout)
>>> select(0, NULL, NULL, NULL, {0, 9000})  = 0 (Timeout)

This is not entirely inconsistent with the spinlock.  Note that 1000
is repeated 3 times, and 5000 is missing.

This might just be a misleading random sample we got here.  I've seen
similar close spacing in some simulations I've run.

It is not clear to me why we use a resolution of 1 msec here.  If the
OS's implementation of select() eventually rounds to the nearest msec,
that is its business.  But why do we have to lose intermediate
precision due to its decision?

Cheers,

Jeff


pgsql-general by date:

Previous
From: Vlad Marchenko
Date:
Subject: Re: High SYS CPU - need advise
Next
From: "P. Broennimann"
Date:
Subject: Purge Logs from pgagent