Мне кажется что ЭТО ВЫ уходите от изначальной темы.
Вы просили инструменты мониторинга, я дал вам ссылки на инструменты и подходы которыми пользуются при мониторинге производительности 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)!!! Но виноваты конечно компоненты Делфи
А дальше автор продолжает побеждать выдуманную проблему «Один коннект — одна транзакция»
1. Уже 20 лет как собираем через стандартный make (и dcc соответствующий — под нужную платформу). И даже Delphi ставить не нужно :), легко переключаемся между версиями библиотек
2. res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь. А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.
Учитывая накопленный объем информации об этой угрозе, мы полагаем, что данный список не является исчерпывающим, и угрозе могут быть подвержены и другие устройства.
Да я понимаю, что это не совсем точно 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)!!! Но виноваты конечно компоненты Делфи
А дальше автор продолжает побеждать выдуманную проблему «Один коннект — одна транзакция»
2. res файл (а соответственно номер версии и все остальное), создается из rc-файла, И это возможность тоже была всегда — пользуйтесь. А так как в svn есть простая возмость проставить номер ревизии (с помощью утилиты SubWCRev), то всегда точно знаешь из каких исходников был собран файл.
2. Кнопка power рядом Power!
Это что специально? Чтобы покупали XPS? У меня у самого Del XPS 9360 — там этих проблем нет.
Задумываюсь об обновлении, но из-за этих моментов эту модель точно не буду брать