[WIP PATCH] for Performance Improvement in Buffer Management

From: Amit kapila <amit(dot)kapila(at)huawei(dot)com>
To: "pgsql-hackers(at)postgresql(dot)org" <pgsql-hackers(at)postgresql(dot)org>
Subject: [WIP PATCH] for Performance Improvement in Buffer Management
Date: 2012-09-03 14:15:05
Message-ID: 6C0B27F7206C9E4CA54AE035729E9C382852FF97@szxeml509-mbs
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-hackers

This patch is based on below Todo Item:

Consider adding buffers the background writer finds reusable to the free list

I have tried implementing it and taken the readings for Select when all the data is in either OS buffers

or Shared Buffers.

The Patch has simple implementation for "bgwriter or checkpoint process moving the unused buffers (unpinned with "ZERO" usage_count buffers) into "freelist".

Results (Results.html attached with mail) are taken with following configuration.

Current scenario is
1. Load all the files in to OS buffers (using pg_prewarm with 'read' operation) of all
tables and indexes.
2. Try to load all buffers with "pgbench_accounts" table and "pgbench_accounts_pkey"
pages (using pg_prewarm with 'buffers' operation).
3. Run the pgbench with select only for 20 minutes.

Platform details:
Operating System: Suse-Linux 10.2 x86_64
Hardware : 4 core (Intel(R) Xeon(R) CPU L5408 @ 2.13GHz)
RAM : 24GB

Server Configuration:
shared_buffers = 6GB (1/4 th of RAM size)

Pgbench configuration:
transaction type: SELECT only
scaling factor: 1200
query mode: simple
number of clients: <varying from 8 to 64 >
number of threads: <varying from 8 to 64 >
duration: 1200 s

Comments or suggestions?

I am still collecting data for update and other operations performance results with different database configuration.

With Regards,

Amit Kapila.

Attachment Content-Type Size
bgwritter_or_checkpoint_proc_moving_buf_to_freelist.patch text/plain 1.1 KB
RESULTS.html text/html 28.7 KB

Responses

Browse pgsql-hackers by date

  From Date Subject
Next Message Bruce Momjian 2012-09-03 14:20:07 Caught up
Previous Message Tom Lane 2012-09-03 14:07:43 Re: Yet another failure mode in pg_upgrade