Re: Compression of full-page-writes

Поиск
Список
Период
Сортировка
От Haribabu kommi
Тема Re: Compression of full-page-writes
Дата
Msg-id 8977CB36860C5843884E0A18D8747B0372BC7888@szxeml558-mbs.china.huawei.com
обсуждение исходный текст
Ответ на Re: Compression of full-page-writes  (Amit Kapila <amit.kapila16@gmail.com>)
Ответы Re: Compression of full-page-writes  (KONDO Mitsumasa <kondo.mitsumasa@lab.ntt.co.jp>)
Список 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.



Вложения

В списке pgsql-hackers по дате отправления:

Предыдущее
От: Atri Sharma
Дата:
Сообщение: Re: Re: custom hash-based COUNT(DISTINCT) aggregate - unexpectedly high memory consumption
Следующее
От: Sawada Masahiko
Дата:
Сообщение: Re: Patch for fail-back without fresh backup