From: | Jim Nasby <jim(dot)nasby(at)gmail(dot)com> |
---|---|
To: | Bharath Rupireddy <bharath(dot)rupireddyforpostgres(at)gmail(dot)com>, Tom Lane <tgl(at)sss(dot)pgh(dot)pa(dot)us> |
Cc: | Michael Paquier <michael(at)paquier(dot)xyz>, 1111hqshj(at)sina(dot)com, pgsql-hackers <pgsql-hackers(at)lists(dot)postgresql(dot)org> |
Subject: | Re: Make NUM_XLOGINSERT_LOCKS configurable |
Date: | 2024-01-12 22:09:19 |
Message-ID: | 5ce30017-1d82-4a4f-8678-ce936a154e73@gmail.com |
Views: | Raw Message | Whole Thread | Download mbox | Resend email |
Thread: | |
Lists: | pgsql-hackers |
On 1/12/24 12:32 AM, Bharath Rupireddy wrote:
> Test case:
> ./pgbench --initialize --scale=100 --username=ubuntu postgres
> ./pgbench --progress=10 --client=64 --time=300 --builtin=tpcb-like
> --username=ubuntu postgres
>
> Setup:
> ./configure --prefix=$PWD/inst/ CFLAGS="-ggdb3 -O3" > install.log &&
> make -j 8 install > install.log 2>&1 &
>
> shared_buffers = '8GB'
> max_wal_size = '32GB'
> track_wal_io_timing = on
>
> Stats measured:
> I've used the attached patch to measure WAL Insert Lock Acquire Time
> (wal_insert_lock_acquire_time) and WAL Wait for In-progress Inserts
> to Finish Time (wal_wait_for_insert_to_finish_time).
Unfortunately this leaves the question of how frequently is
WaitXLogInsertionsToFinish() being called and by whom. One possibility
here is that wal_buffers is too small so backends are constantly having
to write WAL data to free up buffers.
--
Jim Nasby, Data Architect, Austin TX
From | Date | Subject | |
---|---|---|---|
Next Message | Cary Huang | 2024-01-12 22:14:38 | Re: [DOC] Add detail regarding resource consumption wrt max_connections |
Previous Message | Tom Lane | 2024-01-12 21:25:53 | Re: plpgsql memory leaks |