вот еще одна тестовая

причем на 9.5 до сих пор

продакшен и препрод не чистим

сейчас активно тестируем postgres_fdw

точнее его форк, greenplum_fdw

чтобы старые партиции загнать с сжатием в GP

а партиции в PG переасайнить на соответвующие партиции в GP

Вот это Вы явно делаете не так, как они. ;) И про производительность ничего не рассказали...

производительность - в среднем 6к tps на мастере и около 4к чтений в секунду на слейвах

на мастере 90% - это запись\обновление

причем много идет по секционированным таблицам, так что у нас не совсем тайм-сериес)

ну и из чтений основное - это индексный поиск по секционированным таблицам с пагинацией по времени

производительность - в среднем 6к tps на мастере и около 4к чтений в секунду на слейвах

Каких transactions? Вставка/обновлнение 1 row (а то так непонятно ничего)? Аналогично, какие запросы на slave?

обновление - в основном построчно

вставка - как адиночная, так и в батч-режиме

*одиночная

на синхронном слейве запросы - поиск по ключу во временном интервале с сортировкой по времени события

на асинхронном - более тяжелые аналитические запросы

ну и из чтений основное - это индексный поиск по секционированным таблицам с пагинацией по времени

Т.е. это не "масштабная" аналитика (как у Ivan Muratov)? > на синхронном слейве запросы - поиск по ключу во временном интервале с сортировкой по времени события Т.е. по одной partition, в основном? А partitions какого размера / сколько их, примерно? > на асинхронном - более тяжелые аналитические запросы (А, вот это уже ближе к тому, что у Ivan Muratov) И какая у них производительность / сколько данных читается?

партиции понедельные, средний обьем партиции на данный момент для базы в 14тб - 300гб

супер тяжелой аналитики у нас нету

для этих целей мы ежеминутно pg_cron’м строим некоторые витрины

у нас етсь заапрувленный делай до 2 минут

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

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

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

поэтому смотрим в сторону GP (опять же, есть успешный опыт построения хранилищ ОЧЕНЬ большого обьема)

вообще, я особо встревать не хотел, просто зацепило про живучесть базы на паре террабайт обьема)

шел сюда по другому вопросы

*вопросу

Ну круто что отписался)

Спасибо

у меня проблема, третий день страдаю

нужен полнотекстовый поиск

в связке с гео

БЫСТРЫЙ

)))

партиции понедельные, средний обьем партиции на данный момент для базы в 14тб - 300гб

Понятно, спасибо! > одиночные инстансы тайм-сериес никогда не дадут производительности, которую даютс системы с горизонтальным масштабированием It depends. Можно предварительно агрегировать... но не всегда, конечно.

)))

elasticsearch?

триграммы отдельно и gin раскурил, координаты отдельно тоже отлично индексируются

elasticsearch?

не очень удобно в использовании

пока хочется обойтись одним слоном

грубо говоря, мне нужно в функции набрать 10 строк для ответа API

сразу ищу в радиусе 10км

отсортированные по релевантности

если в этом радиусе не набралось 10 штук, то нужно добить записями в порядке удаления от центра поиска

понятно, что лимит и радиус поиска - величины динамически меняющиеся

решение “в лоб” нацарапали, работает

завтра сгененрируем данных пару миллионов строк, и оно, естественно, все встанет колом)

сразу ищу в радиусе 10км

Ищи knn

триграммы отдельно и gin раскурил, координаты отдельно тоже отлично индексируются

А если их вместе попробовать (в одном GIST-индексе), ради интереса?

когда обедал, подумал об этом

но потом решил, что бредовая идея

)))

но потом решил, что бредовая идея

Попробовать-то недолго. > завтра сгененрируем данных пару миллионов строк, и оно, естественно, все встанет колом) А это, вообще-то, совсем немного... от row size зависит, конечно.

Типа нет модуля, а он есть.

Не подскажите глупый вопрос - как дать пользователю права на селекты из всех таблиц? даю grant connect on database my_dat_name to i_sopov; GRANT USAGE ON SCHEMA public TO i_sopov; grant select on all tables in schema public to i_sopov; подключиться могу, поселектить что-то - ERROR: permission denied for schema public

всем привет, не большой специалист в postgre подскажите, какой механизм периодически может освобождать память в системе, GC или еще чтото? Столкнулся с тем, что OOM killer убил процесс по памяти.

всем привет, не большой специалист в postgre подскажите, какой механизм периодически может освобождать память в системе, GC или еще чтото? Столкнулся с тем, что OOM killer убил процесс по памяти.

Проверьте, что shared_buffers + work_mem * max_connections < доступная память в системе.

всем привет, не большой специалист в postgre подскажите, какой механизм периодически может освобождать память в системе, GC или еще чтото? Столкнулся с тем, что OOM killer убил процесс по памяти.

А он "по делу" убил процесс PostgreSQL? Если нет, почему бы не настроить OOM killer?

всем привет, не большой специалист в postgre подскажите, какой механизм периодически может освобождать память в системе, GC или еще чтото? Столкнулся с тем, что OOM killer убил процесс по памяти.

Обычно никакой. Все GC какие есть - внутри пользовательчских процессов. Система отвечает за CopyOnWrite или AllocationOnWrite и миграцию данных между memory и swap

Не подскажите глупый вопрос - как дать пользователю права на селекты из всех таблиц? даю grant connect on database my_dat_name to i_sopov; GRANT USAGE ON SCHEMA public TO i_sopov; grant select on all tables in schema public to i_sopov; подключиться могу, поселектить что-то - ERROR: permission denied for schema public

С виду, должно работать. Вы точно в той базе права дали? И точно к ней подключаетесь?

Проверьте, что shared_buffers + work_mem * max_connections < доступная память в системе.

buffers 2Gb work mem 56Mb max_conn=1500 (86Gb) mem available 24Gb

Проверьте, что shared_buffers + work_mem * max_connections < доступная память в системе.

Это, в общем случае, бесполезно (зависит от запросов).

Это, в общем случае, бесполезно (зависит от запросов).

а можно по подробнее

buffers 2Gb work mem 56Mb max_conn=1500 (86Gb) mem available 24Gb

Вы бы лучше посмотрели, обоснованно был "убит" backend или нет.

kill -9

а можно по подробнее

work_mem: 1. Ограничивает использование памяти только одним node плана (а их могут быть десятки). 2. Всё равно будет превышена некоторыми nodes, если оценки не соответствуют реальности.

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

Доброго времени суток, постгрес каждый день в одно и то же время уходит на pg_stat_wait . Никаких джобов нету в это время. С базой работает ERP система к которому нету доступа. В логах не пишет какой запрос тормозит, в какую сторону копать ? https://pastebin.com/XXpDJ7nn

Идет большая транзакция которая тормозит db1 2018-10-03 12:05:20 GET LOG: duration: 79657.156 ms statement: COMMIT Может добавочно какие то доги включить чтоб потом показать админам апликации

Доброго времени суток, постгрес каждый день в одно и то же время уходит на pg_stat_wait . Никаких джобов нету в это время. С базой работает ERP система к которому нету доступа. В логах не пишет какой запрос тормозит, в какую сторону копать ? https://pastebin.com/XXpDJ7nn

Я прямо начинаю подозревать, что "копать" в сторону upgrade. ;) Какая версия PostgreSQL?

Я прямо начинаю подозревать, что "копать" в сторону upgrade. ;) Какая версия PostgreSQL?

Upgrade пока не получится, 9.2 версия

Upgrade пока не получится, 9.2 версия

9.2? Жизнь - боль и страдания. На которые вы обрекаете себя сами. Оно уже давно снято с поддержки.

9.2? Жизнь - боль и страдания. На которые вы обрекаете себя сами. Оно уже давно снято с поддержки.

Знаю, этот один сервер остался пока не получается upgrade

это баг 9.2?

Upgrade пока не получится, 9.2 версия

Ну и как оно, "весело" на EOL сидеть? ;) Ладно... а какая OS? И да, Вы пытались разобраться с: > db1 2018-10-03 12:05:20 GET LOG: duration: 79657.156 ms statement: COMMIT Т.к. (в современных версиях) это необычно, и возможных причин немного.

Ну и как оно, "весело" на EOL сидеть? ;) Ладно... а какая OS? И да, Вы пытались разобраться с: > db1 2018-10-03 12:05:20 GET LOG: duration: 79657.156 ms statement: COMMIT Т.к. (в современных версиях) это необычно, и возможных причин немного.

centos 6.4 версия, мне интересно почему запрос не пишется в лог

Знаю, этот один сервер остался пока не получается upgrade

И, ксати, полная версия какая? Точно последняя?

centos 6.4 версия, мне интересно почему запрос не пишется в лог

Он пишется. У Вас в самом деле долгий COMMIT, и... см. выше.

Он пишется. У Вас в самом деле долгий COMMIT, и... см. выше.

9.2.4 точно не помню ,сейчас не сижу у компа вышел на час

centos 6.4 версия, мне интересно почему запрос не пишется в лог

С какой стати не пишется-то? Пишется: COMMIT - это и есть запрос, который висит.

9.2.4 точно не помню ,сейчас не сижу у компа вышел на час

Это при том, что последняя 9.2.24? Попробуйте начать с этого, хотя бы.

С какой стати не пишется-то? Пишется: COMMIT - это и есть запрос, который висит.

никак не посмотреть что он комитит?

никак не посмотреть что он комитит?

Вам надо менять формат записи в лог, чтобы увидеть процесс и номер запроса в сесси, чтобы отловить собственно запрос. Это - к документации (в комментах postgresql.conf есть вся необходимая информация)

интересно то что всегда в одно и тоже время зависает

И такой длинный коммит - он наводит на мысли, например, разные. Блокировки там, насилование дисковой системы с особопоказательной жестокостью, ну и вот это фсйо.

интересно то что всегда в одно и тоже время зависает

Ну так смотрите, что у вас в это время делается. В системе вообще, и в постгресе в частности. Или вы не в курсе, как посмотреть в консоли ПГ, чем он занят? А документацию почитать? Например, про мониторинг активности есть целая глава - вредно точно не будет.

никак не посмотреть что он комитит?

Транзакцию. ;) Вы читали, что я Вам выше писал? Начали бы Вы с update PostgreSQL, в самом деле... ну или можете release notes полистать (кстати, Вам всё равно придётся это делать).

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

И такой длинный коммит - он наводит на мысли, например, разные. Блокировки там, насилование дисковой системы с особопоказательной жестокостью, ну и вот это фсйо.

Блокировки обычно не имеют отношения к длинным commit-ам, кстати. Если транзакция уже COMMIT-ит, значит (в обычных случаях) все блокировки у неё уже есть.

в pgstat смотрел там комиты висят , что комитит не было видно. Значит изменю лог и надо поговорить с бизнесом для downtime

Ярослав добрый - всего-навсего релиз-нотес почитать. :) :D

и до 9.6 подняться

хотябы

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

Может быть, ROW_NUMBER() подойдёт?

и до 9.6 подняться

До 10-ки лучше. Там много хорошего в плане параллельных выборок при агрегациях завезли.