приветствую всех. Господа, есть вопрос. Пишу проект, решил сменить БД с MySQL на PostgreSQL. Пока все хорошо, кроме одного момента. В функциональных тестах на каждый сценарий делаю TRUNCATE с cascade=true. И вот, что-то на постгресе транкейт отнимает прилично времени - 25сек. для каждого сценария. Есть какие-то лайфхаки, что подтюнить, чтобы сократить это время? Мб заменить на DELETE FROM table; VACCUUM (FULL, ANALYZE) table; Что посоветуете?

приветствую всех. Господа, есть вопрос. Пишу проект, решил сменить БД с MySQL на PostgreSQL. Пока все хорошо, кроме одного момента. В функциональных тестах на каждый сценарий делаю TRUNCATE с cascade=true. И вот, что-то на постгресе транкейт отнимает прилично времени - 25сек. для каждого сценария. Есть какие-то лайфхаки, что подтюнить, чтобы сократить это время? Мб заменить на DELETE FROM table; VACCUUM (FULL, ANALYZE) table; Что посоветуете?

truncate не удаляет данные, он обновляет пару строк в системной таблице, это самая быстрая операция

но чтобы это выполнить ему необходимо взять локи

Ну замеры говорят об обратном.

Таблиц не много. Около 20

у вас просто активное использование данной таблицы, truncate стоит в очереди и ожидает какой-нибудь залипшей транзакции на update/delete конкретно этой таблицы

Хм. Транзакцию только открываю. И транкейт это впринципе первая операция с бд. Но на всякий случай в логах проверю.

Спасибо за инфу.

глянул. транкейт это действительно одна из первых операций с БД. До этого толтько чтение из постгресовских таблиц типа pg_attribute, pg_index, pg_class и т.п. Т.е. на вставку ничего нет. Далее открываю транзакцию и начинаю truncate а за ним ALTER SEQUENCE .. RESTART где необходимо

мы в тестах выкрутили synchronuous_commit=off

транкейты стали отпускать быстрее

что-то легче не стало. от слова совсем. я все верно прописал? $conn->exec('SET synchronous_commit = off;');

а у вас foreign keys, или к чему cascade=true?

подозреваю, может помочь транкейтить в другом порядке, или встречных индексов по foreign key, чтобы проверки были шустрее или снимать fk перед транкейтами и потом возвращать на место

а у вас foreign keys, или к чему cascade=true?

да

а в постгресе естб аналог set FOREIGN_KEY_CHECKS = 0; ?

приветствую всех. Господа, есть вопрос. Пишу проект, решил сменить БД с MySQL на PostgreSQL. Пока все хорошо, кроме одного момента. В функциональных тестах на каждый сценарий делаю TRUNCATE с cascade=true. И вот, что-то на постгресе транкейт отнимает прилично времени - 25сек. для каждого сценария. Есть какие-то лайфхаки, что подтюнить, чтобы сократить это время? Мб заменить на DELETE FROM table; VACCUUM (FULL, ANALYZE) table; Что посоветуете?

Зачем вообще делать транкейт если можно просто откатывать транзакцию?

во время выполнения сценария может произойти несколько транзакций

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

Ну там же вложенные работают. Точнее savepoints.

А, ну хотя функциональные тесты наверно используют отдельное соединение? Тогда посмотреть что в другой транзакции действительно не получится

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

такая ситуация исключена. ORM вешает индексы на все FK

Ох уж эти ORM. Не доверяю я им ).

такая ситуация исключена. ORM вешает индексы на все FK

в какую сторону?

не может быть FK без индекса по этому полю)

но может быть fk без индекса по колонке, которая fk

в какую сторону?

Кстати, да. Может, она на само поле вешает?

индекс в обеих таблицах создается

покажь :)

:)

вот ddl одной из таблиц

create table streets ( id uuid not null constraint streets_pkey primary key, town_id uuid not null constraint fk_93f67b3e75e23604 references towns, district_id uuid not null constraint fk_93f67b3eb08fa272 references districts, name varchar(64) not null ) ; create index idx_93f67b3e75e23604 on streets (town_id) ; create index idx_93f67b3eb08fa272 on streets (district_id) ;

А причем тут вообще индексы?

ну, можно ещё спросить explain (analyze, verbose, buffers) от тормозящего транкейта

какая версия пг?

9.5.x

стандартный из коробки ubuntu 16.04

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

лочить никто не должен и не может. все в лоб. последовательно. руками сейчас проверю.

руками выглядит, что все также.

explain (analyze, verbose, buffers)

а fsync в каком сотоянии?

fsync тридцать секунд не накинет

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

и я сам(

так cascade не транкейтит, он по одной записи убивает

накинет, если много мелочи, там же дофига дисковых операций на truncate происходит

а fsync в каком сотоянии?

все в стандртном конфиге

развернул - звпустил

предлагаю банить за предложения fsync=off ;)

на стейдж среде для прогона тестов? предлагаю думать начать

деградация в 30 секунд на операцию при переходе с mysql подразумевает, что проблема не в fsync

сейчас свичнул БД. транкейт всех таблиц с каскадом на мускуле 4.98

поэтому, если у кого-то появятся мысли - буду благодарен.

Весьма голословное утверждение не зная схемы и среды окружения. Хотя в 9.2 на этот счет были патчи,

но ничего не мешает взять и проверить, чем рассуждать

Стас, попробуй fsync=off и посмотрим

fsync=off; верно?

оке

поэтому, если у кого-то появятся мысли - буду благодарен.

А запасти просто всю схему с данными и я у себя быстренько прогоню

сейчас в меня полетят ссаные тряпки, но вариант с докером не рассматривался?

(если не секретно)

а что будет, если всё затранкейтить в одном выражении, truncate table table1, table2, table3... restart identity cascade ?

fsync=off; Truncate all - 0.60193705558777

ERROR: S client not available

я же могу на сделать что-то подобное set fsync = off; затранкейтить, а потом set fsync = on;

или из-под юзера это не меняется

а зачем? у тебя же тестовая среда...

fsync can only be set in the postgresql.conf file or on the server command line. If you turn this parameter off, also consider turning off full_page_writes.

ну да,

ну помрет у тебя база, ну и фиг с ней, пересоздашь с нуля

а перформанс в том же окружении стейджится?

In many situations, turning off synchronous_commit for noncritical transactions can provide much of the potential performance benefit of turning off fsync, without the attendant risks of data corruption. но вот мне что-то synchronous_commit не помог (

а перформанс в том же окружении стейджится?

не понимаю о чем речь..

я все на локальной машине гоняю.

fsync=off может сделать так, что тест пройдёт за 0.00001, но в продакшене без fsync=off окажется 10000.1

ну в проде я транкейтить ничего не буду.

а тесты и не делаются для замеров производительности

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

задача была не ждать по 25сек на сценарий, пока я фиксанул что-то и хочу проверить что ничего не отвалилось

можно еще попробовать delete стратегию, на самом деле в некоторых случаях она быстрее в pg

но, конечно, лучше всего если получается в транзакцию все паковать

на данном этапе, я думаю этого хватит с головой. Большое всем спасибо за участие, интерес и ваше время. ?

[Из песочницы] Создание справочника адресной информации с блекджеком и API https://habrahabr.ru/post/333424/ Tags: PostgreSQL, PHP, Laravel, php, postgresql Author il_kow on #habrahabr

>Импорт данных осуществляется простым способом. Открываем файлы в Excel и сохраняем их как csv. слабаки

truncate, как и drop table, сканирует весь shared_buffers и удаляет из него страницы таблицы. Не знаю, основная ли это причина, но свой вклад она точно вносит. Причем это время зависит не от размера таблицы, а от размера shared_buffers.

пробовал уменьшить shared buffers до минимального, выйгрыша во времени это не дало

Я до сих пор не понимаю людей, которые пишут тесты и вычищают базу сами. Почему нельзя тест кейс обернуть в транзакцию и откатить?

Какие кейсы не работают с этим?

Включающие несколько транзакций

Какие кейсы не работают с этим?

Которые требуют коммита.

Тесты не меняют данные, нафига им коммит?

Как ты еще черную коробку протестируешь?

Как делать е2е без изменения данных?

Тесты не меняют данные, нафига им коммит?

Нафига мне такие тесты?! o_O

Я тестирую конкурентный доступ к данным в приложении. Как я без коммита увижу изменения в другой сессии?!