|
|
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Может кто то сталкивался PG 12.5 Redhat 8.3 ядер 16 ОЗУ 32ГБ идет вставка в таблицу лога с тремя полями (int4, int4, text(40 символов всегда)) insert одной записи часто идет 1-2сек, судя по логу ПГ. В pg_stat_activity замечено, что в пике, таких insert рождается 30-40 в секунду и все они в состоянии LWLock, WALWriteLock балансировщика не установлено, только стандартный PG 12.5 Какие варианты побороть такие эффекты долгой вставки? Заранее спасибо ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 10:17 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
в данный момент никаких индексов нет на таблице ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 10:44 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Диски куда пишется wal медленные. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 11:01 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Не знаю как в PostgreSQL, а в Oracle, я Wal/Redo старался вынести на отдельный диск. Если HDD, то банальное перепозиционирование головок уже убивает всю запись логов. Wal/Redo пишется последовательно, скорость диска на максимуме, а любой сброс буферов файлов данных - приводит к перемещению головок и "затыку" в записи Wal/Redo. IMHO & AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 11:19 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
kliff, syncronous commit и fsync включены? попробуйте для интереса отключить "syncronous commit" и потестировать ещё раз? какие у вас диски? механика? ssd (какой)? что iostat -xmdy 10 в это время показывает отсчётов штук 5-10? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 11:21 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk kliff, syncronous commit и fsync включены? попробуйте для интереса отключить "syncronous commit" и потестировать ещё раз? какие у вас диски? механика? ssd (какой)? что iostat -xmdy 10 в это время показывает отсчётов штук 5-10? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru syncronous commit и fsync включены да как раз сейчас экспериментирую с отключением syncronous commit для этой вставки диски механика iostat попробую подловить ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 14:18 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
kliff Maxim Boguk kliff, syncronous commit и fsync включены? попробуйте для интереса отключить "syncronous commit" и потестировать ещё раз? какие у вас диски? механика? ssd (какой)? что iostat -xmdy 10 в это время показывает отсчётов штук 5-10? -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru syncronous commit и fsync включены да как раз сейчас экспериментирую с отключением syncronous commit для этой вставки диски механика iostat попробую подловить В такой ситуации - то что вы пишете 100% нормальное поведение и ничего с ним вы не сделаете кроме следующих вариантов 1)отключить syncronous commit или 2)перед дисками поставить кеширующий рейд контроллер с батарейкой и кешом на запись или 3)переходом на нормальные серверные ssd или 4)(оно конечно помогает но ограниченно на самом деле) вынос wal лог на отдельные от базы диски (не разделы а именно физические диски) -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 15:14 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk 4)(оно конечно помогает но ограниченно на самом деле) вынос wal лог на отдельные от базы диски (не разделы а именно физические диски) Насчет PG не знаю, но Oracle помогает кардинально. Wal/Redo по логике должны писаться чисто последовательно, если никто другой головки не дергает (кроме случая архивирования redo), то скорость записи что на старый HDD, что на современный SSD будет однофиолетовая, а возможно на HDD даже и быстрее. AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 15:24 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
1 и 2 в целом занятие рискованное. Т.к. на пункте 2, я бы написал нормальный (дорогой) контроллер с батарейкой + админы с прямыми руками. Видел убитые базы в ситуации: a) вполне приличной копьютерной фирмы, с дорогущей техникой (дабы сами и торговали), сертифицированными админами b) выключение питания примерно в 17:00 (админы на работе) c) воплей и писка ups'ов как минимум до 18:00-18:30, когда все ушли домой d) на утро в 9:00, базы которые были в виртуалках превратились в руины т.ч. в России, ни батарейка на контролере, ни UPS при грамотных админах - не помогают. AFAIK ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 15:29 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Спасибо за ответы. Все таки буду искать путь меньше инсертить. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 15:52 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
kliff Спасибо за ответы. Все таки буду искать путь меньше инсертить. Вставляйте батчами в транзакции... а ещё лучше копите данные в буфер и пишите батчами через COPY если бизнес требования позволяют. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 16:08 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk, "идет вставка в таблицу лога с тремя полями" Странно, что в PG да и вроде в PG Pro, до сих пор не реализована команда COMMIT NOWAIT. Как раз для логов было бы самое то. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 16:31 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev Maxim Boguk, "идет вставка в таблицу лога с тремя полями" Странно, что в PG да и вроде в PG Pro, до сих пор не реализована команда COMMIT NOWAIT. Как раз для логов было бы самое то. Так это и есть отключение sync commit для конкретной транзакции. Вполне сделанно. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 16:52 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Leonid Kudryavtsev 1 и 2 в целом занятие рискованное. Т.к. на пункте 2, я бы написал нормальный (дорогой) контроллер с батарейкой + админы с прямыми руками. Видел убитые базы в ситуации: a) вполне приличной копьютерной фирмы, с дорогущей техникой (дабы сами и торговали), сертифицированными админами b) выключение питания примерно в 17:00 (админы на работе) c) воплей и писка ups'ов как минимум до 18:00-18:30, когда все ушли домой d) на утро в 9:00, базы которые были в виртуалках превратились в руины т.ч. в России, ни батарейка на контролере, ни UPS при грамотных админах - не помогают. AFAIK Эм вообще то 1)а где вообще все были админы когда им должны были сыпаться sms с информацией о отключении питания (и были ли эти sms) если не было уведомлений (включая техдира) - недоработка админов если проигнорировали - скорее организационная недоработа и оргвыводы 2)а почему UPS не погасил сервера как должен делать при нормальной настройке когда осталось менее 30 минут запаса? Опять недоработка админов. В общем у меня большие сомнения в грамотности админов в этой ситуации. С synchronous_commit=off живет около 95% всех баз в production кроме жёско банковских и тп. Потому что база не развалиться а потеря последних 50-100ms транзакций при сбое питания или OS не то чтобы критична как правило. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 16:57 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk В общем у меня большие сомнения в грамотности админов в этой ситуации. So do I Но админы были с кучей сертификатов, фирма солидная, сопровождали дофига солидных заказчиков и так далее.... т.ч. кто я такой, что бы в профессионализме админов сомневаться ))) Мне кажется, тут вообще было нужно очень хорошо постараться с конфигурией железа. Т.к. добиться, что бы за >1.5 часа работы на ups'ах кэш на запись не доехал до дисков - это нужно быть профессионалами ))) Но в умелых руках админов и не такое видел. Maxim Boguk С synchronous_commit=off живет около 95% всех баз в production кроме жёско банковских и тп. Потому что база не развалиться а потеря последних 50-100ms транзакций при сбое питания или OS не то чтобы критична как правило. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru не спорю, я больше по Oracle ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.08.2021, 17:22 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
Maxim Boguk kliff Спасибо за ответы. Все таки буду искать путь меньше инсертить. Вставляйте батчами в транзакции... а ещё лучше копите данные в буфер и пишите батчами через COPY если бизнес требования позволяют. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru что имеется в виду под буффером? Например на бэке складывать записи в какой то файл, а при накоплении определенного числа лить в базу? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2021, 10:20 |
|
||
|
WALWriteLock ожидание
|
|||
|---|---|---|---|
|
#18+
kliff Maxim Boguk пропущено... Вставляйте батчами в транзакции... а ещё лучше копите данные в буфер и пишите батчами через COPY если бизнес требования позволяют. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru что имеется в виду под буффером? Например на бэке складывать записи в какой то файл, а при накоплении определенного числа лить в базу? Или в памяти копить... смотря какой уровень надежности требуется и сколько вставок в секунду. Но да... в файле или в памяти.... если операций реально много то копим в памяти и раз в секунду в базу скидываем батчем (если потеря 1 секунды данных допустима... если нет то копим в файле + fsync). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 18.08.2021, 10:31 |
|
||
|
|
start [/forum/topic.php?fid=53&msg=40090219&tid=1993897]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
50ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
53ms |
get tp. blocked users: |
1ms |
| others: | 256ms |
| total: | 406ms |
| 0 / 0 |
