YS
Ярослав, пациент сделал существенное дополнение: в момент чтения таблица активно насилуется записью и, соответственно, автовакуумом.
От этого, по идее, только легче ("изнасилованные" блоки уже, как минимум, в FS cache), а не тяжелее. ;)
Size: a a a
2020 July 16
YB
а конфигурация сервера ПГ какая? память, диски.
12 vCPUs, 52 GB memory, диск 1TB SSD
YB
Yaroslav Schekin
Значит, выбросите в мусорную корзину те дискеты 3.5, на которых у Вас работает PostgreSQL, хватит над ним издеваться!
Вы в самом деле считаете, что чтение с любых современных дисков 189 GB за пять часов — это нормально?!
Вы в самом деле считаете, что чтение с любых современных дисков 189 GB за пять часов — это нормально?!
это клауд
s
это клауд
А iops нигде в параметрах тарифа не ограничены?
YS
это клауд
Если это в самом деле так (т.е. это throttling) — ну разве это не прекрасно (т.е. получается не SSD, а одно название)? ;(
Т.е. по уровню производительности на самом деле — как вышеупомянутые дискеты.
Т.е. по уровню производительности на самом деле — как вышеупомянутые дискеты.
YB
Yaroslav Schekin
Если это в самом деле так (т.е. это throttling) — ну разве это не прекрасно (т.е. получается не SSD, а одно название)? ;(
Т.е. по уровню производительности на самом деле — как вышеупомянутые дискеты.
Т.е. по уровню производительности на самом деле — как вышеупомянутые дискеты.
а почему? как проверить что не ссд?
СГ
а почему? как проверить что не ссд?
а шелл доступен? pgbench можно напустить на СУБД?
YS
а почему? как проверить что не ссд?
Это может быть только throttling, по идее. Т.е. https://t.me/pgsql/238364
YB
А iops нигде в параметрах тарифа не ограничены?
чтение и запись 15000
throughoutput 480Mb/s
throughoutput 480Mb/s
YB
а шелл доступен? pgbench можно напустить на СУБД?
есть. что посмотреть?
YS
чтение и запись 15000
throughoutput 480Mb/s
throughoutput 480Mb/s
Ну так у меня получается, что это должно занимать где-то 7 минут, в таком случае:
> SELECT ((189*1024.0) / 480 / 60)
6.72
YB
QUERY PLAN
Seq Scan on tbl_order o (cost=0.00..24413241.04 rows=78733104 width=53) (actual time=0.043..897201.486 rows=77755112 loops=1)
Buffers: shared hit=1557053 read=22068857 dirtied=240608 written=128365
I/O Timings: read=777774.409 write=2718.135
Planning Time: 0.078 ms
Execution Time: 903871.974 ms
Seq Scan on tbl_order o (cost=0.00..24413241.04 rows=78733104 width=53) (actual time=0.043..897201.486 rows=77755112 loops=1)
Buffers: shared hit=1557053 read=22068857 dirtied=240608 written=128365
I/O Timings: read=777774.409 write=2718.135
Planning Time: 0.078 ms
Execution Time: 903871.974 ms
YB
explain (ANALYZE,BUFFERS) SELECT
o.platform,
o.platform_order_id,
o.platform_created_at,
o.extended_money_status,
o.money_status,
extended_delivery_status,
delivery_status,
synced_at
FROM
public.tbl_order o
o.platform,
o.platform_order_id,
o.platform_created_at,
o.extended_money_status,
o.money_status,
extended_delivery_status,
delivery_status,
synced_at
FROM
public.tbl_order o
YS
QUERY PLAN
Seq Scan on tbl_order o (cost=0.00..24413241.04 rows=78733104 width=53) (actual time=0.043..897201.486 rows=77755112 loops=1)
Buffers: shared hit=1557053 read=22068857 dirtied=240608 written=128365
I/O Timings: read=777774.409 write=2718.135
Planning Time: 0.078 ms
Execution Time: 903871.974 ms
Seq Scan on tbl_order o (cost=0.00..24413241.04 rows=78733104 width=53) (actual time=0.043..897201.486 rows=77755112 loops=1)
Buffers: shared hit=1557053 read=22068857 dirtied=240608 written=128365
I/O Timings: read=777774.409 write=2718.135
Planning Time: 0.078 ms
Execution Time: 903871.974 ms
Тем не менее, это 15 минут, а не 5 часов (т.е., по крайней мере, похоже на то, что должно быть).
YB
Yaroslav Schekin
Тем не менее, это 15 минут, а не 5 часов (т.е., по крайней мере, похоже на то, что должно быть).
да. ошиблась
СГ
есть. что посмотреть?
провести тестирование через pgbench:
https://postgrespro.ru/docs/postgrespro/12/pgbench
например сделать -s 1000 и клиентов 16/16
ну и проверить сколько ваш клауд выдаёт на запись:
https://postgrespro.ru/docs/postgrespro/12/pgbench
например сделать -s 1000 и клиентов 16/16
ну и проверить сколько ваш клауд выдаёт на запись:
pg_test_fsync
YB
провести тестирование через pgbench:
https://postgrespro.ru/docs/postgrespro/12/pgbench
например сделать -s 1000 и клиентов 16/16
ну и проверить сколько ваш клауд выдаёт на запись:
https://postgrespro.ru/docs/postgrespro/12/pgbench
например сделать -s 1000 и клиентов 16/16
ну и проверить сколько ваш клауд выдаёт на запись:
pg_test_fsyncспасибо
YB
копи отдельно так же долго идет. то есть если просто в psql вызвать. без передачи в BQ. я вчера просто стопнула процесс спустя 4 часа
YS
да. ошиблась
Т.е. получается, что этот ETL будет как минимум (если не считать разницу между расчётным и фактическим временем) занимать такое время. Т.е. с чтением всё более/менее.
Я вот поэтому и писал — по шагам нужно разбираться, искать bottleneck. Т.е. COPY в /dev/null примерно даст Вам время чтения+преобразования. Ну и так далее.
Я вот поэтому и писал — по шагам нужно разбираться, искать bottleneck. Т.е. COPY в /dev/null примерно даст Вам время чтения+преобразования. Ну и так далее.
s
копи отдельно так же долго идет. то есть если просто в psql вызвать. без передачи в BQ. я вчера просто стопнула процесс спустя 4 часа
Copy куда делается? Рядом на тот же диск в облаке?