0 просмотренных постов скрыто
Про посуточный съем
Вот объясните мне, почему заселение часто бывает с 12 часов, а то и 15? Люди часто выбирают рейсы, чтобы прибыть на вокзал пункта назначения утром и в дальнейшем придя в квартиру скинуть вещи, поспать или начать заниматься ещё чем либо. А получается что им надо полдня ходить по городу или сидеть у подъезда в ожидании когда их наконец пустят.
П.с. ещё и двойную плату иногда берут за однокомнатную квартиру, если гостей двое.
Использование PG_EXPECTO для выявления проблемных SQL запросов при анализе инцидента производительности СУБД PostgreSQL
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
«База данных «тормозит». В логах — сотни выполняемых запросов. Где та самая иголка в стоге сена, что заставляет СУБД стонать под нагрузкой? PG_EXPECTO — это магнит, который её находит.»
Расследование инцидентов производительности в PostgreSQL часто напоминает поиск иголки в стоге сена. Десятки тысяч запросов , и определить, какой именно из них стал «слабым звеном» системы, без специальных инструментов — крайне сложная задача.
В этой статье рассмотрим, как использование PG_EXPECTO позволяет кардинально ускорить этот процесс. Мы не будем гадать на основе снимков pg_stat_statements. Вместо этого мы научимся проактивно создавать «ловушки» на проблемные паттерны производительности. Когда инцидент происходит, PG_EXPECTO позволяет быстро найти проблемные SQL-запросы , предоставляя инженеру готовый список «подозреваемых» для дальнейшей оптимизации.
Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic и GitHub
Задача
Практическое применение представленных ранее методик использования pg_expecto :
Инцидент производительности СУБД в мониторинге Zabbix
Дашборд Zabbix
Шаг 1 - сформировать сводный отчет по метрика оценки производительности СУБД и инфраструктуры
cd /postgres/pg_expecto/sh/performance_reports/summary_report.sh '2025-11-01 10:22'
Шаг 2 - импортировать текстовые файлы в таблицы Excel
Действия аналогичны описанным ранее:
Раздел : Импортирование данных отчетов в Excel
Шаг 3 - Выявление аномалий инфраструктуры
1.Корреляция "Ожидания СУБД - vmstat"
Результат отчета:
SQL запросы создают нагрузку на инфраструктуру
2. Статистика vmstat+iostat по файловой подсистеме /data
Результат отчета:
Имеются проблемы производительности на запись для дискового устройства используемого для файловой системы /data
3. Статистика vmstat+iostat по файловой подсистеме /wal
Результат отчета:
Существенных аномалий нет, но возможно, имеются перспективы для оптимизации.
4. Чек-лист IO
Результат отчета:
Аномалий - не обнаружено.
5. Чек-лист CPU
Результат отчета:
Аномалий - не обнаружено.
6. Чек-лист RAM
Результат отчета:
Аномалий - не обнаружено.
7. Результат анализа инфраструктуры
Аномалии инфраструктуры, оказывающая влияние на производительность СУБД:
Превышение времени отклика на запись для дискового устройства используемого для файловой системы /data
Шаг 4 - корреляционный анализ производительности СУБД
Операционная скорость и ожидания СУБД в период, предшествующий инциденту
График операционной скорости СУБД. Красная линия - линия регрессии.
График ожидания СУБД. Красная линия - линия регрессии.
Корреляционный анализ ожиданий СУБД
Тип ожидания, имеющий наибольший коэффициент корреляции с ожиданиями СУБД - IPC
IPC: Серверный процесс ожидает взаимодействия с другим процессом. В wait_event обозначается конкретное место ожидания;
График ожиданий типа IPC
Диаграмма Парето по событиям ожидания СУБД - для типа ожидания IPC
Гипотеза(спойлер)
Можно сразу предположить , что причина - отсутствие индексов.
Диаграмма Парето по ожиданиям SQL запросов для типа ожидания IPC
Шаг 5 - формирование списка проблемных SQL запросов для последующей оптимизации
Список queryid SQL-запросов для оптимизации:
-1701015661318396920
3449463017331132112
-7715565454820708773
1374759154717555017
-678327810318891437
5459520954633506046
-3969322877824419761
3985919093425059746
Шаг 6 - получение рекомендации нейросети по снижению ожиданий типа IPC
Запрос нейросети
Файл сформированный отчетом : net.1.wait_event.prompt.txt
Выдели общие части из текста и найти смысловые совпадения. Сформируй краткий итог по необходимым мероприятиям в виде сводной таблицы.
Входной файл для нейросети сформированный отчетом : net.1.wait_event.IPC.txt
Результат работы нейросети DeepSeek
Шаг 7 - анализ проблемных SQL запросов нейросетью
Запрос нейросети
Файл сформированный отчетом : net.2.sql.prompt.txt
Выдели ключевые паттерны SQL запросов , с уточнением - сколько раз встречается паттерн. Сформируй итоговую таблицу - какие паттерны используются для каждого queryid. Выдели ключевые особенности SQL запроса, использующего наибольшее количество паттернов.
Входной файл для нейросети сформированный отчетом : net.2.sql.IPC.txt
Результат работы нейросети DeepSeek
Шаг 8 - Примерный план получения рекомендаций нейросети по оптимизации проблемного запроса queryid = 1374759154717555017
Проблемный запрос для оптимизации
Текст запроса
SELECT
"Table-1"."col1",
"Table-1"."col2",
"Table-2"."col1" AS "Table-2.col1",
"Table-2"."col3" AS "Table-2.col4",
"Table-2"."col6" AS "Table-2.col5",
"Table-3"."col1" AS "Table-3.col1",
"Table-3"."col6" AS "Table-3.col5",
"Table-3"."col7" AS "Table-3.col7",
"Table-3"."col8" AS "Table-3.col8"
FROM "public"."Table-1" AS "Table-1"
INNER JOIN "public"."Table-4" AS "Table-2" ON "Table-1"."col1" = "Table-2"."col6"
INNER JOIN "public"."Table-1_Table-3" AS "Table-3" ON "Table-1"."col1" = "Table-3"."col6" AND "Table-3"."col7" = 'ipr_training_id' AND "Table-3"."col8" = 'XXX'
Таблицы участвующие в запросе
Table "public.Table-1"
Column | Col2 | Collation | Nullable | Default
--------+---------------+----------+---------+---------------------
col1 | col1 | | not null | col1_generate_v1mc()
col2 | enum_task_col2 | | not null |
Indexes:
"Table-1_pcol7" PRIMARY COL7, btree (col1)
Referenced by:
TABLE "Table-4" CONSTRAINT "Table-4_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
TABLE "Table-1_Table-3" CONSTRAINT "Table-1_Table-3_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
TABLE "Table-1_meta" CONSTRAINT "Table-1_meta_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
TABLE "templates_Table-1" CONSTRAINT "templates_Table-1_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
Table "public.Table-4"
Column | Col2 | Collation | Nullable | Default
-----------+-----+----------+---------+---------------------
col1 | col1 | | not null | col1_generate_v1mc()
col3 | col1 | | not null |
col6 | col1 | | not null |
Indexes:
"Table-4_pcol7" PRIMARY COL7, btree (col1)
"Table-4_col3_col6_col7" UNIQUE CONSTRAINT, btree (col3, col6)
Foreign-col7 constraints:
"Table-4_col3_fcol7" FOREIGN COL7 (col3) REFERENCES plans(col1)
"Table-4_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
Referenced by:
TABLE "Table-1_statuses" CONSTRAINT "Table-1_statuses_plan_col6_fcol7" FOREIGN COL7 (plan_col6) REFERENCES Table-4(col1)
Table "public.Table-1_Table-3"
Column | Col2 | Collation | Nullable | Default
-----------+------------------------+----------+---------+---------------------
col1 | col1 | | not null | col1_generate_v1mc()
col6 | col1 | | not null |
col7 | enum_task_attribute_col7 | | not null |
col8 | text | | not null |
Indexes:
"Table-1_Table-3_pcol7" PRIMARY COL7, btree (col1)
"col6_col7" UNIQUE CONSTRAINT, btree (col6, col7)
Foreign-col7 constraints:
"Table-1_Table-3_col6_fcol7" FOREIGN COL7 (col6) REFERENCES Table-1(col1)
План выполнения запроса
EXPLAIN ( ANALYZE , VERBOSE , COSTS , BUFFERS , TIMING , SUMMARY )
SELECT "Table-1"."col1", "Table-1"."col2", "Table-2"."col1" AS "Table-2.col1", "Table-2"."col3" AS "Table-2.col4", "Table-2"."col6" AS "Table-2.col5", "Table-3"."col1" AS "Table-3.col1", "Table-3"."col6" AS "Table-3.col5", "Table-3"."col7" AS "Table-3.col7", "Table-3"."col8" AS "Table-3.col8"
FROM "public"."Table-1" AS "Table-1"
INNER JOIN "public"."Table-4" AS "Table-2" ON "Table-1"."col1" = "Table-2"."col6"
INNER JOIN "public"."Table-1_Table-3" AS "Table-3" ON "Table-1"."col1" = "Table-3"."col6" AND "Table-3"."col7" = 'ipr_training_id' AND "Table-3"."col8" = 'XXX';
QUERY PLAN
-------------------------------------------------------------------------
Gather (cost=51291.67..61070.22 rows=11 width=138) (actual time=212.782..228.904 rows=0 loops=1)
Output: "Table-1".col1, "Table-1".col2, "Table-2".col1, "Table-2".col3, "Table-2".col6, Table-3.col1, Table-3.col6, Table-3.col7, Table-3.col8
Workers Planned: 2
Workers Launched: 2
Buffers: shared hit=38808
-> Nested Loop (cost=50291.67..60069.12 rows=5 width=138) (actual time=198.025..198.030 rows=0 loops=3)
Output: "Table-1".col1, "Table-1".col2, "Table-2".col1, "Table-2".col3, "Table-2".col6, Table-3.col1, Table-3.col6, Table-3.col7, Table-3.col8
Inner Unique: true
Buffers: shared hit=38808
Worker 0: actual time=191.589..191.593 rows=0 loops=1
Buffers: shared hit=12830
Worker 1: actual time=191.283..191.288 rows=0 loops=1
Buffers: shared hit=10816
-> Parallel Hash Join (cost=50291.24..60066.84 rows=5 width=118) (actual time=198.023..198.027 rows=0 loops=3)
Output: "Table-2".col1, "Table-2".col3, "Table-2".col6, Table-3.col1, Table-3.col6, Table-3.col7, Table-3.col8
Inner Unique: true
Hash Cond: ("Table-2".col6 = Table-3.col6)
Buffers: shared hit=38808
Worker 0: actual time=191.587..191.590 rows=0 loops=1
Buffers: shared hit=12830
Worker 1: actual time=191.281..191.285 rows=0 loops=1
Buffers: shared hit=10816
-> Parallel Seq Scan on public.Table-4 "Table-2" (cost=0.00..9045.05 rows=278305 width=48) (never executed)
Output: "Table-2".col1, "Table-2".col3, "Table-2".col6
-> Parallel Hash (cost=50291.20..50291.20 rows=3 width=70) (actual time=197.528..197.529 rows=0 loops=3)
Output: Table-3.col1, Table-3.col6, Table-3.col7, Table-3.col8
Buckets: 1024 Batches: 1 Memory Usage: 0kB
Buffers: shared hit=38728
Worker 0: actual time=191.259..191.260 rows=0 loops=1
Buffers: shared hit=12790
Worker 1: actual time=190.969..190.970 rows=0 loops=1
Buffers: shared hit=10776
-> Parallel Seq Scan on public.Table-1_Table-3 Table-3 (cost=0.00..50291.20 rows=3 width=70) (actual time=194.885..194.885 rows=0 loops=3)
Output: Table-3.col1, Table-3.col6, Table-3.col7, Table-3.col8
Filter: ((Table-3.col7 = 'ipr_training_id'::enum_task_attribute_col7) AND (Table-3.col8 = 'XXX'::text))
Rows Removed by Filter: 1027564
Buffers: shared hit=38728
Worker 0: actual time=187.238..187.239 rows=0 loops=1
Buffers: shared hit=12790
Worker 1: actual time=187.176..187.176 rows=0 loops=1
Buffers: shared hit=10776
-> Index Scan using Table-1_pcol7 on public.Table-1 "Table-1" (cost=0.42..0.46 rows=1 width=20) (never executed)
Output: "Table-1".col1, "Table-1".col2
Index Cond: ("Table-1".col1 = "Table-2".col6)
Query Identifier: 1374759154717555017
Planning:
Buffers: shared hit=217
Planning Time: 2.928 ms
Execution Time: 228.955 ms
(49 rows)
Запрос нейросети
Как можно оптимизировать SQL запрос, используя прилагаемые таблицы участвующие в запросе и план выполнения запроса
Результат работы нейросети DeepSeek
Показать полностью
23
Продажа человечности
Открывал недавно с утра дверь в славном районе Солнечный.
Звонком вытащили прямо из-под одеяла, поэтому на кухню даже не зашел.
Быстро приехал, открыл и поменял замок человеку, и нашел на карте ближайшую пекарню на Золотистом бульваре.
Зашел, а там ряды нарумяненных булок и пирогов.
Выбрал сочень и кофе с молоком.
Выдали мне заказ, смотрю: нет пакетиков с сахаром, спрашиваю:
- А кофе у вас уже с сахаром?
- Нет, - отвечает мне парень-кассир.
Ищу глазами сахарницу, но не вижу.
- А где сахар?
- Сахар 3 рубля за пакетик, – говорит он и достает бумажные пакетики с сахаром.
Я подвисаю от такой странной ситуации.
- А в кофе у меня уже есть сахар? – на всякий случай снова спрашиваю я.
- Нет, – отвечает он.
- И чтобы мой кофе был с сахаром, мне нужно купить у вас отдельно сахар? – уточняю я.
- Да, – улыбается парень.
- А почему у вас тогда не написано, что кофе без сахара?
- Вот так, – пожимает он плечами.
Хочется еще что-то сказать, но вовремя понимаю, что он просто кассир и вряд ли это его идея.
- Ладно, – покупаю сахар, – а мешалки есть?
- Да, - достает он банку с мешалками.
- А они сколько стоят? – осторожно уточняю я.
- Нисколько, – отвечает он.
Эх, - думаю, – зря спросил, завтра продавать начнут)
Не стал ругаться, еду все-таки покупаю, но сказал, что больше я к ним за кофе никогда не приду.
До чего, интересно, мы дойдем такими темпами?
Люди уже сходят с ума от этой оптимизации.
Такое ощущение, что только и думают: как бы еще обобрать окружающих.
На мой взгляд – это саморазрушение проектов и людей, которые так мыслят.
Я вот туда больше не пойду, да и полагаю, я не один такой.
Тем более пекарен сейчас полно.
И сейчас такая оптимизация идет везде.
У меня возле дома ЖК установили шлагбаум, и теперь мне надо платить, что бы постоять у своего дома.
Сюрпризом стало, когда я узнал, что ответственности за оставленные авто и вещи никто не несет.
Просто стригут деньги.
Во многих организациях уже идут такие процессы, что из работников стараются выжать как можно больше, а заплатить как можно меньше.
Один мой товарищ, в дружеских кругах, называет хозяйку своей конторы не иначе как порноактриса или глубокая глотка.
А когда его спрашивают, почему, он отвечает: потому что никак не может остановиться.
Оптимизирует и оптимизирует.
Вроде и хорошо у нее все, но она постоянно ищет, где бы еще что-то кому-то недодать.
- Вроде, - говорит он, - все у нее уже есть, и становится все больше и больше и больше, а она от этого делается только еще более жадной и безчеловечной.
- Вроде ей уже не лезет, а она все равно сует и сует! – говорит он со злостью, объясняя свои метафоры.
А ведь когда-то он радовался, что работает в этой организации.
Активно развивал ее, стал руководителем, строил планы, и больше даже не свои, а корпоративные.
Теперь это все как корова языком слизала.
Его руководительница переработала его энергию, да, видимо, и многих других сотрудников, в ничто.
Раньше они строили компанию, в которой трудились.
Теперь большинство уходит, а те, кто остался, в основном думают, как бы урвать кусок посочнее.
И так, мне кажется, везде, где Мамона затмил людям глаза и заставил поставить жадность и алчность выше чести и совести.
Деньги – это энергия.
Но только тогда, когда их можно обменять на позитивную энергию других людей.
Тогда они строят.
Если руководители покупают за деньги негативную энергию своих работников и клиентов, то это разрушительная энергия, которая закладывает мину под саму основу проекта.
Это разрушает сам фундамент, и затем все рушится, а никто не понимает, почему...
И, думаю, теперь, когда капитализм показал свой оскал, нам нужно перестраиваться на новые рельсы, которые вернут нам человеческое отношение.
Иначе труба: мы сами себя уничтожим негативными мыслями и образами.
Оглянитесь вокруг: горы перепроизведенной продукции просто выкидываются, гниют и ржавеют на свалках.
А на все это мы взяли ресурсы нашей матушки Земли и просто выкинули их в никуда.
Мы превращаемся в раковую опухоль нашей планеты.
Вероятно, еще есть время очнуться от морока и начать строить другие модели общества.
Даже один светлый человек может сделать многое и помочь людям в своем окружении очистить их души от материальной шелухи, которая затмила наши истинные цели.
Искренне улыбайтесь людям, если еще можете, говорите добрые слова – это теперь самая ценная валюта.
Показать полностью
1
AMD поступили спорно
Ну, как говорится, надейся на лучшее, готовься к худшему.
AMD прекращает поддержку оптимизацию игр для видеокарт серии 5000 и 6000. То-есть моя Radeon Rx 6600 уже больше не канает. Если вы хотели получить новые дрова чтобы в Батлу 6 гонять без проблем, то всё, лавочке прикрыта. Также больше не стоит ждать обновлений и новых функций, связанных с трассировкой лучей и FSR.
Напомню, что PlayStation 5 и многие портативные консоли вроде steam deck используют 6000 серию.
Связано это с тем, что AMD хотят сосредоточится на новых технологиях связанных с искусственным интеллектом.
Ладно 5000 серия, Nvidia свои GTX 1000 вот только сейчас официально прекращает поддерживать. Но 6000 вышли совсем недавно, последняя новая модель вышла всё 2 года назад, в октябре 2023 - Radeon RX 6750 GRE. Это вполне производительные карты, тянущие многие современные игры минимум на средних, некоторые и на высоких настройках, если тех оптимизированы.
И вот собираю я сейчас компьютер, и думаю выбрать Radeon Rx 9060tx 16 GB, может 9070 если за удачную цену. А тут такие новости. А если через пять лет, что так-то немного для железа, появится новая более популярная технология, и им тоже крылья подлежат?
Показать полностью
Типовой шаблон расследования инцидентов PostgreSQL с помощью pg_expecto. Часть 2: Детальный разбор инфраструктуры сервера
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
Производительность СУБД — это лишь верхушка айсберга. Исследуем его основание.
«PostgreSQL — это гость в доме вашего сервера. И если в доме нет электричества (CPU), течет водопровод (память) или разъехался фундамент (диски), гостю будет некомфортно, как бы он ни был совершенен.»
Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic
Задача
Используя отчеты, сформированные с помощью расширения pg_expecto провести анализ производительности инфраструктуры сервера СУБД и взаимного влияния СУБД на инфраструктуру, возникновении инцидента производительности СУБД.
Начало
Формирование отчетов по метрикам производительности СУБД и инфраструктуры
Входной параметр отчета summary_report.sh:
Дата и время возникновения инцидента
cd /postgres/pg_expecto/performance_reports
./summary_report.sh '2025-10-25 11:09'
Результаты сводного отчета в виде текстовых файлов сохраняются в папке /tmp/pg_expecto_reports
Период формирования отчетов: 1 час .
Результирующие файлы отчетов аналогичны отчетам по нагрузочному тестированию
1.КОРРЕЛЯЦИЯ ОЖИДАНИЙ СУБД И МЕТРИК vmstat
Фрагмент отчета:
Результаты анализа отчета:
Проблемы с подсистемой IO
SQL запросы , возможно нуждаются в оптимизации.
2.КОРРЕЛЯЦИЯ МЕТРИК VMSTAT И IOPSTAT для файловой системы /data
Фрагмент отчета
Результаты анализа отчета:
Серьезные проблемы с дисковым устройством, используемом для файловой системы /data, оказывающие влияние на производительность СУБД.
3.КОРРЕЛЯЦИЯ МЕТРИК VMSTAT И IOPSTAT для файловой системы /wal
Фрагмент отчета
Результаты анализа отчета:
Проблемы с дисковым устройством, используемом для файловой системы /wal, оказывающие влияние на производительность СУБД.
4.Чек-лист подсистемы IO
Фрагмент отчета
Результаты анализа отчета:
Серьезные проблемы с подсистемой IO для сервера СУБД, оказывающие влияние на производительность СУБД.
5.Чек-лист CPU
Фрагмент отчета
Результаты анализа отчета:
Проблем со стороны CPU, оказывающих влияние на производительность СУБД - нет.
6.Чек-лист RAM
Фрагмент отчета
Результаты анализа отчета:
Проблем со стороны RAM, оказывающих влияние на производительность СУБД - нет.
Свопинг - отсутствует.
Итог: типовой шаблон анализа производительности инфраструктуры сервера СУБД при расследования инцидентов.
1. По результатам отчета "КОРРЕЛЯЦИЯ ОЖИДАНИЙ СУБД И МЕТРИК vmstat" - исключить или подтвердить влияние на производительность СУБД недостаточной производительности подсистемы IO.
2. По результатам отчета "КОРРЕЛЯЦИЯ ОЖИДАНИЙ СУБД И МЕТРИК vmstat" - исключить или подтвердить влияние на инфраструктуры сервера СУБД нагрузки создаваемой выполнением SQL запросов.
3. По результатам отчетов "КОРРЕЛЯЦИЯ МЕТРИК VMSTAT И IOPSTAT" , "Чек-лист подсистемы IO" - исключить или подтвердить:
Наличие проблем подсистемы IO
Производительность подсистемы IO
4. По результатам отчета "Чек-лист CPU" - исключить или подтвердить гипотезу о недостатке вычислительных ресурсов сервера СУБД.
5. По результатам отчета "Чек-лист RAM" - исключить или подтвердить гипотезу о недостатке RAM и наличии свопинга.
Показать полностью
6
Типовой шаблон расследования инцидентов PostgreSQL с помощью pg_expecto. Часть 1: Анализ на уровне СУБД
Взято с основного технического канала Postgres DBA (возможны правки в исходной статье).
От симптома к причине: системный подход к диагностике PostgreSQL.
«Правильно заданный вопрос — это половина ответа. Данная статья — это структурированный список вопросов, которые вы должны задать данным из pg_expecto, чтобы докопаться до истинной причины инцидента.»
Новый инструмент с открытым исходным кодом для статистического анализа, нагрузочного тестирования и построения отчетов доступен в репозитории GitFlic
Задача
Используя отчеты, сформированные с помощью расширения pg_expecto провести анализ метрик производительности СУБД возникновении инцидента производительности СУБД.
Формирование отчетов по метрикам производительности СУБД и инфраструктуры
Входной параметр отчета summary_report.sh:
Дата и время возникновения инцидента
cd /postgres/pg_expecto/performance_reports
./summary_report.sh '2025-10-25 11:09'
Результаты сводного отчета в виде текстовых файлов сохраняются в папке /tmp/pg_expecto_reports
Период формирования отчетов: 1 час .
Результирующие файлы отчетов аналогичны отчетам по нагрузочному тестированию
1. Определение типа ожидания СУБД имеющего наибольшую корреляцию со снижением производительности СУБД
Формирование таблицы в Excel
Отчет:
Результат отчета по показателям производительности и ожиданий СУБД
Результат анализа отчета - определение типа ожидания с наибольшей корреляцией и абсолютным значением.
Тип ожидания IO - имеет наибольшую корреляцию с ожиданиями СУБД и оказывает наибольшее влияние на снижение производительности СУБД в целом.
2. Определение проблемных SQL запросов.
Список SQL запросов, вызывающих наибольшее количество событий ожиданий по типу ожидания, оказывающего наибольшее влияние на снижение производительности СУБД.
Формирование таблицы в Excel
Результат отчета по событиям ожиданий для SQL запросов
Результат анализа отчета - определение SQL запросов и событий ожиданий по типу ожидания оказывающего наибольшее влияние на снижение производительности СУБД.
Проблемные SQL запросы:
-3805078444547199896
-4883642671474097249
События ожидания по проблемным запросам:
DataFileRead: Ожидание чтения из файла данных отношения.
DataFileWrite: Ожидание записи в файл данных отношения.
DataFileExtend: Ожидание расширения файла данных отношения.
Итог: типовой шаблон анализа производительности и ожиданий СУБД при расследования инцидентов.
1. Определение типа ожидания СУБД имеющего наибольшую корреляцию со снижением производительности СУБД
2. Определение проблемных SQL запросов.
Показать полностью
2
Лайфхак по быстрой уборке со стола
Подсмотрен в ресторанчике в районе Арбата в Москве.
Закупают каждый раз несколько коробок бумаги (похоже А1 или А0)
После приёма пищи гостем официанты выбрасывают старый лист бумаги и меняют на новый.
Быстро и дёшево.
Как вариант - крафтовая бумага или А3 - на одного человека (в этом случае при покупке 500+ листов около 100 р/мес)
Праздничный вариант - можно печатать узоры или вырезать на ЧПУ печать и делать отпечатки
Гораздо дешевле одноразовых бумажных скатертей
Показать полностью
3