Pull to refresh
38
0
Васильев Дмитрий @vadv

User

Send message

Эпизодический запуск pg_repack, даже раз в неделю, будет проносить профит: он сделает индексы компактнее и быстрее. Принесет ли профит кластеризация по индексу конкретно вам я не могу сказать, так как все зависит от ваших запросов.
Другого использования pg_repack не предусмотренно

alexeiivanov


И в том и в другом случае включен FPW (full page write), но средний размер записи в wal у bigserial меньше.
А происходит это потому что FPW записывается только после первой модификации страницы.
В случае с UUID — переиспользование буферов в буферном пуле маленькое и там мы пачкаем "новые" страницы чаще и чаще вызываем FPW.


Так что я оказался прав, запись WAL связана с вытеснением страниц из буфера, прав но отчасти :)


UUID:
rmgr: Heap        len (rec/tot):     54/  1378, tx: 2255313124, lsn: 2E5/1A036540, prev 2E5/1A036500, desc: INSERT off 25 flags 0x00, blkref #0: rel 1663/14010/24831 blk 703953 FPW
rmgr: Btree       len (rec/tot):     53/  8157, tx: 2255313124, lsn: 2E5/1A036AA8, prev 2E5/1A036540, desc: INSERT_LEAF off 8, blkref #0: rel 1663/14010/24832 blk 287891 FPW

bigserial:
rmgr: Heap        len (rec/tot):     71/    71, tx: 2255587536, lsn: 2E5/33FFFAC0, prev 2E5/33FFFA98, desc: INSERT off 41 flags 0x00, blkref #0: rel 1663/14010/24838 blk 24892
rmgr: Btree       len (rec/tot):     64/    64, tx: 2255587536, lsn: 2E5/33FFFB08, prev 2E5/33FFFAC0, desc: INSERT_LEAF off 83, blkref #0: rel 1663/14010/24843 blk 12623

в случае с bigserial:


pg_waldump pg_wal/00000001000002E4000000E9 | awk '{print $14}' | sort | uniq -c
  92288 COMMIT
  91804 INSERT
    489 INSERT+INIT
  92042 INSERT_LEAF
    252 INSERT_UPPER
   2797 LOG
    253 SPLIT_R
      3 ZEROPAGE

в случае с UUID v4


pg_waldump pg_wal/00000001000002E4000000B8 | awk '{print $14}' | sort | uniq -c
   2723 COMMIT
      5 DEDUP
   2703 INSERT
     18 INSERT+INIT
   5423 INSERT_LEAF
     18 INSERT_UPPER
      7 SPLIT_L
     11 SPLIT_R
сброс буферов на диск через WAL не проходит

хм, вы правы, а тут я не прав, каюсь :)
запустил тест еще раз и после этого натравлю pg_waldump

поиск по uuid, подозреваю, тоже ускорится. vadv, не хотите проверить?
наверное зависит от запросов, а подскажите что именно проверить?

привет alexeiivanov !


  1. тестирование проводилось на 8GB Ram, shared_buffers 2GB, max_clients 100, 4 CPU, 7k IOPS:
    number of clients: 20
    number of threads: 2
    duration: 21600 s
  2. генерируется много WAL потому что запросам (бакендам) приходилось вытеснять грязные страницы на диск, так как не хватало место в shared_buffers

PostgreSQL проверяет области видимости и ему приходится таскать страницы из истории в случае с неравномерным индексом, поэтому хотелось показать насколько это важно — индекс по равномерным данным. Если вы историю будете хранить на медленном IO с неравномерным индексом — это вас погубит.

Речь о том как сделать так, что бы вычитка большого числа строк из таблицы работала ещё быстрее, при использовании индекса по полю с условно рандомным значением.

ну не совсем так, речь про эффективный кэш, стабильный buffer pool в котором лежат стабильные части "горячих" данных — последний день, месяц.

В других СУБД есть возможность Clustered indexes (MSSQL, MySQL, Oracle) со своими особенностями. В PostgreSQL такой важной возможности нет, есть CLUSTER и сторонний pg_repack, с чем живем то и обслуживаем.

Вы правы, я намерено выбрал самый неудачный для моего случая UUID v4. Согласен, что лучше использовать стандартные решения, или прокачивать их.
Но задача была не перепробовать все UUID, а показать насколько может тормозить индекс и почему. Дать повод разработчикам задуматься о том что недостаточно просто построить индекс, надо понимать как он будет работать и как его обслуживать в дальнейшем. Поэтому для примера добавил известные решения, что бы дать волю экспериментам :)

Спасибо, Григорий! Опечатку в тексте исправил, речь конечно была про row-level локи

Select вызывает запись при обновлении страниц после hot-update

select всегда вызывает запись (переписывает страницы при full_page_write) если находит закомиченные в clog, но не помеченные как закомиченные данные в data.

мощная индексация по json

Стоит обратить внимание, что по json просто нельзя собрать статистику.
А база, планер которой работает по весовой схеме, просто не может нормально работать без статистики.


Но надеюсь скоро исправят, здесь smagen писал: http://akorotkov.github.io/blog/2015/09/07/jsonb_statistics/ для 10-ки точно еще актуально.

ну как откуда, в control-файле же информация про два checkpoint'а

потестили как быстро pg открывает коннект, поздравляю

dell precision 5510 — меняли бесплатно батарею с такой же проблемой (в гарантийный срок) в http://screspect.ru/

Николай, спасибо за статью!
Как можно решить с помощью envoy можно проблему пинания 504 от апстрима к апстриму?

ни колонок переменной длины, а содержит в основном значения типов integer и timestamp.

дело в движке:


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

обслуживание

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

Очень доступно и круто!

1
23 ...

Information

Rating
Does not participate
Location
Россия
Works in
Date of birth
Registered
Activity