Re: Compression of full-page-writes - Mailing list pgsql-hackers

From Haribabu kommi
Subject Re: Compression of full-page-writes
Date
Msg-id 8977CB36860C5843884E0A18D8747B0372BC7888@szxeml558-mbs.china.huawei.com
Whole thread Raw
In response to Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
Responses Re: Compression of full-page-writes  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
List pgsql-hackers
On 05 October 2013 17:12 Amit Kapila wrote:
>On Fri, Oct 4, 2013 at 10:49 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>> On Mon, Sep 30, 2013 at 1:55 PM, Amit Kapila <amit.kapila16@gmail.com> wrote:
>>> On Mon, Sep 30, 2013 at 10:04 AM, Fujii Masao <masao.fujii@gmail.com> wrote:
>>>> On Mon, Sep 30, 2013 at 1:27 PM, KONDO Mitsumasa
>>>> <kondo.mitsumasa@lab.ntt.co.jp> wrote:
>>>>> Hi Fujii-san,
>>>>>
>>>>>
>>>>> (2013/09/30 12:49), Fujii Masao wrote:
>>>>>> On second thought, the patch could compress WAL very much because
>>>>>> I used pgbench.
>>>>>>
>>>>>> I will do the same measurement by using another benchmark.
>>>>>
>>>>> If you hope, I can test this patch in DBT-2 benchmark in end of this week.
>>>>> I will use under following test server.
>>>>>
>>>>> * Test server
>>>>>   Server: HP Proliant DL360 G7
>>>>>   CPU:    Xeon E5640 2.66GHz (1P/4C)
>>>>>   Memory: 18GB(PC3-10600R-9)
>>>>>   Disk:   146GB(15k)*4 RAID1+0
>>>>>   RAID controller: P410i/256MB
>>>>
>>>> Yep, please! It's really helpful!
>>>
>>> I think it will be useful if you can get the data for 1 and 2 threads
>>> (may be with pgbench itself) as well, because the WAL reduction is
>>> almost sure, but the only thing is that it should not dip tps in some
>>> of the scenarios.
>>
>> Here is the measurement result of pgbench with 1 thread.
>>
>> scaling factor: 100
>> query mode: prepared
>> number of clients: 1
>> number of threads: 1
>> duration: 900 s
>>
>> WAL Volume
>> - 1344 MB (full_page_writes = on)
>> -   349 MB (compress)
>> -     78 MB (off)
>>
>> TPS
>> 117.369221 (on)
>> 143.908024 (compress)
>> 163.722063 (off)

>This data is good.
>I will check if with the help of my old colleagues, I can get the performance data on m/c where we have tried similar
idea.

                        Thread-1                    Threads-2
                Head code        FPW compress    Head code        FPW compress
Pgbench-org 5min        1011(0.96GB)    815(0.20GB)        2083(1.24GB)    1843(0.40GB)
Pgbench-1000 5min        958(1.16GB)        778(0.24GB)        1937(2.80GB)    1659(0.73GB)
Pgbench-org 15min        1065(1.43GB)    983(0.56GB)        2094(1.93GB)    2025(1.09GB)
Pgbench-1000 15min    1020(3.70GB)    898(1.05GB)        1383(5.31GB)    1908(2.49GB)

Pgbench-org - original pgbench
Pgbench-1000 - changed pgbench with a record size of 1000.
5 min - pgbench test carried out for 5 min.
15 min - pgbench test carried out for 15 min.

The checkpoint_timeout and checkpoint_segments are increased to make sure no checkpoint happens during the test run.

>From the above readings it is observed that,
1. There a performance dip in one or two threads test, the amount of dip reduces with the test run time.
2. For two threads pgbench-1000 record size test, the fpw compress performance is good in 15min run.
3. More than 50% WAL reduction in all scenarios.

All these readings are measured with pgbench query mode as simple.
Please find the attached sheet for more details regarding machine and test configuration.


Regards,
Hari babu.



Attachment

pgsql-hackers by date:

Previous
From: Atri Sharma
Date:
Subject: Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Next
From: Sawada Masahiko
Date:
Subject: Re: Patch for fail-back without fresh backup