Re: Reducing power consumption on idle servers

From: Kyotaro Horiguchi <horikyota(dot)ntt(at)gmail(dot)com>
To: andres(at)anarazel(dot)de
Cc: simon(dot)riggs(at)enterprisedb(dot)com, zhengli10(at)gmail(dot)com, nasbyj(at)amazon(dot)com, thomas(dot)munro(at)gmail(dot)com, tgl(at)sss(dot)pgh(dot)pa(dot)us, pgsql-hackers(at)postgresql(dot)org
Subject: Re: Reducing power consumption on idle servers
Date: 2022-03-24 07:16:43
Message-ID: 20220324.161643.1806962492940958215.horikyota.ntt@gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

At Thu, 10 Mar 2022 11:45:10 -0800, Andres Freund <andres(at)anarazel(dot)de> wrote in
> Hi,
>
> On 2022-03-10 17:50:47 +0000, Simon Riggs wrote:
> > On Wed, 9 Mar 2022 at 01:16, Zheng Li <zhengli10(at)gmail(dot)com> wrote:
> >
> > > > 1. Standardize the hibernation time at 60s, using a #define
> > > > HIBERNATE_DELAY_SEC 60
> > >
> > > I notice in patch 3 HIBERNATE_DELAY_SEC has been increased to 300
> > > seconds, what’s the reasoning behind it? Is longer hibernation delay
> > > better? If so can we set it to INT_MAX (the max timeout allowed by
> > > WaitLatch()) in which case a worker in hibernation only relies on
> > > wakeup? I think it would be nice to run experiments to verify that the
> > > patch reduces power consumption while varying the value of
> > > HIBERNATE_DELAY_SEC.
> >
> > Setting it to INT_MAX would be the same as not allowing a timeout,
> > which changes a lot of current behavior and makes it less robust.
>
> Most of these timeouts are a bad idea and should not exist. We repeatedly have
> had bugs where we were missing wakeups etc but those bugs were harder to

I basically agree to this.

> notice because of timeouts. I'm against entrenching this stuff further.

For example, pgarch.c theoretically doesn't need hibernate, since it
has an apparent trigger event and a terminal condition. What we need
to do about archiver is to set timeout only when it didn't reach the
lastest finished segment at an iteration. (this might need additional
shared memory use, though..)

I'm not sure about bgwriter, walwriter and logical replication stuff...

About walreciver,

- if ((now - startTime) > WALRCV_STARTUP_TIMEOUT)
+ if ((now - startTime) > wal_receiver_timeout)

This is simply a misuse of the timeout. WALRCV_STARTP_TIMEOUT is not
used for a sleep and irrelevant to receiving data from the peer
walsender. wal_receiver_timeout's default is 60s but we don't assume
that walreceiver takes that long time to start up. (I think Thomas is
wroking on the walreceiver timeout stuff.)

regards.

--
Kyotaro Horiguchi
NTT Open Source Software Center

In response to

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Jian Guo 2022-03-24 07:50:11 Re: Summary Sort workers Stats in EXPLAIN ANALYZE
Previous Message Andrey V. Lepikhov 2022-03-24 06:43:37 Re: Fast COPY FROM based on batch insert