|
|
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Приветствую, Решили перевести проект на PostgreSQL но столкнулись с рандомными задержками, к примеру таблица outputs Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. При первом запросе без кеша занимает около 12мс: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. В таблице около 35M записей, прогнозируем рост до 100М Так же очень долгий insert bulk записей, к примеру запрос INSERT INTO "outputs" ("trx_id", "addresses", "position", "amount") VALUES (15341844, '{813298}', 0, 4999500000), (15341844, '{11407753}', 1, 1001313) returning id; может занимать до 20ms, но в большинстве случаев исполняется за 0.5-1ms vacuum\analyze делали. Сервер 32GB RAM, конфиг: synchronous_commit = off - временно отключили его что бы оптимизировать импорт effective_cache_size = 23040MB work_mem = 78643kB maintenance_work_mem = 1920MB checkpoint_segments = 32 checkpoint_completion_target = 0.7 wal_buffers = 16MB default_statistics_target = 100 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 15:47 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessТак же очень долгий insert bulk записей, к примеру запрос INSERT INTO "outputs" ("trx_id", "addresses", "position", "amount") VALUES (15341844, '{813298}', 0, 4999500000), (15341844, '{11407753}', 1, 1001313) returning id; может занимать до 20ms , но в большинстве случаев исполняется за 0.5-1ms 20 ms -- это же нормально, чего жалуешься? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 15:56 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
MasterZiv20 ms -- это же нормально, чего жалуешься? около 80% всех инсертов укладываются меньше чем в 1ms. Для нас это критично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 16:00 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
nateless, 10-20ms - порядок времени задержки обращения к диску так что это нормальное поведение. Надо гарантированно быстрее - используйте SSD, а них задержки на пару порядков ниже будут. PS: а сколько у вас shared_buffers? -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 16:38 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Maxim Boguknateless, 10-20ms - порядок времени задержки обращения к диску так что это нормальное поведение. Надо гарантированно быстрее - используйте SSD, а них задержки на пару порядков ниже будут. PS: а сколько у вас shared_buffers? -- Maxim Boguk www.postgresql-consulting.ru shared_buffers = 8GB На SSD видим примерно такие-же спайки при похожей конфигурации правда БД только 70% от основной, хотя на новом сервере памяти 64GB и настройки соотвественные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 16:47 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessMaxim Boguknateless, 10-20ms - порядок времени задержки обращения к диску так что это нормальное поведение. Надо гарантированно быстрее - используйте SSD, а них задержки на пару порядков ниже будут. PS: а сколько у вас shared_buffers? -- Maxim Boguk www.postgresql-consulting.ru shared_buffers = 8GB На SSD видим примерно такие-же спайки при похожей конфигурации правда БД только 70% от основной, хотя на новом сервере памяти 64GB и настройки соотвественные. Плохой ssd значит. Нормальный SSD Intel s3710 (в крайнес случае s3610 или s3510). полезно включать track_io_timing и делать explain (analyze, costs, buffers, timing) запрос чтобы понимать что происходит. Такие пики время от времени это только дисковый IO. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 16:51 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessMasterZiv20 ms -- это же нормально, чего жалуешься? около 80% всех инсертов укладываются меньше чем в 1ms. Для нас это критично. Это не может быть критично. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 17:22 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessMasterZiv20 ms -- это же нормально, чего жалуешься? около 80% всех инсертов укладываются меньше чем в 1ms. Для нас это критично. Делайте асинхронную вставку/буферизацию. Т.е. пишите в файл или в быструю очередь а уж из нее скидывайте в базу. Но вообще 20ms в 1 случае из 100-1000 не должно быть проблемой. -- Maxim Boguk www.postgresql-consulting.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 17:33 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Maxim Boguknatelessпропущено... около 80% всех инсертов укладываются меньше чем в 1ms. Для нас это критично. Делайте асинхронную вставку/буферизацию. Т.е. пишите в файл или в быструю очередь а уж из нее скидывайте в базу. Но вообще 20ms в 1 случае из 100-1000 не должно быть проблемой. -- Maxim Boguk www.postgresql-consulting.ru Не можем. Мы импортируем БД blockchain, каждый блок состоит из двух тысяч транзакций, каждая транзакция состоит из входов ( предыдущие выходы ) и выходов, которых в транзакции может быть от 1 до нескольких тысяч. Сейчас каждый блок импортируется в среднем за 60 секунд и это примерно 60% завершено, дальше будет дольше. Каждый блок идет в транзакцию что бы откатить в случае ошибки или остановки. В эту транзакцию укладываются все данные их десятки тысяч записей + апдейты старых. По сколько данные зависят друг от друга необходимо добавлять к приеру транзакцию перед входами и выходами так как они ссылаются на id. необходимо помечать выхода как использованные с каждой транзакцией, и еще много чего. Поэтому спайки в 20 мс на 1000 транзакций дают задержку в 10-20 секунд на блок, а блоков 400 тысяч. При текущей скорости импорта это займет почти месяц, что ну ни в какие ворота :) А если ошибка в коде и нужно будет реимпортнуть БД то можно застрелиться. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 17:43 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
nateless, Из общих соображений. Индексы по trx_id точно нужны оба? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 18:12 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Павел Лузановnateless, Из общих соображений. Индексы по trx_id точно нужны оба? Да спасибо, я уже сегодня понял что нам надо иcключить несколько индексов вообще пока идет импорт, так как они влияют на скорость записи, а сипользуются уже на вебморде после импорта. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 18:21 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelesssynchronous_commit = off - временно отключили его что бы оптимизировать импорт work_mem = 78643kB checkpoint_segments = 32 checkpoint_completion_target = 0.7 Если вы много пишете в базу, то имеет смысл добавить сегментов, до 128 для начала. И c_c_t поднять до 0.85-0.9. Если это разовая операция и надо быстрее, то может `fsync = off`? Тем более, что уже `synchronous_commit = off`. И `work_mem` большой, при умолчательных 100 соединениях вы отдаете 78GB, которых нету. Зачем так много? Что у вас в `/etc/sysctl.conf` на тему `vm.%`? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 19:08 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
vyegorovnatelesssynchronous_commit = off - временно отключили его что бы оптимизировать импорт work_mem = 78643kB checkpoint_segments = 32 checkpoint_completion_target = 0.7 Если вы много пишете в базу, то имеет смысл добавить сегментов, до 128 для начала. И c_c_t поднять до 0.85-0.9. Если это разовая операция и надо быстрее, то может `fsync = off`? Тем более, что уже `synchronous_commit = off`. И `work_mem` большой, при умолчательных 100 соединениях вы отдаете 78GB, которых нету. Зачем так много? Что у вас в `/etc/sysctl.conf` на тему `vm.%`? Спасибо, поробуем с этими настройками сегодня. По факту 100 соединений нет, на импорт идет один коннект. В основном пишем, то что пишем потом стараемся сразу в redis класть что бы дергать от туда потом. sysctl.conf поправили слегка: kernel.shmmax = 16797089792 kernel.shmall = 4100852 vm.swappiness = 10 ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 20:18 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Стандартно на массивный начальный импорт отключают все индексы кроме тех, которые могут быть использованы самим импортом. Как вам уже сказали, вы при массивном импорте упираетесь в IO на дисковой системе. Как бы вы не игрались с кэшем файловой системы, контроллера массива и т.д. в долговременном плане вы упираетесь в скорость записи на диск. Следовательно, писать надо абсолютный минимум, а дисковая подсистема должна быть максимально быстрой. На сегодняшний день самые быстрые диски за вменяемые деньги будут SSD. К уже упомянутым настройкам можно добавить wal_level = minimum если меняли на другое. После импорта поменяете настройки базы, создадите индексы, да и данные можно будет скопировать на более медленные и дешевые носители. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 03.02.2016, 22:17 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
nateless, если то что импортировалось хранить ненадо, а данные только както обрабатываются и загружается новая порция, можно посмотреть в сторону UNLOGGED TABLE. так ещё секонимите IO на WAL. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2016, 09:48 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
Удалось частично ускорить выполнение, но все равно появляются рандомные спайки, к примеру этот запрос выполнялся 16!! секунд в первый раз: Код: sql 1. Код: sql 1. 2. 3. 4. 5. 6. 7. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 10:17 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
nateless, Сложно сказать. Может холодная часть как индекса, так и таблицы. Может был чекпойнт. Что показывает `sysctl -a|egrep '^vm.dirty'`? Если там большие значения (особенно в `%_ratio`, что есть проценты от виртуальной памяти), то ядро будет долго копить грязные страницы (до указанных значений) и потом разом сбрасывать на диск (блокирующая операция, если объем превышает кэш диска). Если вы отключили `fsync`, то это вполне возможно — надо понизить параметры. Вы саму систему мониторите (IO, VM, CPU)? Было бы полезно видеть что происходит на уровне ОС в такие моменты. Для проблемных запросов приводите вывод `EXPLAIN (analyze, buffers)` — это поможет лучше понять сколько буферов обрабатывается запросом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 11:00 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessУдалось частично ускорить выполнение, но все равно появляются рандомные спайки, к примеру этот запрос выполнялся 16!! секунд в первый раз: Код: sql 1. Код: sql 1. 2. 3. 4. 5. 6. 7. 600 произвольных доступов. это если у вас индексы не опухшие. Т.е *4 -- около 2400/в минуту. Только на чтение. но что--то подсказывает мне, что индексы у вас опухшие раз в 5--10. такое у меня предчувствие, судя по вашему коду. и вашему же времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 11:09 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
qwwq600 произвольных доступов. это если у вас индексы не опухшие. Т.е *4 -- около 2400/в минуту. Только на чтение. но что--то подсказывает мне, что индексы у вас опухшие раз в 5--10. такое у меня предчувствие, судя по вашему коду. и вашему же времени. Что значит опухшие? Я просто еще не очень разбираюсь в PostgreSQL. vyegorovnateless, Сложно сказать. Может холодная часть как индекса, так и таблицы. Может был чекпойнт. Что показывает `sysctl -a|egrep '^vm.dirty'`? Если там большие значения (особенно в `%_ratio`, что есть проценты от виртуальной памяти), то ядро будет долго копить грязные страницы (до указанных значений) и потом разом сбрасывать на диск (блокирующая операция, если объем превышает кэш диска). Если вы отключили `fsync`, то это вполне возможно — надо понизить параметры. Вы саму систему мониторите (IO, VM, CPU)? Было бы полезно видеть что происходит на уровне ОС в такие моменты. Для проблемных запросов приводите вывод `EXPLAIN (analyze, buffers)` — это поможет лучше понять сколько буферов обрабатывается запросом. vm.dirty_background_bytes = 0 vm.dirty_background_ratio = 10 vm.dirty_bytes = 0 vm.dirty_expire_centisecs = 3000 vm.dirty_ratio = 20 vm.dirty_writeback_centisecs = 500 vm.dirtytime_expire_seconds = 43200 Диск загружен на 60% примерно. fsync отключили. Потребление памяти очень низкое 10GB из 32GB. load average: 3.80. Слегка свапится около 800MB. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 11:52 |
|
||
|
Задержка при выполнении селекта по индексу
|
|||
|---|---|---|---|
|
#18+
natelessУдалось частично ускорить выполнение, но все равно появляются рандомные спайки, к примеру этот запрос выполнялся 16!! секунд в первый раз: Код: sql 1. [/src] Первый раз - данные все не в памяти уже (т.е. холодные). Смотрите... 600 ID это 600 раз считать страницы с индекса + 600 раз считать страницы с таблицы (и это в лучшем случае), вероятнее всего еще *2. 1200 IO на механическом НИЧЕМ другим не занятом диске выполняются за 10-20 секунд и быстрее вы это НИКАК не сделаете. А по вашим словам у вас еще и диски заняты. А PostgreSQL тут собственно не причем он работает с той скоростью с которой ему диски данные отдают в таких случаях. Быстрый (относительно) ответ по холодным данным возможен только на SSD где 1200IO операций можно за 0.1s отработать. PS: альтернативное решение - выделить достаточно оперативки на сервере и достаточно shared buffers так чтобы база всегда целиком лежала в shared buffers базы (т.е. shared_buffers>database size). Но даже в такой ситуации после рестарта сервера будет много тормозов пока данные с дисков в память все попадут. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 05.02.2016, 13:28 |
|
||
|
|

start [/forum/topic.php?fid=53&fpage=97&tid=1997465]: |
0ms |
get settings: |
8ms |
get forum list: |
20ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
50ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
68ms |
get tp. blocked users: |
2ms |
| others: | 214ms |
| total: | 380ms |

| 0 / 0 |
