Re: WAL prefetch - Mailing list pgsql-hackers

From Tomas Vondra
Subject Re: WAL prefetch
Date
Msg-id b3b5ce12-73bb-cf2e-9107-3a4f7983cd5b@2ndquadrant.com
Whole thread Raw
In response to Re: WAL prefetch  (Konstantin Knizhnik <k.knizhnik@postgrespro.ru>)
Responses Re: WAL prefetch
List pgsql-hackers

On 06/21/2018 04:01 PM, Konstantin Knizhnik wrote:
> I continue my experiments with WAL prefetch.
> I have embedded prefetch in Postgres: now walprefetcher is started 
> together with startup process and is able to help it to speedup recovery.
> The patch is attached.
> 
> Unfortunately result is negative (at least at my desktop: SSD, 16Gb 
> RAM). Recovery with prefetch is 3 times slower than without it.
> What I am doing:
> 
> Configuration:
>      max_wal_size=min_wal_size=10Gb,
>      shared)buffers = 1Gb
> Database:
>       pgbench -i -s 1000
> Test:
>       pgbench -c 10 -M prepared -N -T 100 -P 1
>       pkill postgres
>       echo 3 > /proc/sys/vm/drop_caches
>       time pg_ctl -t 1000 -D pgsql -l logfile start
> 
> Without prefetch it is 19 seconds (recovered about 4Gb of WAL), with 
> prefetch it is about one minute. About 400k blocks are prefetched.
> CPU usage is small (<20%), both processes as in "Ds" state.
> 

Based on a quick test, my guess is that the patch is broken in several 
ways. Firstly, with the patch attached (and wal_prefetch_enabled=on, 
which I think is needed to enable the prefetch) I can't even restart the 
server, because pg_ctl restart just hangs (the walprefetcher process 
gets stuck in WaitForWAL, IIRC).

I have added an elog(LOG,...) to walprefetcher.c, right before the 
FilePrefetch call, and (a) I don't see any actual prefetch calls during 
recovery but (b) I do see the prefetch happening during the pgbench. 
That seems a bit ... wrong?

Furthermore, you've added an extra

     signal_child(BgWriterPID, SIGHUP);

to SIGHUP_handler, which seems like a bug too. I don't have time to 
investigate/debug this further.

regards

-- 
Tomas Vondra                  http://www.2ndQuadrant.com
PostgreSQL Development, 24x7 Support, Remote DBA, Training & Services


pgsql-hackers by date:

Previous
From: Heikki Linnakangas
Date:
Subject: Re: Considering signal handling in plpython again
Next
From: Andrew Dunstan
Date:
Subject: Re: Fast default stuff versus pg_upgrade