http://linuxscripter.blogspot.com/2013/09/using-tmpfs-to-improve-postgresql.html

это не используем

а есть статистика по количеству запросов на чтение/запись?

а есть статистика по количеству запросов на чтение/запись?

так как мы не логируем запросы короче 100мс, то ответить "да" не получится но примерно 90/10 Read-Write

вопрос: включен autovacuum, делается elapsed 606.95 sec. Сильно ли при включенном автовакуме падает производительность?

таблицы под несколько десятков-сотен гигабайт

analyze кластеру сделали?

сделали ещё раз. Без изменений

вопрос: включен autovacuum, делается elapsed 606.95 sec. Сильно ли при включенном автовакуме падает производительность?

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

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

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

и у нас когда делается автовакум, то всё тормозит

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

ты можешь посмотреть на это обычными утилитами исследования процессов в системе

кто нибудь?

кто нибудь?

вывод: кто-то скинул какие-то цифры в чат и хочет объяснений без описания проблемы

так как мы не логируем запросы короче 100мс, то ответить "да" не получится но примерно 90/10 Read-Write

а количество запросов 100+мс выросло? в них есть намёки?

ты можешь посмотреть на это обычными утилитами исследования процессов в системе

смотрели через заабих, но ничего аномального

так как мы не логируем запросы короче 100мс, то ответить "да" не получится но примерно 90/10 Read-Write

а если посмотреть на io через iotop, кто пишет?

вывод: кто-то скинул какие-то цифры в чат и хочет объяснений без описания проблемы

проблемы нет. Написал же что это pg_statio_all_tables хотелось бы узнать о чем эти цифры

а количество запросов 100+мс выросло? в них есть намёки?

особого роста нет, топ запросов тот же просто пропорциональный рост времени

особого роста нет, топ запросов тот же просто пропорциональный рост времени

iotop тогда, и рассматривать что с buffers в auto_explain

проблемы нет. Написал же что это pg_statio_all_tables хотелось бы узнать о чем эти цифры

вторая ссылка в гугле даже по-русски: https://postgrespro.ru/docs/postgrespro/10/monitoring-stats#PG-STATIO-ALL-TABLES-VIEW

это агрегированное, чтобы цифры набрались побольше

и логгер лидирует с большим отрывом

что делал 57257 на 29% io?

или его ныне живой аналог

как бы ещё это посмотреть

можно погрепать лог на этот pid

вторая ссылка в гугле даже по-русски: https://postgrespro.ru/docs/postgrespro/10/monitoring-stats#PG-STATIO-ALL-TABLES-VIEW

Видимо нужно было спросить хорошо когда количество дисковых блоков, прочитанных из этой таблицы/Число попаданий в буфер для этой таблицы = 42 доку читал

можно погрепать лог на этот pid

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

Небольшой вопрос. Eсть запрос, который вытаскивает Top-N значений with top as ( select story_id, count(*) as count, type from story_statuses where type = ? and removed_at is null group by story_id, type limit 5 ) select id, title, count, type from top join stories on top.story_id = stories.id; Должен ли я накладывать индекс на type и removed_at?

QUERY PLAN ------------------------------------------------------------------------------------ Hash Join Hash Cond: (story.id = top.story_id) CTE top -> Limit -> HashAggregate Group Key: story_statuses.quest_id, story_statuses.type -> Seq Scan on story_statuses Filter: ((removed_at IS NULL) AND (type = 'would-go'::text)) -> Seq Scan on stories -> Hash -> CTE Scan on top (11 rows)

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

тебе бы индекс на story_id, type where removed_at is null

Подскажите, пожалуйста, в какую сторону копать? Необходимо построить кластер отказоустойчивый, что сейчас самое перспективное и актуальное? планируем 10 версию использовать.

тебе бы индекс на story_id, type where removed_at is null

спасибо. индекс на story_id, type - понятно. А индекс на removed_at is null - это индекс на null значение?

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

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

супер! Пойду почитаю. Благодарю

тебе бы индекс на story_id, type where removed_at is null

только тайп и стори местами поменять

так порядок в групбае же

так а where

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

это было бы идеально да

group by type, story_id?

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

Спасибо!

На что может Logger process тратить иопсы и bw? Он пишет у меня <10G данных в сутки в файл, но при этом по иотопу легко делает гигабайт в 10 минут

На fsync

Чет я на графики поглядел. Число временных файлов стало меньше, количество записи больше - есть стойкок ощущение, что у вас просто БД стала обрабатывать больше запросов в секунду.

Небольшой вопрос. Eсть запрос, который вытаскивает Top-N значений with top as ( select story_id, count(*) as count, type from story_statuses where type = ? and removed_at is null group by story_id, type limit 5 ) select id, title, count, type from top join stories on top.story_id = stories.id; Должен ли я накладывать индекс на type и removed_at?

А где тут topN? Я не вижу ORDER BY в CTE...

Чет я на графики поглядел. Число временных файлов стало меньше, количество записи больше - есть стойкок ощущение, что у вас просто БД стала обрабатывать больше запросов в секунду.

увы, но сейчас она обрабатывает те же 80-90М в сутки (при пике в почти 200) И даже в пике мы не получали проблем с IO, Только с cpu

Почему сократилось число временных файлов?

это хороший вопрос

pg стал параллелить видимо... отсюда можно объяснить iowait. Но вот как сбез изменения настроек уменьшилось число/объем временных файлов?

work_mem подняли ребята при переносе, поэтому

но проблема в другом оказалась. log_rotation_size = 3

@Komzpa @ArtemTokarev @aggeisoft Спасибо за помощь!

Добрый день Подскажите, кто что использует для партиционирования таблиц в боевых условиях на БД? Со встроенным механизмом в 10ке пробовали работать?

интересно, а тяжело заставить pgbouncer <-> pgbouncer общаться через свой протокол с компрессией?

авито что-то такое не делало?

Наверно если обернуть поверх в TLS, компрессию можно получить за так

но за счёт воркеров pg

а хочеться это унести с базы

stunnel - разговаривает на pgsql протоколе

но не хочеться лишнего сервиса :)

Наверно если обернуть поверх в TLS, компрессию можно получить за так

ну или хотябы уровень компрессии регулировать :)

но компрессия в openssl доживает последние дни: https://www.postgresql.org/docs/devel/static/libpq-connect.html#LIBPQ-CONNECT-SSLCOMPRESSION

ну да! есть же однопоточные stunnel :D

А где тут topN? Я не вижу ORDER BY в CTE...

Я вытаскиваю список story_id с наибольшим количеством типов “type”. Почему это не topN задача?

Я вытаскиваю список story_id с наибольшим количеством типов “type”. Почему это не topN задача?

Потому что либо не вытаскиваете, либо я чего-то не вижу. Почему вы думаете, что именно с наибольшим? Где ORDER BY?

Потому что либо не вытаскиваете, либо я чего-то не вижу. Почему вы думаете, что именно с наибольшим? Где ORDER BY?

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

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

Какой "такой"? Может, вы не тот вставили?

with top as ( select story_id, count(*) as count, type from story_statuses where type = ? and removed_at is null group by type, story_id limit 5 ) select id, title, count, type from top join stories on top.story_id = stories.id;

возможно да, для упорядоченности, надо добавить еще order by

Какой "такой"? Может, вы не тот вставили?

Благодарю. Добавил

возможно да, для упорядоченности, надо добавить еще order by

Не можно, а нужно. ;) А так у вас 5 случайных групп выбирались.

а есть ли разница между созданием индекса для каждого столбца или сразу для нескольких в моем случае? “story_statuses_pkey" PRIMARY KEY, btree (id) "story_statuses_type_story_id_index" btree (type, story_id)

а есть ли разница между созданием индекса для каждого столбца или сразу для нескольких в моем случае? “story_statuses_pkey" PRIMARY KEY, btree (id) "story_statuses_type_story_id_index" btree (type, story_id)

А вы можете показать итоговый запрос?

А вы можете показать итоговый запрос?

да, конечно. with top as ( select story_id, count(*) as count, type from story_statuses where type = ? and removed_at is null group by type, story_id limit 5 ) select id, title, count, type, "order" from top join stories on top.story_id = stories.id order by count desc, "order"

да, конечно. with top as ( select story_id, count(*) as count, type from story_statuses where type = ? and removed_at is null group by type, story_id limit 5 ) select id, title, count, type, "order" from top join stories on top.story_id = stories.id order by count desc, "order"

Он по-прежнему неправильный, разве нет? Вы сначала (в CTE "top") выбираете 5 _произвольных_ story_id. Это именно то, что нужно?

Он по-прежнему неправильный, разве нет? Вы сначала (в CTE "top") выбираете 5 _произвольных_ story_id. Это именно то, что нужно?

хм. Мне нужно из статусов вытаскивать все статусы с одинаковым типом, группировать их по story_id, подсчитывая сколько получилось статусов у каждого story_id, и вывести список stories, упорядоченный по количеству записей и свойству stories(order)

хм. Мне нужно из статусов вытаскивать все статусы с одинаковым типом, группировать их по story_id, подсчитывая сколько получилось статусов у каждого story_id, и вывести список stories, упорядоченный по количеству записей и свойству stories(order)

Тогда зачем "limit 5" в CTE?

Тогда зачем "limit 5" в CTE?

потому что мне нужны все story_id, а только первые пять. Ааа, лимит нужно ставить вне CTE?

потому что мне нужны все story_id, а только первые пять. Ааа, лимит нужно ставить вне CTE?

Что такое "первые"? Вот, к примеру, кто из нас первый, я или вы? ;)

Что такое "первые"? Вот, к примеру, кто из нас первый, я или вы? ;)

)) первых 5 stories из списка упорядоченного по “count”

)) первых 5 stories из списка упорядоченного по “count”

Так вот и напишите там ORDER BY COUNT(*). PostgreSQL что, сам должен догадаться?

Так вот и напишите там ORDER BY COUNT(*). PostgreSQL что, сам должен догадаться?

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

подскажите, плз есть массив json объектов, типа {{"a" : "foo1", "foo2"}, {"b": "boo1", "boo2"}}. Надо по значению boo2 вывести всю строку, верхние значения изначально неизвесты что-то не могу догнать как это сделать..

ну, пожалуйста((

у вас json невалидный

как быть?

прочитать спецификацию json

?

кареглазая Сташа получает отпор от жестоких но справедливых знатоков жсон

или Стяша? ) Стейша?

не важно

главное в короткие сроки изучить json и что-то с этим сделать