Горячее
Лучшее
Свежее
Подписки
Сообщества
Блоги
Эксперты
#Круги добра
Войти
Забыли пароль?
или продолжите с
Создать аккаунт
Я хочу получать рассылки с лучшими постами за неделю
или
Восстановление пароля
Восстановление пароля
Получить код в Telegram
Войти с Яндекс ID Войти через VK ID
Создавая аккаунт, я соглашаюсь с правилами Пикабу и даю согласие на обработку персональных данных.
ПромокодыРаботаКурсыРекламаИгрыПополнение Steam
Пикабу Игры +1000 бесплатных онлайн игр Битва Героев: RPG - увлекательная игра в жанре РПГ.

Битва Героев: RPG

Приключения, Фэнтези

Играть

Топ прошлой недели

  • SpongeGod SpongeGod 1 пост
  • Uncleyogurt007 Uncleyogurt007 9 постов
  • ZaTaS ZaTaS 3 поста
Посмотреть весь топ

Лучшие посты недели

Рассылка Пикабу: отправляем самые рейтинговые материалы за 7 дней 🔥

Нажимая кнопку «Подписаться на рассылку», я соглашаюсь с Правилами Пикабу и даю согласие на обработку персональных данных.

Спасибо, что подписались!
Пожалуйста, проверьте почту 😊

Помощь Кодекс Пикабу Команда Пикабу Моб. приложение
Правила соцсети О рекомендациях О компании
Промокоды Биг Гик Промокоды Lamoda Промокоды МВидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
0 просмотренных постов скрыто
kznalp
kznalp
4 месяца назад
Искусственный интеллект
Серия ITшное

YandexGPT vs DeepSeek. Китаец в пролёте . В полном⁠⁠

Вопрос :Где можно найти материалы по методу корреляционного анализа ожиданий СУБД PostgreSQL ?

Ответ YandexGPT

**Корреляционный анализ ожиданий** в PostgreSQL - это методика поиска проблемных SQL-запросов при продуктивной нагрузке.

Основные источники информации по данной методике:

* **PG_HAZEL** - инструмент для анализа производительности PostgreSQL, использующий данный метод
* **Документация PostgreSQL** - содержит базовые понятия и термины, связанные с ожиданиями и производительностью
* **Специализированные блоги** и публикации DBA-специалистов, где описываются практические кейсы применения метода

Методика включает следующие этапы:

* **Анализ операционной скорости** на уровне кластера
* **Мониторинг ожиданий** на уровне кластера
* **Корреляционный анализ** на уровне кластера
* **Статистический анализ** выполнений и ожиданий по отдельным SQL-запросам

Ключевые метрики для анализа:

* **QUERYID** - идентификатор SQL-запроса
* **CORRELATION** - коэффициент корреляции между ожиданиями
* **CALLS** - количество выполнений запроса
* **WAITINGS** - количество ожиданий
* **WAITINGS TO CALL** - отношение ожиданий к выполнениям

Особое внимание уделяется **типам ожиданий**:
* DataFilePrefetch
* DataFileRead
* DataFileWrite
* WALSync
* WALWrite

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


Ответ DeepSeek

Для изучения метода корреляционного анализа ожиданий (Correlation Analysis of Expectations) в PostgreSQL вы можете обратиться к следующим источникам:

### **1. Официальная документация PostgreSQL**
- **Planner/Optimizer Statistics**: В документации PostgreSQL описано, как оптимизатор использует статистику для построения планов запросов, включая корреляцию между столбцами.
- [PostgreSQL: Statistics Used by the Planner](https://www.postgresql.org/docs/current/planner-stats.html)
- [PostgreSQL: Multivariate Statistics](https://www.postgresql.org/docs/current/multivariate-statist...) (для анализа корреляции между несколькими столбцами)

### **2. Книги и учебные материалы**
- **"PostgreSQL 14 Internals"** (E. Rogov, A. Belyaev) – книга объясняет работу планировщика и статистику, включая корреляцию.
- **"Mastering PostgreSQL"** (Hans-Jürgen Schönig) – содержит разделы по оптимизации запросов и статистике.

### **3. Статьи и блоги**
- **Use of Correlation in PostgreSQL Query Planning**:
- [Understanding PostgreSQL Query Planning](https://www.timescale.com/blog/how-postgresql-query-optimiza...)
- [Correlation and PostgreSQL Indexes](https://www.cybertec-postgresql.com/en/postgresql-index-corr...)
- **Примеры анализа корреляции через `pg_stats`**:
```sql
SELECT attname, correlation
FROM pg_stats
WHERE tablename = 'your_table' AND schemaname = 'public';
```

### **4. Исследовательские работы и презентации**
- **"Advanced Query Planning in PostgreSQL"** (лекции с конференций PGConf, PGDay).
- **"Statistics in PostgreSQL: How the Planner Works"** (доклады разработчиков, например, от Robert Haas).

### **5. Практические примеры**
- **Создание расширенной статистики для корреляции**:
```sql
CREATE STATISTICS corr_stats (dependencies) ON column1, column2 FROM table_name;
ANALYZE table_name;
```
- **Использование `pg_stats` для анализа корреляции**:
```sql
SELECT tablename, attname, correlation
FROM pg_stats
WHERE schemaname = 'public'
ORDER BY abs(correlation) DESC;
```

Если вам нужны конкретные примеры или углублённый разбор, уточните, какой аспект корреляционного анализа вас интересует (планирование запросов, индексы, многомерная статистика и т. д.).


Вывод :
Очередная, иллюстрация - китайская нейросеть вообще ничего не знает о материалах в российском сегменте интернета .

Ну а команде Yandex - очередной заслуженный респект.

P.S. Чтобы еще усугубить и резко обозначить разницу можно задать вопрос " Кто автор методологии корреляционного анализа ожиданий СУБД PostgreSQL ? "
DeepSeek, как обычно несет мусор.
А вот ответ, YandexGPT, вполне по делу:

YandexGPT vs DeepSeek. Китаец в пролёте . В полном Искусственный интеллект, DeepSeek, Яндекс, Нейронные сети, Длиннопост, Postgresql

Дальше - дело техники - простейший поиск по ключевому слову "pg_hazel" и живое общение с автором 😎

Показать полностью 1
[моё] Искусственный интеллект DeepSeek Яндекс Нейронные сети Длиннопост Postgresql
28
kznalp
kznalp
4 месяца назад
Искусственный интеллект
Серия ITшное

Стандартный пример того, как опасно использовать ответы нейронных сетей⁠⁠

Продолжение игр с большими языковыми моделями .

Вопрос : Расскажи мне про использование индикатора CPI при анализе производительности СУБД PostgreSQL

Ответ DeepSeek , не приводится , китаец как обычно , по данной теме, полную пургу несет.
Ответ YandexGPT:

**CPI** (Cycles Per Instruction) в контексте PostgreSQL представляет собой метрику производительности, которая рассчитывается как модуль вектора из трех показателей:

* **QPS** - количество запросов в секунду
* **TPS** - количество транзакций в секунду
* **RPS** - количество строк, полученных клиентом в секунду

Для измерения времени выполнения операций используются данные из системных представлений:
* **active_time** из pg_stat_database
* **total_exec_time** из pg_stat_statements

Дополнительно введены расширенные метрики:
* **CPI_VOLUME** - объем обработанных блоков распределенной памяти при выполнении SQL-операторов
* **CPI_RATIO** - отношение основной метрики производительности к объему обработанных блоков

**CPI_RATIO** особенно важен для оценки эффективности работы СУБД, так как показывает, насколько эффективно система обрабатывает данные - для достижения одинакового результата требуется обработать меньший объем информации.

При проведении анализа производительности рекомендуется следующий подход:
* Выполнить серию тестовых операций (SELECT, INSERT, UPDATE, DELETE)
* Создать необходимые индексы
* Повторить тестовые операции
* Проанализировать полученные результаты

Экспериментально подтверждено, что цифровые показатели CPI полностью коррелируют с наблюдаемым эффектом от создания индексов, что делает эту метрику надежным инструментом для анализа производительности PostgreSQL.

Сразу бросается в глаза полное несоответствие описания и расчёта .

Но самое неприятное не в этом , а в том, что если вдруг кто то из поклонников "искусственного интеллекта" решит сэкономить время (ну это же заявлено как основная выгода ) он потеряет массу времени и соберет по пути все грабли и аномалии , потому что методика расчета, которую привел YandexGPT - неверная , устаревшая и давно неиспользуемая .
Т.е. в данном случае "искусственный интеллект" не помогает, а вредит.

Что делать ? Не доверять чат ботам, включать голову , искать и работать с первоисточниками и материалами самостоятельно .
Лучше с авторами.

Показать полностью
[моё] Искусственный интеллект Нейронные сети Яндекс ИМХО Текст Postgresql
4
0
IliaHohlov
IliaHohlov
4 месяца назад

Задача на оптимизацию SQL запроса⁠⁠

Предлагаю ещё одну задачу по базам данных со своего Телеграм-канала по SQL и базам данных. Итак, среди прочих, имеется таблица выставленных счетов INVOICES:

Задача на оптимизацию SQL запроса Тестирование, IT, Программирование, Собеседование, SQL, База данных, Аналитик, Аналитика, Программист, Postgresql, Postgres, Oracle, Mysql, Telegram (ссылка)

В некотором отчёте АБС количество счетов, выставленных за текущий день формируется SQL запросом:

SELECT COUNT(*) COUNT_INV FROM INVOICES WHERE DATE(DATE_CREATE) = CURRENT_DATE

Задача на оптимизацию SQL запроса Тестирование, IT, Программирование, Собеседование, SQL, База данных, Аналитик, Аналитика, Программист, Postgresql, Postgres, Oracle, Mysql, Telegram (ссылка)
Тестирование IT Программирование Собеседование SQL База данных Аналитик Аналитика Программист Postgresql Postgres Oracle Mysql Telegram (ссылка)
3
kznalp
kznalp
4 месяца назад
Искусственный интеллект
Серия ITшное

Нейросети между собой не дружат и не обмениваются информацией⁠⁠

Продолжение игр с нейросетями.

Вопрос: Какие практические рекомендации по ожиданиям PostgreSQL может дать чат-бот ChatPPG ?


Ответ YandexGPT

Практические рекомендации по работе с ожиданиями в PostgreSQL

Основные типы ожиданий

Lock-based ожидания:

  • LockAcquire - ожидание получения блокировки объекта

  • BufferLock - ожидание блокировки буфера

  • TransactionIdLock - ожидание завершения транзакций

Мониторинг ожиданий

Основные инструменты:

  • pg_stat_activity - просмотр текущих сессий и их состояния

  • pg_locks - мониторинг блокировок в системе

  • pg_stat_statements - анализ производительности запросов

Оптимизация производительности

Рекомендации по настройкам:

  • Настройка max_connections под реальную нагрузку

  • Оптимизация shared_buffers и effective_cache_size

  • Корректная настройка wal_segment_size для снижения IO

Работа с блокировками

Практические советы:

  • Использование SELECT FOR UPDATE только там, где это действительно необходимо

  • Минимизация времени удержания блокировок

  • Применение SERIALIZABLE изоляции только при необходимости

Диагностика проблем

Основные шаги:

  • Анализ pg_stat_statements для выявления медленных запросов

  • Мониторинг pg_stat_database для оценки нагрузки

  • Использование EXPLAIN ANALYZE для анализа планов выполнения

Автоматизация мониторинга

Рекомендуемые практики:

  • Настройка оповещений при превышении пороговых значений ожиданий

  • Регулярный анализ логов системы

  • Автоматическое создание дампов состояния при критических ожиданиях

Профилактические меры

Регулярные действия:

  • Реорганизация таблиц при росте фрагментации

  • Обновление статистики для корректной работы оптимизатора

  • Периодическая очистка устаревших данных

Работа с большими нагрузками

Масштабирование:

  • Разделение нагрузки между узлами (shard-ing)

  • Использование репликации для чтения

  • Кэширование часто используемых данных

Дополнительные рекомендации

Безопасность и стабильность:

  • Регулярное резервное копирование

  • Настройка параметров WAL для оптимальной производительности

  • Мониторинг свободного места на дисках

При возникновении специфических проблем рекомендуется обращаться к документации PostgreSQL и профильным сообществам для получения более детальных рекомендаций под конкретную задачу.


Ответ DeepSeek

Чат-бот ChatPPG (предположительно, это вымышленный бот для PostgreSQL) мог бы дать следующие практические рекомендации по настройке ожиданий (expectations) при работе с PostgreSQL:

1. Производительность

  • Не ожидайте, что PostgreSQL будет так же быстр, как специализированные NoSQL-системы для ключ-значение (например, Redis).

  • Оптимизируйте запросы: Используйте EXPLAIN ANALYZE для анализа плана выполнения.

  • Настройте индексы: Добавляйте индексы на часто используемые столбцы в WHERE, JOIN, ORDER BY.

2. Масштабируемость

  • PostgreSQL хорошо масштабируется вертикально (увеличение CPU/RAM), но горизонтальное масштабирование (шардинг) требует дополнительных инструментов (Citus, PostgreSQL + Foreign Data Wrappers).

  • Ожидайте, что репликация (streaming replication) будет запаздывать на несколько секунд или минут при высокой нагрузке.

  • 3. Надежность и отказоустойчивость

    • WAL (Write-Ahead Log) гарантирует сохранность данных, но требует правильной настройки (fsync, synchronous_commit).

    • Регулярно делайте бэкапы (pg_dump, pg_basebackup, Barman).

    4. Транзакции и блокировки

    • Долгие транзакции блокируют систему – избегайте idle in transaction сессий.

    • Deadlocks (взаимоблокировки) возможны – настраивайте deadlock_timeout и логируйте их.

    5. Расширяемость

    • PostgreSQL поддерживает множество расширений (PostGIS, pg_partman, TimescaleDB).

    • Можно писать хранимые процедуры на Python, JavaScript (PL/V8), Rust (pgx) и др.

    6. Мониторинг и обслуживание

    • Автовакуум (autovacuum) критически важен для производительности – настраивайте autovacuum_vacuum_scale_factor и autovacuum_analyze_threshold.

    • Используйте pg_stat_statements для выявления медленных запросов.

    7. Совместимость и миграции

    PostgreSQL строго следует стандарту SQL, но некоторые функции (например, ON UPDATE) отсутствуют.

  • Миграции с других СУБД (MySQL, Oracle) возможны, но требуют проверки (используйте pgloader, Ora2Pg).

8. Безопасность

  • Не используйте trust в pg_hba.conf – применяйте md5/scram-sha-256.

  • Рекомендуется ограничивать права через ROLE и GRANT.

Вывод

PostgreSQL – мощная, надежная и гибкая СУБД, но требует грамотной настройки и понимания её внутренней работы. Если ChatPPG действительно существовал, он бы советовал читать документацию, тестировать на реалистичных нагрузках и не надеяться на "волшебную" производительность без оптимизаций.


Результат

YandexGPT - садись 2 . На переэкзаменовку. Незнание предметной области, не обладает информацией по вопросу.

DeepSeek - садись 2 . На переэкзаменовку. Незнание предметной области, не обладает информацией по вопросу.

Нейросети между собой не дружат и не обмениваются информацией Яндекс, DeepSeek, Нейронные сети, Чат-бот, Длиннопост, Postgresql

Стыдно, при таких бюджетах не знать простого.

А ведь достаточно всего лишь , воспользоваться шпорой и сделать запрос в поисковик:

Нейросети между собой не дружат и не обмениваются информацией Яндекс, DeepSeek, Нейронные сети, Чат-бот, Длиннопост, Postgresql
Показать полностью 2
[моё] Яндекс DeepSeek Нейронные сети Чат-бот Длиннопост Postgresql
0
kznalp
kznalp
4 месяца назад
Postgres DBA
Серия СУБД PostgreSQL

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr⁠⁠

Взято с основного технического канала Postgres DBA ( возможны правки и дополнения в исходной статье ).

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

У любого события есть причина .

Задача

Определить причину аномальной утилизации CPU и снижения производительности СУБД

Симптомы

Аномальная утилизация CPU сервера СУБД

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Ось X - точка времени. Ось Y - метрика утилизации CPU.

Наблюдаемая проблема

Снижение операционной скорости СУБД

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Ось X - точка времени. Ось Y - операционная скорость СУБД

Корреляционный анализ

Отрицательная корреляция между снижением операционной скорости и ростом ожиданий - отсутствует.

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Ось X - точка времени. Ось Y - ожидания СУБД

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Ось X - точка времени. Ось Y - значение индикатора деградации скорости СУБД

Подробнее об индикаторе

https://dzen.ru/a/Z-FQYUcB3gepNYzA

Отчеты pgpro_pwr

G.3.11.2. Load distribution (Распределение нагрузки)

Этот раздел отчёта pgpro_pwr основан на представлении pgpro_stats_totals расширения pgpro_stats, если оно было доступно в течение отчётного интервала. Каждая таблица в данном разделе предоставляет данные за отчётный интервал о распределении нагрузки для определённого типа объектов, для которых собирается агрегированная статистика, например, баз данных, приложений, узлов или пользователей. Каждая таблица содержит по одной строке для каждого из ресурсов (таких, как общее время или общее число записанных разделяемых блоков), где распределение нагрузки показано на графике в виде линейчатой диаграммы с накоплением для объектов с наибольшей нагрузкой по этому ресурсу. Если область диаграммы, соответствующая объекту, слишком узка для включения заголовков, наведите указатель на эту область, чтобы получить подсказку с заголовком, значением и процентом. Таблицы «Load distribution among heavily loaded databases», «Load distribution among heavily loaded applications», «Load distribution among heavily loaded hosts» и «Load distribution among heavily loaded users» показывают распределение нагрузки для соответствующих объектов.

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Наибольшую нагрузку создает DB-1

Статистика утилизации CPU

G.3.11.4.1. rusage statistics (Статистика использования ресурсов)

Этот раздел добавляется в отчёт, только если в отчётном интервале было доступно расширение pgpro_stats или pg_stat_kcache.

Таблица отчёта «Top SQL by system and user time» показывает запросы с наибольшей суммой значений полей user_time и system_time в представлении pg_stat_kcache или pgpro_stats_totals.

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

SQL запрос с наибольшим потреблением CPU

Наиболее длительные SQL

Таблица отчёта «Top SQL by execution time» показывает запросы с наибольшей длительностью выполнения, определяемой по значению поля total_time представления pgpro_stats_statements или pg_stat_statements.

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

SQL запрос с наибольшей длительностью выполнения

Причина инцидента и проблемный запрос

Определение причины снижения производительности СУБД с использованием pg_hazel и pgpro_pwr Инженер, Субд, Postgresql, Мониторинг, Производительность, Длиннопост

Проблемный запрос

Причина аномальной утилизации CPU и снижения операционной скорости СУБД является массовый вызов хранимой функции, требующей для выполнения высоких вычислительных ресурсов.

Показать полностью 9
[моё] Инженер Субд Postgresql Мониторинг Производительность Длиннопост
2
kznalp
kznalp
4 месяца назад
Postgres DBA
Серия СУБД PostgreSQL

PG_HAZEL : тестирование рекомендаций ChatPPG на сценариях нагрузочного тестирования PostgreSQL⁠⁠

Взято с основного технического канала Postgres DBA ( возможны правки и дополнения в исходной статье ).

PG_HAZEL : тестирование рекомендаций ChatPPG на сценариях нагрузочного тестирования PostgreSQL Тестирование, Инженер, Исследования, Искусственный интеллект, Нейронные сети, Postgresql, Чат-бот

Человек и чат-бот - уже коллеги по работе.

PG_HAZEL : Влияние изменения параметра max_parallel_workers_per_gather на скорость и ожидания СУБД.

Подробности экспериментов

PG_HAZEL : Влияние изменения параметра shared_buffer на скорость и ожидания СУБД.

Подробности экспериментов

Показать полностью
[моё] Тестирование Инженер Исследования Искусственный интеллект Нейронные сети Postgresql Чат-бот
0
kznalp
kznalp
4 месяца назад
Postgres DBA
Серия СУБД PostgreSQL

Гипотеза об ожиданиях СУБД PostgreSQL⁠⁠

Взято с основного технического канала Postgres DBA ( возможны правки и дополнения в исходной статье ).

Гипотеза об ожиданиях СУБД PostgreSQL Исследования, Субд, Postgresql, Производительность, Длиннопост

Время - деньги.

Определение ожидания СУБД

Серверный процесс выполняющий SQL запрос к СУБД, в процессе выполнения находится в основных состояниях:

· active: серверный процесс выполняет запрос.

· idle: серверный процесс ожидает новой команды от клиента.

· idle in transaction: серверный процесс находится внутри транзакции, но в настоящее время не выполняет никакой запрос.

Postgres Pro Enterprise : Документация: 15: 27.2. Система накопительной статистики : Компания Postgres Professional

Если, серверный процесс находится состоянии active, то процесс может находится в либо в состоянии выполнения запроса, либо в состоянии ожидания:

wait_event_type text

Тип события, которого ждёт обслуживающий процесс, если это ожидание имеет место; в противном случае — NULL.

Postgres Pro Enterprise : Документация: 15: 27.2. Система накопительной статистики : Компания Postgres Professional

Вывод

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

Термины и определения:

Операционная скорость

Интегральный показатель, рассчитываемый как сумма общего числа выполненных SQL выражений и общего числа строк, полученных или затронутых операторами за выбранный промежуток времени.

Для сглаживания выбросов используется медианное сглаживание.

Гипотеза об ожиданиях СУБД PostgreSQL Исследования, Субд, Postgresql, Производительность, Длиннопост

Ось X - точка наблюдения. Ось Y - значение операционной скорости.

События ожидания в PostgreSQL

Информация о том, чего процесс базы данных ожидает, когда не выполняются активные запросы.

Гипотеза об ожиданиях СУБД PostgreSQL Исследования, Субд, Postgresql, Производительность, Длиннопост

Ось X - точка наблюдения. Ось Y - общее количество ожиданий за отрезок наблюдения.

Коэффициент корреляции

Коэффициент корреляции в математической статистике — показатель, характеризующий силу статистической связи между двумя или несколькими случайными величинами.

Корреляция между операционной скоростью и ожиданиями

Коэффициент корреляции между значениями операционной скорости и событиями ожидания.

Гипотеза об ожиданиях СУБД PostgreSQL Исследования, Субд, Postgresql, Производительность, Длиннопост

Ось X - значения операционной скорости за период наблюдения. Ось Y - значения ожиданий за период наблюдений.

Корреляция между ожиданиями

Коэффициент корреляции между всеми ожиданиями и событиями ожидания по определенному типу

Гипотеза об ожиданиях СУБД PostgreSQL Исследования, Субд, Postgresql, Производительность, Длиннопост

Ось X - значения ожиданий за период наблюдений. Ось Y - значения ожиданий типа IPC за период наблюдений.

Практический вывод

При постоянном сценарии нагрузки (неизменяемые SQL запросы) и при постоянных конфигурационных параметрах СУБД - коэффициент корреляции между значениями операционной скорости и количеством ожиданий определяет степень влияния событий ожидания на снижение операционной скорости.

При отсутствии влияния инфраструктуры (CPU, сеть), наибольшее влияние на снижение операционной скорости имеет тип ожидания, имеющее наибольшее значение коэффициента корреляции со всеми ожиданиями СУБД.

Следовательно – снизив количество ожиданий данного типа время выполнения SQL запроса уменьшится и количество запросов за отрезок времени увеличится. Т.е. операционная скорость возрастет.

Показать полностью 4
[моё] Исследования Субд Postgresql Производительность Длиннопост
0
7
kznalp
kznalp
4 месяца назад
Postgres DBA
Серия СУБД PostgreSQL

Заметка на память - как не надо завершать процесс в PostgreSQL⁠⁠

Иногда случается ситуация : нужно завершить долгий SQL запрос (кильнуть сессию).

Заметка на память - как не надо завершать процесс в PostgreSQL Субд, Postgresql, Полезное, Опыт, Личный опыт, Длиннопост

Стандартный способ, рекомендованный в документации :
select pg_terminate_backend( pid );


Однако, иногда, если запрос очень долгий , даже после прерывания процесса, pid всё равно еще остается в результате запроса select ... from pg_stat_activity ;


И в этой ситуации может возникнуть соблазн "kill -9 pid"
Чтобы побыстрее ...

Заметка на память - как не надо завершать процесс в PostgreSQL Субд, Postgresql, Полезное, Опыт, Личный опыт, Длиннопост

После выполнения kill , кластер PostgreSQL аварийно перезапустится , со всеми вытекающими последствиями .
Быстрее - не получится .

Нужно просто подождать завершения отката изменений, выполненных в ходе транзакции начатой pid .

Заметка на память - как не надо завершать процесс в PostgreSQL Субд, Postgresql, Полезное, Опыт, Личный опыт, Длиннопост

P.S. Ну и как обычно , мнение ИИ. Страшилка о 'kill -9" от DeepSeek:

После выполнения команды `kill -9` для процесса PostgreSQL, выполняющего долгий запрос, возникают следующие последствия:

### 1. **Прерывание транзакции**
- Транзакция, связанная с убитым процессом, **не будет завершена корректно**. Поскольку `SIGKILL` (сигнал 9) нельзя перехватить или обработать, PostgreSQL не успевает выполнить откат (`ROLLBACK`) транзакции. Это может привести к:
- **Незавершенным изменениям данных**: Если транзакция выполняла модификацию данных (INSERT/UPDATE/DELETE), изменения останутся в состоянии "под вопросом" до восстановления.
- **Блокировкам (locks)**: Ресурсы (строки, таблицы), заблокированные транзакцией, могут остаться занятыми до очистки процесса.

### 2. **Автоматическое восстановление PostgreSQL**
- PostgreSQL обнаруживает аварийное завершение процесса и автоматически выполняет:
- **Очистку блокировок**: Все удерживаемые процессом блокировки освобождаются.
- **Откат транзакции**: Незавершенная транзакция откатывается с помощью механизма восстановления на основе **WAL (Write-Ahead Logging)**. Это гарантирует целостность данных, но может занять время, особенно если транзакция была крупной.

### 3. **Влияние на производительность**
- **Долгое восстановление**: Если убитый процесс работал с большим объемом данных, откат транзакции через WAL может задержать другие операции.
- **Возможные задержки**: Другие сессии, ожидавшие блокировок от убитого процесса, получат доступ к ресурсам только после завершения восстановления.

### 4. **Ошибки в клиентских приложениях**
- Клиент, инициировавший запрос, получит ошибку соединения (например, `connection terminated unexpectedly`). Приложение должно быть готово к таким сценариям (повторные попытки, обработка исключений).

### 5. **Риск для репликации (если используется)**
- В режимах синхронной репликации аварийное завершение процесса может временно нарушить синхронизацию данных между primary и standby-серверами. Однако механизм WAL гарантирует восстановление согласованности.

### 6. **Журналирование (логи)**
- В логах PostgreSQL появится запись об аварийном завершении процесса, например:
```
FATAL: terminating connection due to administrator command
LOG: server process (PID 12345) was terminated by signal 9: Killed
LOG: aborting any active transactions
```

---

### Рекомендации:
1. **Избегайте `kill -9`**, если это возможно. Используйте `pg_cancel_backend()` или `pg_terminate_backend()` для безопасного завершения запросов.
2. Для долгих транзакций настройте `statement_timeout` или `idle_in_transaction_session_timeout`.
3. Мониторьте активные транзакции через `pg_stat_activity`.

**Итог**: `kill -9` не повредит данные благодаря WAL, но может вызвать временные задержки и требует времени на автоматическое восстановление.

Показать полностью 3
[моё] Субд Postgresql Полезное Опыт Личный опыт Длиннопост
2
Посты не найдены
О нас
О Пикабу Контакты Реклама Сообщить об ошибке Сообщить о нарушении законодательства Отзывы и предложения Новости Пикабу Мобильное приложение RSS
Информация
Помощь Кодекс Пикабу Команда Пикабу Конфиденциальность Правила соцсети О рекомендациях О компании
Наши проекты
Блоги Работа Промокоды Игры Курсы
Партнёры
Промокоды Биг Гик Промокоды Lamoda Промокоды Мвидео Промокоды Яндекс Директ Промокоды Отелло Промокоды Aroma Butik Промокоды Яндекс Путешествия Постила Футбол сегодня
На информационном ресурсе Pikabu.ru применяются рекомендательные технологии