Да хоть как. Вот эта формула точно к CPU вообще никакого отношения не имеет. Пальцем небо.
Ну прям таки никакого? Если время уходит не работу с диском, то на что оно уходит?
Да я знаю, что есть еще блокировки которые наверное CPU не кушают, а только "total_exec_time". А какое еще значимое время может быть спрятано во total_exec_time?
Конечно можно этот показатель и переобозвать не "CPU" а назвать "other time" :)
Если нужны точные данные для анализа, а не для отчетности юзерам то:
Тип pgpro_stats_rusage
На это я могу только облизываться. Бедны мои клиенты, не все могут позволить себе Postgres Pro Enterprise...
with s AS
(SELECT
sum(total_exec_time) AS t,
sum(blk_read_time + blk_write_time) AS iot,
sum(total_exec_time - blk_read_time - blk_write_time) AS cput,
sum(calls) AS s,
sum(ROWS) AS r
FROM
pg_stat_statements
WHERE
TRUE), _pg_stat_statements AS (
SELECT
dbid,
regexp_replace(query, E'\\?(, ?\\?)+', '?') AS query,
sum(total_exec_time) AS total_exec_time,
sum(blk_read_time) AS blk_read_time,
sum(blk_write_time) AS blk_write_time,
sum(calls) AS calls,
sum(ROWS) AS rows
FROM
pg_stat_statements
WHERE
TRUE
GROUP BY
dbid,
query
) /* END WITH*/
--- запрос по основным показателям
SELECT
(100*total_exec_time/(SELECT t FROM s))::numeric(20, 2) AS time_percent,
(100*(blk_read_time+blk_write_time)/(SELECT iot FROM s))::numeric(20, 2) AS iotime_percent,
(100*(total_exec_time-blk_read_time-blk_write_time)/(SELECT cput FROM s))::numeric(20, 2) AS cputime_percent,
(total_exec_time/1000)*'1 second'::interval as total_time,
((total_exec_time-blk_read_time-blk_write_time)*1000/calls)::numeric(20, 2) AS avg_cpu_time_microsecond,
((blk_read_time+blk_write_time)*1000/calls)::numeric(20, 2) AS avg_io_time_microsecond,
calls,
(100*calls/(SELECT s FROM s))::numeric(20, 2) AS calls_percent,
rows,
(100*rows/(SELECT r from s))::numeric(20, 2) AS row_percent,
(select datname from pg_database where oid=dbid) as database,
query
FROM _pg_stat_statements
WHERE
(total_exec_time-blk_read_time-blk_write_time)/(SELECT cput FROM s)>= 0.05
UNION all
SELECT
(100*sum(total_exec_time)/(SELECT t FROM s))::numeric(20, 2) AS time_percent,
(100*sum(blk_read_time+blk_write_time)/(SELECT iot FROM s))::numeric(20, 2) AS iotime_percent,
(100*sum(total_exec_time-blk_read_time-blk_write_time)/(SELECT cput FROM s))::numeric(20, 2) AS cputime_percent,
(sum(total_exec_time)/1000)*'1 second'::interval,
(sum(total_exec_time-blk_read_time-blk_write_time)*1000/sum(calls))::numeric(10, 3) AS avg_cpu_time_microsecond,
(sum(blk_read_time+blk_write_time)*1000/sum(calls))::numeric(10, 3) AS avg_io_time_microsecond,
sum(calls),
(100*sum(calls)/(SELECT s FROM s))::numeric(20, 2) AS calls_percent,
sum(rows),
(100*sum(rows)/(SELECT r from s))::numeric(20, 2) AS row_percent,
'all' as database,
'other' AS query
FROM _pg_stat_statements
WHERE
(total_exec_time-blk_read_time-blk_write_time)/(SELECT cput FROM s)< 0.05
По желанию можно добавить остальные показатели, типа временных блоков, для себя написал утилитку, периодически борюсь с проблемными запросами в топах
Мне кажется что ЭТО ВЫ уходите от изначальной темы.
Вы просили инструменты мониторинга, я дал вам ссылки на инструменты и подходы которыми пользуются при мониторинге производительности postgresql.
При чем здесь временные таблицы?
В статье вы пишите "При анализе данных мониторинга производительности я не обнаружил параметров, которые бы явно коррелировали с объемом потребляемой памяти."
Я вам привел конкретный раздел настроек postgresql который влияет на объем оперативной памяти.
Вы пишите "Это побудило меня поднять вопрос о том, как можно улучшить идентификацию "тяжелых" и "опасных" запросов для системы на основе данных мониторинга."
Ну так pg_stat_statement и выдаст вам такую ифомрацию. Именно самые тяжелые запросы по CPU, можно по IO, можно по временным файлам, по времени выполнения и т.п.
В статье вы пишете, что делаете нагрузочное тестирование. В чем проблема повторить при нагрузочном тестировании запросы? Непонятно.
Если вы вы хотите подсмотреть запрос с параметрами, то log_statement = all in postgresql.conf
Если у вас меняются сильно планы в зависимости от параметров запроса, но есть расширение pg_stat_plans.
В статье у вас очень все поверхностно, и в комментариях вместо мониторинга нагрузки, вы уже пишете про захват и воспроизведение нагрузки (правда я не уверен что правильно вас понял).
И еще огорчу автора. Боюсь что технологию, которую вы изобрели под названием "прокси, которая фиксирует запросы во временные таблицы" это вновь изобретенный велосипед на тему pg_stat_statements. Читать здесь: https://postgrespro.ru/docs/postgresql/17/pgstatstatements
Ну а после того изучите pg_stat_statement вам откроется мир с десятком утилит и расширений которые анализируют pg_stat_statement и десятки других представлений.
А ребята из postgrespro уже вплотную приблизились к базовому функционалу из Oracle Enterprise Manager 15-ти летней давности: https://postgrespro.ru/products/PPEM
Со всем уважением, но мне кажется, автор не совсем понимает как работает posgtresql. И начинает исследовать как ему кажется "черный ящик", и делать выводы.
Алилуйя! Обещают возможность создавать триггеры на события ON LOGIN (правда не увдел LOGOFF - хотя он и менее полезен)
Буду ждать еще фичи:
Пакетов как в Оракле (но не через схемы как postgres.pro). Ну пожалуйста ...
Автономных транзакций (но не через dblink)
И встроенный шедулер я тоже хочу (я знаю про pg_cron и т.п.)
На этом, мой список фич из Oracle 8i (1998 год) почти закончен (хотя встроенные аналоги AWR и ADDM я бы с удовольствием увидел. Да, можно Zabbix прикрутить, но я лучше просто помечтаю :) ).
Нет, система rttf автоматически может поправить рейтинг. Организатор может пожаловаться что админам, что алгоритм rttf плохо сработал (такое на моей практике было), и тогда они включают ручной режим. Алгоритм хорошо работает если новичок играет как с игроками выше себя, так и ниже.
Игроку, впервые принимающему участие в турнире, стартовый рейтинг для посева выставляет организатор по своему экспертному мнению. Стартовый RTTF-рейтинг назначается на основании результатов сыгранного турнира кратный 25, минимум 100 пунктов и может меняться задним числом на основании результатов следующих турниров.
Вот смотрю профиль игрока, которого на начальном посеве слегка переоценили: https://rttf.ru/players/103997. Я не вижу тут нулевой дельты
Ха, так тут всего 15 очков (которые она и так потеряла). На таких маленьких значениях это не работает Вот пример турнира: https://rttf.ru/tournaments/17608, смотреть на Романову, на скринах в группе у нее рейтинг 100, после пересчета начальный рейтинг стал 300.
Но вы и в другом тоже ошибаетесь, насколько я могу судить. Для новичков дельта не равна 0. Там просто коэффициенты другие. В первых пяти играх его рейтинг просто активнее будет меняться, только и всего.
Нет, я не ошибся. rttf пересчитывает рейтинг задним числом таким образом, чтобы дельта рейтинга новичка стремилась к нулю. А "коэффициент новичка" это действительно другое. Он сделан для того чтобы быстрее рейтинг соответствовал уровню мастерства.
Для этого в РТТФ есть костыль, описанный в пункте "7. Ручное изменение рейтинга".
Почему костыль? Он предназначен как раз для тех случаев, что описаны в п.7. Но подозреваю, что им пользуются настолько редко, что никто про него и не помнит.
Вы слишком зациклились на очках рейтинга, просто нужно играть и выигрывать - тогда и рейтинг будет высокий в любой системе
В RTTF начальный рейтнг огрназатором турнира выставляется только для ПЕРВОГО ПОСЕВА. Система потом сама скорректирует его таким образом чтобы дельта рейтинга в первых 5-ти турнирах была равна нулю. Поэтому важно поучаствовать в играх с разными игроками. Т.е. эта та самая автономность, которая нужна автору.
2.Также автор пишет: "Если разница в рейтинге победителя и проигравшего составляет более 100 очков (один спортивный разряд), то рейтинг не меняется." Но забывает добавить, что в только случае победы сильнейшего.
Выступления на турнире несколько отличаются от формата сыграть пару игр. В первую очередь мотивацией
В заключение добавлю
У каждого рейтинга есть свои достатки и недостоинтсва.
Рейтинг будет отображать реальное ваше место, только при условии частого участия в рейтинговых турнирах. (Причем нужно играть как с игроками сильнее по рейтингу, так и слабее).
Рейтинг влияет только на две вещи: стартовый посев, и турниры с ограничением по рейтингу
И конечно же посоветую: проведите несколько турниров и у вас у всех определиться рейтинг
Проблема программная: чтобы получить доступ к вставленной записи нужно было выполнить дополнительный SELECT-запрос, который возвращал максимальное значение первичного ключа (значение для только что вставленной записи). Причем этот процесс должен был проходить в пределах одной транзакции. Далее можно было обновлять или корректировать запись. Это сейчас я знаю, что некоторые драйверы БД возвращают значение первичного ключа для вставленной записи, но в 2003 году мы такими знаниями не обладали, да и не припомню что бы Делфи-компоненты возвращали что-то подобное.
М-да, вот что значит студенты взялись программировать БД. Даже в 2000 году было множество FAQ в которых говорилось используйте sequence и никогда select max(id)!!! Но виноваты конечно компоненты Делфи
А дальше автор продолжает побеждать выдуманную проблему «Один коннект — одна транзакция»
Он еще и нажимается. По умолчанию включает/выключает звук.
А так через стандартный настройщик Keychron можно что угодно прикрутить, в том числе и Mouse Wheel (вертикальный и горизонтальный)
Но меня вполне устраивает управление звуком.
Базовая 15 000 ₽
С переключателями и тачпадом около 23 000 ₽
https://ru.ergohaven.xyz/shop/tproduct/767494027-708129490331-high-plains-drifter-v2
А мне наоборот очень понравился ряд M-клавиш и крутилка слева!
А в остальном полностью согласен.
Ну прям таки никакого?
Если время уходит не работу с диском, то на что оно уходит?
Да я знаю, что есть еще блокировки которые наверное CPU не кушают, а только "
total_exec_time". А какое еще значимое время может быть спрятано воtotal_exec_time?Конечно можно этот показатель и переобозвать не "CPU" а назвать "other time" :)
На это я могу только облизываться. Бедны мои клиенты, не все могут позволить себе Postgres Pro Enterprise...
:(
По желанию можно добавить остальные показатели, типа временных блоков, для себя написал утилитку, периодически борюсь с проблемными запросами в топах
Да я понимаю, что это не совсем точно CPU , но для оценки в % вполне подойдет.
Хм, а если так?
total_exec_time - blk_read_time - blk_write_timeИ считать в процентах от общего числа...
Могу и запрос весь скинуть
О! многоуважаемый @Kilor подтянулся. Но боюсь автору даже он не сможет помочь :)
Мне кажется что ЭТО ВЫ уходите от изначальной темы.
Вы просили инструменты мониторинга, я дал вам ссылки на инструменты и подходы которыми пользуются при мониторинге производительности postgresql.
При чем здесь временные таблицы?
В статье вы пишите "При анализе данных мониторинга производительности я не обнаружил параметров, которые бы явно коррелировали с объемом потребляемой памяти."
Я вам привел конкретный раздел настроек postgresql который влияет на объем оперативной памяти.
Вы пишите "Это побудило меня поднять вопрос о том, как можно улучшить идентификацию "тяжелых" и "опасных" запросов для системы на основе данных мониторинга."
Ну так pg_stat_statement и выдаст вам такую ифомрацию. Именно самые тяжелые запросы по CPU, можно по IO, можно по временным файлам, по времени выполнения и т.п.
В статье вы пишете, что делаете нагрузочное тестирование. В чем проблема повторить при нагрузочном тестировании запросы? Непонятно.
Если вы вы хотите подсмотреть запрос с параметрами, то log_statement = all in postgresql.conf
Если у вас меняются сильно планы в зависимости от параметров запроса, но есть расширение pg_stat_plans.
В статье у вас очень все поверхностно, и в комментариях вместо мониторинга нагрузки, вы уже пишете про захват и воспроизведение нагрузки (правда я не уверен что правильно вас понял).
И еще огорчу автора.
Боюсь что технологию, которую вы изобрели под названием "прокси, которая фиксирует запросы во временные таблицы" это вновь изобретенный велосипед на тему pg_stat_statements.
Читать здесь: https://postgrespro.ru/docs/postgresql/17/pgstatstatements
Ну а после того изучите pg_stat_statement вам откроется мир с десятком утилит и расширений которые анализируют pg_stat_statement и десятки других представлений.
Пример одной из утилит: https://habr.com/ru/articles/494162/
А ребята из postgrespro уже вплотную приблизились к базовому функционалу из Oracle Enterprise Manager 15-ти летней давности: https://postgrespro.ru/products/PPEM
Ах да, совсем забыл упомянуть PGTUNE
https://pgtune.leopard.in.ua/
или какое-нибудь зеркало типа: https://pgtune.fariton.ru/
Но не забывайте, что pgtune это совсем не панацея.
Со всем уважением, но мне кажется, автор не совсем понимает как работает posgtresql.
И начинает исследовать как ему кажется "черный ящик", и делать выводы.
Все давно расписано в документации раздел "Потребление ресурсов"
https://postgrespro.ru/docs/postgresql/17/runtime-config-resource
И настоятельно рекомендую для начала исследований
прочитать книгу "PostgreSQL 17 изнутри"
https://postgrespro.ru/education/books/internals
Все в свободном доступе и бесплатно.
После прочтения можно вернуться к теме мониторинга с совсем другим взглядом.
Алилуйя! Обещают возможность создавать триггеры на события ON LOGIN (правда не увдел LOGOFF - хотя он и менее полезен)
Буду ждать еще фичи:
Пакетов как в Оракле (но не через схемы как postgres.pro). Ну пожалуйста ...
Автономных транзакций (но не через dblink)
И встроенный шедулер я тоже хочу (я знаю про pg_cron и т.п.)
На этом, мой список фич из Oracle 8i (1998 год) почти закончен (хотя встроенные аналоги AWR и ADDM я бы с удовольствием увидел. Да, можно Zabbix прикрутить, но я лучше просто помечтаю :) ).
Можете минусовать, но я никогда не пойму зачем люди ставят такое приложение.
Хочешь попить воды - пойди и выпей воды.
Нет, система rttf автоматически может поправить рейтинг. Организатор может пожаловаться что админам, что алгоритм rttf плохо сработал (такое на моей практике было), и тогда они включают ручной режим. Алгоритм хорошо работает если новичок играет как с игроками выше себя, так и ниже.
Отсюда https://rttf.ru/content/2
4. Стартовый рейтинг и рейтинг новичков.
Игроку, впервые принимающему участие в турнире, стартовый рейтинг для посева выставляет организатор по своему экспертному мнению. Стартовый RTTF-рейтинг назначается на основании результатов сыгранного турнира кратный 25, минимум 100 пунктов и может меняться задним числом на основании результатов следующих турниров.
Ха, так тут всего 15 очков (которые она и так потеряла). На таких маленьких значениях это не работает
Вот пример турнира: https://rttf.ru/tournaments/17608, смотреть на Романову, на скринах в группе у нее рейтинг 100, после пересчета начальный рейтинг стал 300.
Нет, я не ошибся. rttf пересчитывает рейтинг задним числом таким образом, чтобы дельта рейтинга новичка стремилась к нулю. А "коэффициент новичка" это действительно другое. Он сделан для того чтобы быстрее рейтинг соответствовал уровню мастерства.
Почему костыль? Он предназначен как раз для тех случаев, что описаны в п.7. Но подозреваю, что им пользуются настолько редко, что никто про него и не помнит.
Вы слишком зациклились на очках рейтинга, просто нужно играть и выигрывать - тогда и рейтинг будет высокий в любой системе
Что недопонял автор про рейтинг RTTF:
В RTTF начальный рейтнг огрназатором турнира выставляется только для ПЕРВОГО ПОСЕВА. Система потом сама скорректирует его таким образом чтобы дельта рейтинга в первых 5-ти турнирах была равна нулю. Поэтому важно поучаствовать в играх с разными игроками. Т.е. эта та самая автономность, которая нужна автору.
2.Также автор пишет:
"Если разница в рейтинге победителя и проигравшего составляет более 100 очков (один спортивный разряд), то рейтинг не меняется."
Но забывает добавить, что в только случае победы сильнейшего.
Выступления на турнире несколько отличаются от формата сыграть пару игр. В первую очередь мотивацией
В заключение добавлю
У каждого рейтинга есть свои достатки и недостоинтсва.
Рейтинг будет отображать реальное ваше место, только при условии частого участия в рейтинговых турнирах. (Причем нужно играть как с игроками сильнее по рейтингу, так и слабее).
Рейтинг влияет только на две вещи: стартовый посев, и турниры с ограничением по рейтингу
И конечно же посоветую: проведите несколько турниров и у вас у всех определиться рейтинг
М-да, вот что значит студенты взялись программировать БД. Даже в 2000 году было множество FAQ в которых говорилось используйте sequence и никогда select max(id)!!! Но виноваты конечно компоненты Делфи
А дальше автор продолжает побеждать выдуманную проблему «Один коннект — одна транзакция»