Телеграмм чат группы pgsql страница 10311

2020 July 16

YB

так и есть - это наличие параллельной нагрузки аналогичного плана??

да. там хуже нагрузка. не сек скан по всей таблице. а аналитические запросы с сортировкой , предикатами и тд
наравне с олтп активностьью

источник

16:01пожаловаться #1

YB

Yelena Bunina in pgsql – PostgreSQL

Сергей Голод

как по мне - так всё плохо. Сравниваю со своим baremetal, где для PG выделено 10Гб памяти и 3 ядра (nvme ssd):

5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     20893.062 ops/sec      48 usecs/op
        fdatasync                         19866.136 ops/sec      50 usecs/op
        fsync                             19576.059 ops/sec      51 usecs/op
        fsync_writethrough                              n/a
        open_sync                         20798.804 ops/sec      48 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     10445.704 ops/sec      96 usecs/op
        fdatasync                         16328.302 ops/sec      61 usecs/op
        fsync                             16295.395 ops/sec      61 usecs/op
        fsync_writethrough                              n/a
        open_sync                         10022.182 ops/sec     100 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write          9088.258 ops/sec     110 usecs/op
         2 *  8kB open_sync writes         6928.302 ops/sec     144 usecs/op
         4 *  4kB open_sync writes         4704.683 ops/sec     213 usecs/op
         8 *  2kB open_sync writes         2464.638 ops/sec     406 usecs/op
        16 *  1kB open_sync writes         1348.255 ops/sec     742 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close               17379.499 ops/sec      58 usecs/op
        write, close, fsync               17518.361 ops/sec      57 usecs/op

Non-sync'ed 8kB writes:
        write                            239796.913 ops/sec       4 usecs/op

пичаль

источник

16:02пожаловаться #2

СГ

Сергей Голод... in pgsql – PostgreSQL

Yelena Bunina

да. там хуже нагрузка. не сек скан по всей таблице. а аналитические запросы с сортировкой , предикатами и тд
наравне с олтп активностьью

тогда я думаю что вам нечего удивляться длительным запросам. У вас сервер просто не расчитан на такого рода нагрузку

источник

16:02пожаловаться #3

СГ

Сергей Голод... in pgsql – PostgreSQL

Yelena Bunina

да. там хуже нагрузка. не сек скан по всей таблице. а аналитические запросы с сортировкой , предикатами и тд
наравне с олтп активностьью

Может, что-то в консерватории подправить? (c), без обид)

источник

16:03пожаловаться #4

YB

Yelena Bunina in pgsql – PostgreSQL

Сергей Голод

Может, что-то в консерватории подправить? (c), без обид)

диагноз ясен

источник

16:05пожаловаться #5

YS

Yaroslav Schekin in pgsql – PostgreSQL

Сергей Голод

как по мне - так всё плохо. Сравниваю со своим baremetal, где для PG выделено 10Гб памяти и 3 ядра (nvme ssd):

5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     20893.062 ops/sec      48 usecs/op
        fdatasync                         19866.136 ops/sec      50 usecs/op
        fsync                             19576.059 ops/sec      51 usecs/op
        fsync_writethrough                              n/a
        open_sync                         20798.804 ops/sec      48 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     10445.704 ops/sec      96 usecs/op
        fdatasync                         16328.302 ops/sec      61 usecs/op
        fsync                             16295.395 ops/sec      61 usecs/op
        fsync_writethrough                              n/a
        open_sync                         10022.182 ops/sec     100 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write          9088.258 ops/sec     110 usecs/op
         2 *  8kB open_sync writes         6928.302 ops/sec     144 usecs/op
         4 *  4kB open_sync writes         4704.683 ops/sec     213 usecs/op
         8 *  2kB open_sync writes         2464.638 ops/sec     406 usecs/op
        16 *  1kB open_sync writes         1348.255 ops/sec     742 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close               17379.499 ops/sec      58 usecs/op
        write, close, fsync               17518.361 ops/sec      57 usecs/op

Non-sync'ed 8kB writes:
        write                            239796.913 ops/sec       4 usecs/op

А что тут сделаешь, тем не менее? Такое вот облако, получается (хотя да, у меня даже на "так себе" local PC показатели как минимум вдвое лучше, чем у них). ;)
Но там, к тому же, есть и другая существенная нагрузка, я так понял...

источник

16:06пожаловаться #6

YS

Yaroslav Schekin in pgsql – PostgreSQL

Yelena Bunina

диагноз ясен

Нет, ну в самом деле... Что это за "сервер" такой, с производительностью современного смартфона? ;)
Но если отвлечься от этого (если "железо" сменить не получится), всё равно Вам стоит найти, куда уходят все эти часы.

источник

16:08пожаловаться #7

СГ

Сергей Голод... in pgsql – PostgreSQL

Yaroslav Schekin

А что тут сделаешь, тем не менее? Такое вот облако, получается (хотя да, у меня даже на "так себе" local PC показатели как минимум вдвое лучше, чем у них). ;)
Но там, к тому же, есть и другая существенная нагрузка, я так понял...

как вариант - полностью запретить аналитические отчёты и перенести их на реплику. На этом сервере только OLTP. Если не поможет - уходить с облака на железо, где поднимать ПГ

источник

16:08пожаловаться #8

YB

Yelena Bunina in pgsql – PostgreSQL

Сергей Голод

как по мне - так всё плохо. Сравниваю со своим baremetal, где для PG выделено 10Гб памяти и 3 ядра (nvme ssd):

5 seconds per test
O_DIRECT supported on this platform for open_datasync and open_sync.

Compare file sync methods using one 8kB write:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     20893.062 ops/sec      48 usecs/op
        fdatasync                         19866.136 ops/sec      50 usecs/op
        fsync                             19576.059 ops/sec      51 usecs/op
        fsync_writethrough                              n/a
        open_sync                         20798.804 ops/sec      48 usecs/op

Compare file sync methods using two 8kB writes:
(in wal_sync_method preference order, except fdatasync is Linux's default)
        open_datasync                     10445.704 ops/sec      96 usecs/op
        fdatasync                         16328.302 ops/sec      61 usecs/op
        fsync                             16295.395 ops/sec      61 usecs/op
        fsync_writethrough                              n/a
        open_sync                         10022.182 ops/sec     100 usecs/op

Compare open_sync with different write sizes:
(This is designed to compare the cost of writing 16kB in different write
open_sync sizes.)
         1 * 16kB open_sync write          9088.258 ops/sec     110 usecs/op
         2 *  8kB open_sync writes         6928.302 ops/sec     144 usecs/op
         4 *  4kB open_sync writes         4704.683 ops/sec     213 usecs/op
         8 *  2kB open_sync writes         2464.638 ops/sec     406 usecs/op
        16 *  1kB open_sync writes         1348.255 ops/sec     742 usecs/op

Test if fsync on non-write file descriptor is honored:
(If the times are similar, fsync() can sync data written on a different
descriptor.)
        write, fsync, close               17379.499 ops/sec      58 usecs/op
        write, close, fsync               17518.361 ops/sec      57 usecs/op

Non-sync'ed 8kB writes:
        write                            239796.913 ops/sec       4 usecs/op

а нагрузка по iops у вас такая же?

источник

16:09пожаловаться #9

СГ

Сергей Голод... in pgsql – PostgreSQL

Yelena Bunina

а нагрузка по iops у вас такая же?

у меня iops так не мониторятся, поэтому тут я ничего не скажу

источник

16:09пожаловаться #10

СГ

Сергей Голод... in pgsql – PostgreSQL

Yelena Bunina

а нагрузка по iops у вас такая же?

но у меня там достаточно шустрые nvme enterprise, поэтому думаю что диски в моём случае совершенно не являются узким местом. По fio я там получал намного выше 100к

источник

16:10пожаловаться #11

A

Alexander in pgsql – PostgreSQL

Yaroslav Schekin

А что тут сделаешь, тем не менее? Такое вот облако, получается (хотя да, у меня даже на "так себе" local PC показатели как минимум вдвое лучше, чем у них). ;)
Но там, к тому же, есть и другая существенная нагрузка, я так понял...

Это всё не отвечает на вопрос, почему explain analyze в два+ раза быстрее, но, да, я бы переполз на реальное железо.

источник

16:11пожаловаться #12

YS

Yaroslav Schekin in pgsql – PostgreSQL

Alexander

Это всё не отвечает на вопрос, почему explain analyze в два+ раза быстрее, но, да, я бы переполз на реальное железо.

Потому что EXPLAIN ANALYZE никакой записи и преобразований не выполняет, это как минимум (это всё может съедать очень существенное время). Вот, к примеру, когда-то Andrew Gierth занялся реализацией нового алгоритма преобразования float -> text после того, когда ему "в прямом эфире" показали, что аналог "copy to" из MS SQL для таблицы, состоящей в основном из полей такого типа, делает это примерно в четыре раза быстрее. ;)
И тут тоже что-то подобное может быть (binary format, кстати — это тоже преобразование, не просто вывод "как есть"), кто его знает (хотя любопытно бы было посмотреть на настоящем железе, да)...

источник

16:20пожаловаться #13

A

Alexander in pgsql – PostgreSQL

Yaroslav Schekin

Потому что EXPLAIN ANALYZE никакой записи и преобразований не выполняет, это как минимум (это всё может съедать очень существенное время). Вот, к примеру, когда-то Andrew Gierth занялся реализацией нового алгоритма преобразования float -> text после того, когда ему "в прямом эфире" показали, что аналог "copy to" из MS SQL для таблицы, состоящей в основном из полей такого типа, делает это примерно в четыре раза быстрее. ;)
И тут тоже что-то подобное может быть (binary format, кстати — это тоже преобразование, не просто вывод "как есть"), кто его знает (хотя любопытно бы было посмотреть на настоящем железе, да)...

ну тут to /dev/null и binary(т.е. без преобразования, или я не правильно понимаю)?

источник

16:22пожаловаться #14

A

Alko in pgsql – PostgreSQL

Всем привет!
У меня глупый вопрос... как быстро удалить данные из таблицы? сейчас там 40млн записей. DELETE FROM "table" - делает очень долго, и удаляет медленно. Сейчас делаю DELETE FROM "table" where id > 1000000 and id < 2000000 (и так далее) таким образом удаляет миллион записей где то за 2 часа.

источник

16:25пожаловаться #15

A

Alexander in pgsql – PostgreSQL

truncate table

источник

16:25пожаловаться #16

A

Alko in pgsql – PostgreSQL

Alexander

truncate table

там есть связи... может можно удалить первичный ключ, сделать truncate а потом добавить ничего не сломав?

источник

16:26пожаловаться #17

A

Alexander in pgsql – PostgreSQL

или партицировать и дропать партиции.

источник

16:26пожаловаться #18

YB

Yelena Bunina in pgsql – PostgreSQL

Сергей Голод

как вариант - полностью запретить аналитические отчёты и перенести их на реплику. На этом сервере только OLTP. Если не поможет - уходить с облака на железо, где поднимать ПГ

с репликой другие проблемы , там аналитические запросы будут канселиться
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed.
и там другая история с настройкой репликации. мы ее не осилили сделать рабочей. так чтобы на мастере работала вся олтп нагрузка а реплика не отставала изза долгих и многих аналитических запросов. там тоже вариант - либо копить вал логи на мастере и забивать диск , либо давать реплике отставать и потом ее восстанавливать заново, что тоже не быстро происходит

источник

16:26пожаловаться #19

VY

Victor Yegorov in pgsql – PostgreSQL

Yelena Bunina

с репликой другие проблемы , там аналитические запросы будут канселиться
ERROR: canceling statement due to conflict with recovery
Detail: User query might have needed to see row versions that must be removed.
и там другая история с настройкой репликации. мы ее не осилили сделать рабочей. так чтобы на мастере работала вся олтп нагрузка а реплика не отставала изза долгих и многих аналитических запросов. там тоже вариант - либо копить вал логи на мастере и забивать диск , либо давать реплике отставать и потом ее восстанавливать заново, что тоже не быстро происходит

хм, зачем заново? если ей позволено отставать на, скажем, 6 часов, то WAL-ы всё время текут, просто не применяются.

источник

16:27пожаловаться #20