Re: pglz compression performance, take two
От | Mark Dilger |
---|---|
Тема | Re: pglz compression performance, take two |
Дата | |
Msg-id | 91F7608D-4800-49B8-B5EC-911AAF1BB069@enterprisedb.com обсуждение исходный текст |
Ответ на | Re: pglz compression performance, take two (Andrey Borodin <x4mmm@yandex-team.ru>) |
Ответы |
Re: pglz compression performance, take two
|
Список | pgsql-hackers |
> On Jan 28, 2021, at 2:56 AM, Andrey Borodin <x4mmm@yandex-team.ru> wrote: > > > >> 22 янв. 2021 г., в 07:48, Justin Pryzby <pryzby@telsasoft.com> написал(а): >> >> @cfbot: rebased >> <0001-Reorganize-pglz-compression-code.patch> > > Thanks! > > I'm experimenting with TPC-C over PostgreSQL 13 on production-like cluster in the cloud. Overall performance is IO-bound,but compression is burning a lot energy too (according to perf top). Cluster consists of 3 nodes(only HA, no standbyqueries) with 32 vCPU each, 128GB RAM, sync replication, 2000 warehouses, 240GB PGDATA. > > Samples: 1M of event 'cpu-clock', 4000 Hz, Event count (approx.): 177958545079 > Overhead Shared Object Symbol > 18.36% postgres [.] pglz_compress > 3.88% [kernel] [k] _raw_spin_unlock_irqrestore > 3.39% postgres [.] hash_search_with_hash_value > 3.00% [kernel] [k] finish_task_switch > 2.03% [kernel] [k] copy_user_enhanced_fast_string > 1.14% [kernel] [k] filemap_map_pages > 1.02% postgres [.] AllocSetAlloc > 0.93% postgres [.] _bt_compare > 0.89% postgres [.] PinBuffer > 0.82% postgres [.] SearchCatCache1 > 0.79% postgres [.] LWLockAttemptLock > 0.78% postgres [.] GetSnapshotData > > Overall cluster runs 862tps (52KtpmC, though only 26KtmpC is qualified on 2K warehouses). > > Thanks! Robert Haas just committed Dilip Kumar's LZ4 compression, bbe0a81db69bd10bd166907c3701492a29aca294. Is this pglz compression patch still relevant? How does the LZ4 compression compare on your hardware? — Mark Dilger EnterpriseDB: http://www.enterprisedb.com The Enterprise PostgreSQL Company
В списке pgsql-hackers по дате отправления: