Например я хочу что чтобы по нажатию Ctrl+Win + X переходил в определенный слой. А дальше при нажатии одной цифировой клавиши запускалось бы приложение. Как это сделать?
DataView в помощь, но конечно же придется результаты анализа внести в свойства и потом построить график. Но честно говоря, я пока не настолько часто сдаю анализы, чтобы так заморачиваться. А выходящие за границы значения и так во всех протоколах исследований подсвечены. У меня анализы от трех лабораторий, и везде они промаркированы самой лабораторией.
Вы уж извините, что я со своим скепсисом влез в комментарии, но дело в том, что у меня профдеформация: я 20-лет в области разработки медицинских информационных систем. Я помню как "Google Health" начинался, а потом был закрыт в 2012 (и кажется, я уже там тоже что-то пробовал хранить). А потом его судьбу и "Microsoft HealthVault" повторил.
Да хоть как. Вот эта формула точно к 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.
В статье у вас очень все поверхностно, и в комментариях вместо мониторинга нагрузки, вы уже пишете про захват и воспроизведение нагрузки (правда я не уверен что правильно вас понял).
Вот это велосипед!
Освойте уже obsidain + пару плугинов
Я не осилил программу.
Что такое аккорд? Что такое модифиактор?
Например я хочу что чтобы по нажатию Ctrl+Win + X переходил в определенный слой. А дальше при нажатии одной цифировой клавиши запускалось бы приложение. Как это сделать?
DataView в помощь, но конечно же придется результаты анализа внести в свойства и потом построить график.
Но честно говоря, я пока не настолько часто сдаю анализы, чтобы так заморачиваться.
А выходящие за границы значения и так во всех протоколах исследований подсвечены. У меня анализы от трех лабораторий, и везде они промаркированы самой лабораторией.
Вы уж извините, что я со своим скепсисом влез в комментарии, но дело в том, что у меня профдеформация: я 20-лет в области разработки медицинских информационных систем. Я помню как "Google Health" начинался, а потом был закрыт в 2012 (и кажется, я уже там тоже что-то пробовал хранить). А потом его судьбу и "Microsoft HealthVault" повторил.
Ребята молодцы,
но для себя я в итоге упорядочил все в Obsidian + DataView
Разложил по папкам:
стоматология
зрение
ИБ
профилактика
вакцинации
Настроил dataview
консультации
исследования
анализы
процедуры
вакцинации
заболевания
Отдельно завел для детей.
Увы но не для меня: во-первых обе не в размере TKL (80%), во вторых нет разделения по группам в функциональном ряду.
О спасибо!
Не знал, что буквенный блок уже чем обычно.
Насколько долго происходило привыкание к Ergohaven ?
Какую раскладку используете?
Да у них есть два варианта:
A4TECH Fstyler FBK11, A4TECH Fstyler FBK26C
Стоит недорого, и наверное попробую
Выглядит прикольно, а если бы они отрезали только цифровой блок, я наверное сразу и купил бы попробовать
Про ссылку наверное мой косяк, поправил.
По раскладке и наличию энкода - однозначно ДА. Но низкопрофильные кейкапы на обычных свичах, кажется не будут не очень .
Он еще и нажимается. По умолчанию включает/выключает звук.
А так через стандартный настройщик 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.
В статье у вас очень все поверхностно, и в комментариях вместо мониторинга нагрузки, вы уже пишете про захват и воспроизведение нагрузки (правда я не уверен что правильно вас понял).