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

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

Так и делали, в принципе. Но мне это в наследство досталось, тот, кто делал уже не работает с нами.

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

Да, похоже на то... естественно, зависит от минимального объёма выбираемых данных в запросе (т.е., например, чтобы найти среднее значение какого-то value за весь период по заданной бирже, _нужно_ прочитать все её данные, т.к. другого выхода просто нет).

Там обычно графики строили примерно по 50-70 свечей, на день, неделю и тд. Выбирали соответственно исходя из периода только.

Но, если у вас сейчас партиции небольшого размера, и большинство запросов обходятся одной (и достаточно быстры _именно_ по execution time (из EXPLAIN ANALYZE)), то c объёмами у вас проблемы нет.

Сейчас посмотрю на проде количество записей

Там запрос count по таблице только полминуты был

(41178.0ms) SELECT COUNT(*) FROM "pair_histories" => 266321665

Там запрос count по таблице только полминуты был

По одной из партиций?

Это по старой таблице, она ещё на проде жива.

Из партиций, которые удалось сделать, микросекунды были

(41178.0ms) SELECT COUNT(*) FROM "pair_histories" => 266321665

А, так это по всей таблице? Ну так с виду при нормальном железе это (описанные запросы) должно летать. :)

Из партиций, которые удалось сделать, микросекунды были

Т.е. проблемы с объёмами у вас действительно нет. Оптимизируйте запросы к "старой" таблице, короче говоря. :)

вот это хорошая новость, тогда буду в этом направлении двигаться

Спасибо Вам

Иными словами мне нужно сделать единую таблицу и индивидуальные индексы? Там запросы в основном содержат биржу, пару, время начала и конца периода. По каждому индексы были, по ночам даже вакуум кроном запускался.

(перечитывая лог). А зачем вы VACUUM-то cron-ом делали (и _какой именно_ командой, ради интереса)? Обычно autovacuum должен справляться...

вот это хорошая новость, тогда буду в этом направлении двигаться

Вы заходите с конкретными запросами / планами, если что. ;)

Нашел, просто VACUUM по нескольким таблицам и потом по ним же REINDEX TABLE

да, в следующий раз больше информации подберу к вопросу ) сейчас просто момент паники, когда все выходные все работало, а сейчас падать начало

Нашел, просто VACUUM по нескольким таблицам и потом по ним же REINDEX TABLE

И, тем не менее, это обычно решается настройкой autovacuum (autoanalyze)... если проблема вообще есть. ;)

я в принципе подозревал, что так не надо, но пока работало - не трогал

а где можно почитать про настройки памяти и прочего под конкретные объемы данных? потому как сначала я поймал ошибку PG::OutOfMemory: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction.

по ней сложно было понять, в чем дело

а где можно почитать про настройки памяти и прочего под конкретные объемы данных? потому как сначала я поймал ошибку PG::OutOfMemory: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction.

В документации, как ни странно. ;) Есть т.н. "rules of thumb"... но они подходят не ко всем ситуациям (см. https://wiki.postgresql.org/wiki/Tuning_Your_PostgreSQL_Server , например).

а где можно почитать про настройки памяти и прочего под конкретные объемы данных? потому как сначала я поймал ошибку PG::OutOfMemory: ERROR: out of shared memory HINT: You might need to increase max_locks_per_transaction.

> ERROR: out of shared memory > HINT: You might need to increase max_locks_per_transaction. В исходниках есть ровно одно место, откуда может выдаваться это сообщение... и, похоже, HINT не врёт. ;)

я 1024 поставил наугад, не помогло

а как определить порядок нужного числа для этой настройки?

а как определить порядок нужного числа для этой настройки?

Тут я точно не скажу, но, если я правильно помню, это происходит во время планирования запроса, когда планировщик накладывает locks на все объекты (т.е. ему нужно примерно: кол-во partitions * какую-то константу (вот её-то я не помню) locks). А есть у него: max_locks_per_transaction * (max_connections + max_prepared_transactions)

а как определить порядок нужного числа для этой настройки?

Но всё равно, вам это не должно сильно помочь, потому что времена планирования у вас, по идее, всё равно будут _огромные_ (в том-то и проблема с большим количеством partitions). :(

Да, и учтите, что вот это "ему нужно" —- это для _одного_ соединения/запроса, а "есть" —- это для _всех_.

а если бы это были не партиции, а нормальные таблицы того же размера, это бы как-то иначе было? (делать так не буду, конечно)

да, там как раз и начало падать, когда я 4 потока запустил

теперь понятно, почему )

теперь понятно, почему )

Т.е. вы бы делали запросы к конкретным таблицам, типа okex_spot_rcn_btc? Если так, то да, было бы совсем иначе, т.к. locks бы накладывались только на неё (ну, и на служебные таблицы). Т.е. вы бы с этой проблемой не столкнулись бы, скорее всего, вообще никогда. ;)

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

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

Да, десятки тысяч таблиц —- не лучшая идея, в общем случае (это уже вызывает всевозможные проблемы, связанные с ростом системных таблиц (каталога)). Да и, плюс к тому, такое кол-во таблиц мало кто использует... и, если что, все bug-и будут ваши (и на проблемы с производительностью, даже если вы ими поделитесь в mailing lists, можно легко получить ответ в стиле "а вы так не делайте"). ;)

да, логично в принципе. предназначенное предпочтительнее приспособленного.

а Stas Kelvich у нас в чяте еще есть?

Нет, Стас отсюда ушёл из-за флуда. Если к Стасу есть вопрос -могу передать...

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

мб напишу ему письмо, или у вас там планы уже какие есть

Нет, Стас отсюда ушёл из-за флуда. Если к Стасу есть вопрос -могу передать...

Можно ведь было просто нотифаи отключить

@knizhnik кстати, сегодня осилил тред в хакерах про внутренний пулер. Мое почтение. Не знаю, что выйдет, но вопросы глобальных масштабов. Красавец

а Stas Kelvich у нас в чяте еще есть?

@mikhailtyurin уже пинганул, что потеряли

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

добавлю конечно, сравнение local/global, и просто бенчи на сколько обычные транзакции могут просесть по скорости

Можно ведь было просто нотифаи отключить

Я не так не могу) Потом все равно прочитаю и увижу, что кто-то в интернете неправ)

Я не так не могу) Потом все равно прочитаю и увижу, что кто-то в интернете неправ)

Терпи дольше. Тогда лень берет верх ?

ну это ты негативные тесты сделаешь, а надо еще позитивных пошардить пгбенч таблички по хешу, потом растаскивать их по серверочкам другим через фдв, и бенчить производительность в зависимости от расперделенных транзакций

плюс патчи для асинк фдв, если их еще не вмержили

плюс интересно как проседает перфоманс в зависимости от рассинхрона времени

как ведет себя на контеншоне

короче там уйму тестов можно сделать

ато не понятно ничего

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

заодно кол-во машин можно менять

второй вопрос, джепсеном тестили?

ну это ты негативные тесты сделаешь, а надо еще позитивных пошардить пгбенч таблички по хешу, потом растаскивать их по серверочкам другим через фдв, и бенчить производительность в зависимости от расперделенных транзакций

Такое пробовали. Там все плохо будет на OLTP из-за того что postgres_fdw кучу стейтментов шлет (BEGIN/SET/COOMIT) и просто в хождение в сеть упирается. Можно потяжелее запросы, но надо аккуратно придумать какие, чтоб не совсем с потолка. В сторону OLAP тож тяжело ибо postgres_fdw много чего не умеет

ато не понятно ничего

а как было бы понятно?

Такое пробовали. Там все плохо будет на OLTP из-за того что postgres_fdw кучу стейтментов шлет (BEGIN/SET/COOMIT) и просто в хождение в сеть упирается. Можно потяжелее запросы, но надо аккуратно придумать какие, чтоб не совсем с потолка. В сторону OLAP тож тяжело ибо postgres_fdw много чего не умеет

так были же патчи на асинк

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

ага, на ажуре тачки

ага, на ажуре тачки

ох

второй вопрос, джепсеном тестили?

ну самим джепсеном — нет, а набор тестов примерно тот же

что и в его тестах для галеры и кокроуча

а как было бы понятно?

на трех размерах базы (в буферах, в памяти, на диске) сделать тесты 1. бейзлайн, без шардинга 2. с шардингом, меняя кол-во серверов плюс у тебя так завязочка на ин прогресс транзакции значит надо сделать те же самые тесты меняя кол-во коннектов

что и в его тестах для галеры и кокроуча

а чем корректнес тестов проверяешь

на трех размерах базы (в буферах, в памяти, на диске) сделать тесты 1. бейзлайн, без шардинга 2. с шардингом, меняя кол-во серверов плюс у тебя так завязочка на ин прогресс транзакции значит надо сделать те же самые тесты меняя кол-во коннектов

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

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

для tpc-h я не знаю будет ли смысл делать тесты, пушо там обычно ридонли всё какие транзакции

а чем корректнес тестов проверяешь

основное — банковский тест с переводами денег и конкуррентным подсчетом баланса, на втроенном в пг перловом фреймворке запускаются пгбенчи с кастомными скриптами

https://github.com/jepsen-io/jepsen/tree/master/cockroachdb/src/jepsen/cockroach

получается примерно bank.clо джепсеновый

то есть тест детерминированный? знает что на выходе должно быть?

не, скорее знает чего не должно быть — не должен быть ненулевым баланс

ок

а дальше статистика, надо долго гонять чтоб что-то вылезло или не вылезло

> All readers who ran into tuples of an InDoubt transaction should wait until it ends and recheck visibility то есть ты такой читаешь, видишь xid, проверяешь что он расперделенный и сидишь ждешь его коммита?

такое чувство что это для сериалайзбл

а для снапшота зачем ждать я не понимаю

мб надо пейпер почитать, но вдруг ты так объяснишь

> All readers who ran into tuples of an InDoubt transaction should wait until it ends and recheck visibility то есть ты такой читаешь, видишь xid, проверяешь что он расперделенный и сидишь ждешь его коммита?

скорее не "видишь, что распределенный", а надо проверить не начали ли его коммитить. Если не начали, то ок, не видим тупл, а если уже начали, тогда — да, надо дождаться коммита и перепроверить по CSN

о, это важный нюанс

а для снапшота зачем ждать я не понимаю

если его начали коммитить распределенно, то где-то он может быть закоммичен локально, а где-то еще запущен. Для этого коммит идет в две фазы: сначала расстави всем InDoubt, потом закоммитим с каким-то снапшотом.

Ну и если кто-то наткнулся на InDoubt должен подождать, так как не знает какой там снапшот в конче будет

я понял да, что надо проверить если между препаре и коммит

угу, типо того

и подождать

релакс версию с коузал консистентностью не думал пилить?

для кей валью штук всяких

там поидее ждать меньше надо будет

на трех размерах базы (в буферах, в памяти, на диске) сделать тесты 1. бейзлайн, без шардинга 2. с шардингом, меняя кол-во серверов плюс у тебя так завязочка на ин прогресс транзакции значит надо сделать те же самые тесты меняя кол-во коннектов

можно сделать, но это будут тесты скорее postgres_fdw чем этих снапшотов. Там плочится что со снапшотами, что без них скорость одной ноды при шардинге достигается начиная с примерно трех нод, если говорить про нагрузку в стиле TPC-B / pgbench

хотя согласен, что это нагляднее