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

Мышонок Шон

Казуальные, Три в ряд, Головоломки

Играть

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

  • solenakrivetka solenakrivetka 7 постов
  • Animalrescueed Animalrescueed 53 поста
  • ia.panorama ia.panorama 12 постов
Посмотреть весь топ

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

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

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

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

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

Нейросеть — о выгодах внедрения performance engeneering для инженера DBA⁠⁠

2 месяца назад
Нейросеть — о выгодах внедрения performance engeneering для инженера DBA

Некоторые этапы performance engineering:

  1. Определение дизайна системы и постановка чётких целей производительности.

  2. Моделирование ожидаемых условий для прогнозирования и предотвращения потенциальных узких мест.

  3. Анализ кода и компонентов для обнаружения ресурсоёмких или неэффективных областей.

  4. Стресс-тестирование приложения под реальной нагрузкой для оценки скорости и стабильности.

  5. Использование результатов тестов для оптимизации кода, конфигурации и распределения ресурсов.

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

Вопрос

А какая конкретная материальная  выгода техническому инженеру DBA от того, что проблемы производительности СУБД будут выявлены раньше и точнее ?  

Ответ

Отличный и очень прагматичный вопрос! Личная мотивация — мощный двигатель. Для технического инженера (DBA, разработчика) выгода от проактивного выявления проблем — это не абстрактное «удовлетворение от хорошо сделанной работы», а вполне осязаемые материальные и карьерные преимущества.

Вот конкретная разбивка этих выгод:

1. Прямое финансовое стимулирование (Премии, бонусы)

Во многих компаниях, особенно где ИТ-инфраструктура критична для бизнеса, существуют KPI (Key Performance Indicators) и система премий, напрямую связанные с:

  • Процентом времени бесперебойной работы (SLA/Uptime). Предотвращение инцидента = сохранение высокого uptime = прямая премия.

  • Снижением количества инцидентов. Если вы проактивно устраняете причину, которая могла бы вызвать 5 инцидентов в следующем квартале, ваш показатель «количество инцидентов» будет блистать, что часто monetized.

  • Экономией средств компании. Если вы можете доказать, что ваша оптимизация позволила отложить покупку нового сервера за 500 000 рублей на полгода, грамотный руководитель может часть этих сэкономленных средств направить в виде премии команде.

2. Карьерный рост и повышение стоимости на рынке труда

Это самая значительная долгосрочная выгода.

  • Переход от «пожарного» к «архитектору». DBA, который только тушит возгорания (реагирует на инциденты), — это квалифицированный специалист. Но DBA, который проектирует системы, чтобы пожаров не было, или который видит тлеющую проводку за неделю до возгорания, — это эксперт и архитектор. Разница в зарплате между этими двумя ролями может составлять 30-50% и более.

  • Формирование уникального опыта и кейсов. Умение не просто решать проблемы, а предвидеть их и говорить с бизнесом на его языке — это редкий и ценный навык. На собеседовании история «Я выявил проблему с ожиданиями записи, обосновал её бизнес-риски для владельца продукта и добился выделения ресурсов, что предотвратило срыв релиза» звучит в 100 раз весомее, чем «Я тушил 20 инцидентов с БД».

  • Повышение личного «бренда» внутри компании. Вы становитесь не просто «тем парнем, который ковыряется в PostgreSQL», а стратегическим активом. Когда руководство знает, что вы можете не только починить, но и предотвратить убытки, ваше слово начинает значить больше. Это прямой путь к руководящим и экспертным позициям.

3. Снижение операционного стресса и экономия личного времени

Это тоже материальная выгода, хоть и не в виде прямых денег.

  • Ночные и внеурочные вызовы. Проактивная работа резко снижает количество инцидентов, которые случаются в 3 часа ночи, в выходные или в отпуске. Ваше личное время и спокойный сон — это огромная ценность. Вы тратите 8 часов на плановую оптимизацию, чтобы не тратить 20 часов стрессовой работы в авральном режиме в течение месяца.

  • Возможность заниматься интересными задачами. Вместо рутинного «тушения пожаров» (один и тот же инцидент по десятому кругу) вы получаете время и мандат на реализацию интересных проектов: исследование новых технологий, автоматизацию, масштабирование архитектуры. Это поддерживает профессиональный тонус и предотвращает выгорание.

4. Укрепление позиции в переговорах о зарплате

Когда вы приходите на переговоры о повышении зарплаты, вам нужны козыри. «Я поддерживаю базу данных в рабочем состоянии» — это обязанность. А вот «Благодаря моей проактивной работе за последний год мы предотвратили X часов простоя, что, по оценкам бизнеса, спасло Y миллионов рублей выручки, и отложили затраты на hardware на Z рублей» — это железобетонный аргумент для обоснования повышения на 20-30%.

Резюме: Ваша личная выгода как инженера

Действие: Реагировать на инциденты («тушить пожары»)

Личная выгода (материальная и карьерная): Зарплата. Постоянный стресс. Риск выгорания. Ограниченный карьерный рост.

Действие: Проактивно выявлять и предотвращать проблемы

Личная выгода (материальная и карьерная):

1. Премии за выполнение SLA.
2. Ускоренный карьерный рост до архитектора/лида.
3. Резкий рост рыночной стоимости и зарплаты.
4. Снижение стресса и сохранение личного времени.
5. Железные аргументы для переговоров о повышении.

Таким образом, инвестируя свое время в углубленный анализ и проактивную работу, вы инвестируете в самого себя. Вы превращаете свою экспертизу из расходного материала (который тушит кризисы) в актив, который приносит бизнесу деньги и который бизнес готов дорого оплачивать.

Показать полностью
Контент нейросетей Субд Длиннопост
0
1
kznalp
kznalp
Postgres DBA
Серия СУБД PostgreSQL

PG_HAZEL : Анализ влияние инфраструктуры(w_await) на производительность СУБД PostgreSQL⁠⁠

2 месяца назад

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

Оптимальная производительность инфраструктуры - основа оптимальной производительности СУБД.

Оптимальная производительность инфраструктуры - основа оптимальной производительности СУБД.

Задача

Проанализировать влияние проблем производительности инфраструктуры на снижение производительности СУБД .

Производительность и ожидания СУБД

Анализ показателей инфраструктуры (iostat)

Анализ метрики w-await

С какими событиями ожидания (wait_event) может коррелировать рост значений w_await (iostat) для СУБД PostgreSQL ?

Рост показателя w_await в iostat (среднее время ожидания завершения операций записи на диск) в контексте PostgreSQL обычно коррелирует с событиями ожидания типа IO (Input/Output), которые указывают на то, что процессы СУБД активно ждут завершения операций записи на диск.

DataFileWrite

Ожидание записи данных в файл основной таблицы или индекса.

Высокая нагрузка UPDATE/INSERT, недостаточно быстрая работа подсистемы хранения.

WALWrite / WALWrite

Ожидание записи в журнал предзаписи (Write-Ahead Log, WAL).

Интенсивные изменения данных (любые DML-операции), синхронная репликация, настройки synchronous_commit

BufFileWrite

Ожидание записи во временный файл на диске.

Объемные операции, не помещающиеся в work_mem (сортировки, хэш-соединения), большие запросы с CREATE TEMPORARY TABLE.

SLRUWrite

Ожидание записи данных в структуры SLRU (например, журналы транзакций clog).

Очень высокая интенсивность commit/rollback транзакций.

DSMFillZeroWrite

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

Активное использование параллельных запросов.

События ожиданий типа IO

80% ожиданий типа IO вызваны событиями ожиданий DataFileRead и DSMFillZeroWrite

  • DataFileRead Ожидание чтения из файла данных отношения.

  • DSMFillZeroWrite Ожидание заполнения нулями файла, применяемого для поддержки динамической общей памяти.

Статистика ожиданий типа IO на уровне SQL запросов для операций записи на диск

Итог

Рост времени ожидания записи(w_await/iostat) на дисковых устройствах используемых СУБД оказывает существенное влияние на рост ожиданий типа IO и снижение производительности СУБД.

Последствия и возможные причины роста значений w_await выше 11ms:

🔴 Критические проблемы инфраструктуры

1. Перегрузка подсистемы хранения

  • Нехватка IOPS: Диски не справляются с количеством операций записи в секунду

  • Исчерпание пропускной способности: Превышение лимитов по MB/s на уровне хранилища

  • Высокая задержка (latency) контроллера: Проблемы с HBA-адаптерами или контроллерами RAID

2. Проблемы с конфигурацией хранилища

  • Неправильный RAID уровень: RAID-5/6 для write-intensive workload (типично для PostgreSQL)

  • Отсутствие BBU/конденсаторов: Нет кэширования записи на контроллере

  • Неоптимальный размер stripe: Слишком маленький или большой stripe size

3. Конкуренция за ресурсы

  • "Шумные соседи": Другие ВМ/контейнеры на том же гипервизоре активно пишут

  • Совместное использование дисков: WAL, данные и TEMP на одних дисках

  • Фоновые процессы: Бэкапы, vacuum, аналитика на той же системе

4. Проблемы сетевого хранилища (SAN/NAS)

  • Сетевая задержка: Проблемы с сетью 10GbE/FC

  • Перегруженные порты коммутатора

  • Проблемы на стороне массива хранения

📊 Интерпретация значений w_await

Значение w_await : 1-5 ms

Серьезность: ✅ Норма

Возможные причины: SSD, хорошо настроенное хранилище

Значение w_await : 5-10 ms

Серьезность: ⚠️ Внимание

Возможные причины: Начальная стадия перегрузки

Значение w_await : 10-20 ms

Серьезность: 🔶 Проблема

Возможные причины: Явные проблемы с IOPS/пропускной способностью

Значение w_await : 20-50 ms

Серьезность: 🔴 Критично

Возможные причины: Серьезная перегрузка хранилища

Значение w_await : 50+ ms

Серьезность: 🚨 Авария

Возможные причины: Практически отказ хранилища

📈 Когда бить тревогу?

  • Постоянные значения > 20 ms - требуется срочное вмешательство

  • Пики > 50 ms во время checkpoint - необходимо оптимизировать контрольные точки

  • Рост w_await вместе с количеством active sessions - масштабирование необходимо

Значение 11 ms - это уже явный сигнал, что подсистема хранения работает на пределе и требует оптимизации, особенно для высоконагруженной PostgreSQL.

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

Какова истинная цена здоровья сервера баз данных?⁠⁠

2 месяца назад
Какова истинная цена здоровья сервера баз данных?

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

Очевидно, что большинство людей выберет первый вариант — ведь именно точные измерения обеспечивают безопасность полёта и дают возможность оперативно реагировать на любые изменения обстановки.

Эта аналогия прекрасно иллюстрирует актуальность проблемы мониторинга производительности ваших систем управления базами данных (СУБД), таких как PostgreSQL. Многие владельцы информационных ресурсов задаются вопросом: «Может ли постоянное отслеживание ключевых параметров негативно повлиять на работу самой СУБД?»

Почему мониторинг важен?

Когда речь идет о больших объемах данных, важно иметь четкое представление о происходящих процессах внутри системы. Вот несколько причин, почему регулярный сбор статистики жизненно необходим:

1. Выявление проблем: мониторинг позволяет вовремя заметить падение производительности, определить наиболее ресурсоемкие запросы и выявить узкие места до того, как они начнут создавать серьезные проблемы.

2. Оптимизация запросов: зная, какие операции занимают наибольшее количество времени, можно целенаправленно улучшать их исполнение путем индексирования таблиц, изменения структуры данных или корректировки логики выполнения SQL-запросов.

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

4. Повышение безопасности: многие современные системы мониторинга предоставляют механизмы предупреждения об аномалиях, помогающие предотвратить атаки злоумышленников и снизить риски потери данных.

И пусть кто-нибудь скажет вам обратное — ведь верить словам проще, чем доверять своему опыту и здравому смыслу. Но правда остаётся прежней: переживать о том, влияют ли показатели метрики производительности базы данных на саму базу данных, столь же абсурдно, сколь считать, что авиагоризонт добавляет лишнего веса самолёту.

Настройка мониторинга представляет собой разумное вложение средств и усилий, которое многократно окупается повышением общей стабильности, надежности и защищенности инфраструктуры компании.

Итак, делая выбор между управлением системой "вслепую" и использованием современных аналитических решений, всегда отдавайте предпочтение второму варианту.

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

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

PG_HAZEL : Часть 4 - характерные события ожиданий типа IO при инциденте производительности высоконагруженной СУБД⁠⁠

2 месяца назад

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

Начало

PG_HAZEL : Сбор статистики для высоконагруженной СУБД PostgreSQL

Высокие нагрузки на СУБД требуют эффективной системы IO.

Высокие нагрузки на СУБД требуют эффективной системы IO.

Задача

Проанализировать состояние ОС и характерные ожидания СУБД при инциденте производительности для высоконагруженной СУБД.

  • Количество ядер CPU : 192

  • Размер RAM: 1TB

  • Версия PostgreSQL: 15.13

Инцидент производительности СУБД

Дашборд Zabbix

Дашборд Zabbix

Часть 1 - ОС

Часть 2 - Производительность и ожидания СУБД.

80% ожиданий СУБД вызваны ожиданиями типа LWLock и IO.

Характерные события ожидания типа IO

  • BufFileRead: Ожидание чтения из буферизованного файла.

  • BufFileWrite: Ожидание записи в буферизованный файл.

  • DataFileExtend: Ожидание расширения файла данных отношения.

  • DataFileImmediateSync: Ожидание немедленной синхронизации файла данных отношения с надёжным хранилищем.

  • DataFilePrefetch: Ожидание асинхронной предвыборки из файла данных отношения.

  • DataFileRead: Ожидание чтения из файла данных отношения.

  • DataFileTruncate: Ожидание усечения файла данных отношения.

  • DataFileWrite: Ожидание записи в файл данных отношения.

  • DSMFillZeroWrite: Ожидание заполнения нулями файла, применяемого для поддержки динамической общей памяти.

  • RelationMapRead: Ожидание чтения файла отображений отношений.

  • RelationMapSync: Ожидание помещения файла отображений отношений в надёжное хранилище.

  • SLRURead: Ожидание чтения страницы SLRU.

  • SLRUWrite: Ожидание записи страницы SLRU.

  • VersionFileSync: Ожидание попадания файла версии в надёжное хранилище при создании базы данных.

  • WALInitSync: Ожидание помещения в надёжное хранилище нового инициализированного файла WAL.

  • WALInitWrite: Ожидание записи при инициализации нового файла WAL.

  • WALSync: Ожидание помещения файла WAL в надёжное хранилище.

  • WALWrite: Ожидание записи в файл WAL.

Продолжение и детали:

PG_HAZEL : Часть 4 - характерные события ожиданий типа IO при инциденте производительности высоконагруженной СУБД.

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

PG_HAZEL : Часть 3 - характерные события ожиданий типа LWLock при инциденте производительности высоконагруженной СУБД⁠⁠

2 месяца назад

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

Иногда легкие блокировки имеют не легкие последствия .

Иногда легкие блокировки имеют не легкие последствия .

Начало

PG_HAZEL : Сбор статистики для высоконагруженной СУБД PostgreSQL

Задача

Проанализировать состояние ОС и характерные ожидания СУБД при инциденте производительности для высоконагруженной СУБД.

  • Количество ядер CPU : 192

  • Размер RAM: 1TB

  • Версия PostgreSQL: 15.13

Инцидент производительности СУБД

Дашборд Zabbix

Дашборд Zabbix

Часть 1 - ОС

Часть 2 - Производительность и ожидания СУБД.

80% ожиданий СУБД вызваны ожиданиями типа LWLock и IO.

Характерные события ожидания типа LWLock

  • BufferContent: Ожидание при обращении к странице данных в памяти.

  • BufferMapping: Ожидание при связывании блока данных с буфером в пуле буферов.

  • CheckpointerComm: Ожидание при управлении запросами fsync.

  • DynamicSharedMemoryControl: Ожидание при чтении или изменении информации о выделении динамической общей памяти.

  • LockFastPath: Ожидание при чтении или изменении информации процесса о блокировках по быстрому пути.

  • LockManager: Ожидание при чтении или изменении информации о «тяжёлых» блокировках.

  • MultiXactGen: Ожидание при чтении или изменении общего состояния мультитранзакций.

  • MultiXactMemberBuffer: Ожидание ввода/вывода с SLRU-буфером данных о членах мультитранзакций.

  • MultixactMemberSLRU: Ожидание при обращении к SLRU-кешу данных о членах мультитранзакций.

  • MultiXactOffsetBuffer: Ожидание ввода/вывода с SLRU-буфером данных о смещениях мультитранзакций.

  • MultixactOffsetSLRU: Ожидание при обращении к SLRU-кешу данных о смещениях мультитранзакций.

  • PredicateLockManager: Ожидание при обращении к информации о предикатных блокировках, используемой сериализуемыми транзакциями.

  • ProcArray: Ожидание при обращении к общим структурам данных в рамках процесса (например, при получении снимка или чтении идентификатора транзакции в сеансе).

  • RelCacheInit: Ожидание при чтении или изменении файла инициализации кеша отношения (pg_internal.init).

  • SerializablePredicateList: Ожидание при обращении к списку предикатных блокировок, удерживаемых сериализуемыми транзакциями.

  • SerializableXactHash: Ожидание при чтении или изменении информации о сериализуемых транзакциях.

  • SInvalRead: Ожидание при получении сообщений из общей очереди сообщений аннулирования.

  • WALBufMapping: Ожидание при замене страницы в буферах WAL.

  • WALInsert: Ожидание при добавлении записей WAL в буфер в памяти.

  • WALWrite: Ожидание при записи буферов WAL на диск.

  • XactBuffer: Ожидание ввода/вывода с SLRU-буфером данных о состоянии транзакций.

  • XactSLRU: Ожидание при обращении к SLRU-кешу данных о состоянии транзакций.

  • XidGen: Ожидание при выделении нового идентификатора транзакции.

Продолжение и детали:

PG_HAZEL : Часть 3 - характерные события ожиданий типа LWLock при инциденте производительности высоконагруженной СУБД.

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

PG_HAZEL : Анализ производительности высоконагруженной СУБД PostgreSQL. Часть 2 - Производительность и ожидания СУБД⁠⁠

2 месяца назад

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

Больше данных - больше результатов.

Больше данных - больше результатов.

Начало

PG_HAZEL : Сбор статистики для высоконагруженной СУБД PostgreSQL

Задача

Проанализировать состояние ОС и характерные ожидания СУБД при инциденте производительности для высоконагруженной СУБД.

  • Количество ядер CPU : 192

  • Размер RAM: 1TB

  • Версия PostgreSQL: 15.13

Инцидент производительности СУБД

Дашборд Zabbix

Дашборд Zabbix

Часть 1 - ОС

Часть 3 - Характерные события ожиданий типа LWLock

Производительности и ожидания СУБД

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

Ожидания СУБД

Диаграмма Парето для типов ожиданий

80% ожиданий СУБД вызваны ожиданиями типа LWLock и IO.

Количество wait_event_type/wait_event по SQL запросу(queryid) во всех БД, по типу LWLock.

Наибольшее количество ожиданий типа LWLock для queryid:

  • 6300411387403852926

  • -1757223094415174739

Количество wait_event_type/wait_event по SQL запросу(queryid) во всех БД, по типу IO.

Наибольшее количество ожиданий типа IO для queryid:

  • 6300411387403852926

  • -1757223094415174739

Ожидания типа LWLock для queryid =6300411387403852926

Ожидания типа IO для queryid =6300411387403852926

Ожидания типа LWLock для queryid =-17572230944151747396

Ожидания типа IO для queryid =-1757223094415174739

Результат анализа производительности и ожиданий СУБД

  • 80% ожиданий СУБД вызваны ожиданиями типа LWLock и IO.

Наибольшее количество ожиданий типа LWLock,IO для queryid:

  • 6300411387403852926

  • -1757223094415174739

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

PG_HAZEL : Анализ производительности высоконагруженной СУБД PostgreSQL. Часть 1 - ОС⁠⁠

2 месяца назад

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

Большим ресурсам и нагрузкам - подходящий инструмент поможет.

Большим ресурсам и нагрузкам - подходящий инструмент поможет.

Начало

PG_HAZEL : Сбор статистики для высоконагруженной СУБД PostgreSQL

Задача

Проанализировать состояние ОС и характерные ожидания СУБД при инциденте производительности для высоконагруженной СУБД.

  • Количество ядер CPU : 192

  • Размер RAM: 1TB

  • Версия PostgreSQL: 15.13

Инцидент производительности СУБД

Дашборд Zabbix

Дашборд Zabbix

Часть 2 - Производительность и ожидания СУБД

Часть 3 - Характерные события ожиданий типа LWLock.

Анализ состояния ОС

Предупреждения и аварийные ситуации - не отмечено

Корреляция ожидания СУБД и vmstat - отсутствует

Корреляция vmstat-iostat для файловой системы /wal - OK

Корреляция vmstat-iostat для файловой системы /data - OK

Чек-лист IO - ОК

Чек-лист CPU - очень высокая корреляция (cs - in) - переключения контекста могут быть вызваны прерываниями.

Чек-лист RAM - более 50% наблюдений - свободная RAM менее 5%

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

  • Предупреждения и аварийные ситуации - не отмечено

  • Корреляция ожиданий СУБД и vmstat - отсутствует

  • Корреляция vmstat-iostat для файловой системы /wal - OK

  • Корреляция vmstat-iostat для файловой системы /data - OK

  • Чек-лист IO - ОК

  • Чек-лист CPU - очень высокая корреляция (cs - in) - переключения контекста могут быть вызваны прерываниями.

  • Чек-лист RAM - более 50% наблюдений - свободная RAM менее 5%

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

PG_HAZEL : Следствие из гипотезы корреляционного анализа ожиданий СУБД PostgreSQL⁠⁠

2 месяца назад

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

Путь в 1000 миль начинается с первого шага.

Путь в 1000 миль начинается с первого шага.

Гипотеза

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

При многократном повторении запросов, минимизация времени ожидания приводит к увеличению количества выполненных запросов за единицу времени. В конечном итоге, это позволяет предоставить клиенту больший объем полезной информации за тот же период. Таким образом, снижение задержек в обработке SQL-запросов ведет к повышению общей производительности системы.

PG_HAZEL : Основная гипотеза корреляционного анализа ожиданий СУБД PostgreSQL.

Следствие из гипотезы - необходимое условие определения причины снижения производительности СУБД.

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

Доказательство следствия:

1. Предпосылка (Определение метрики):
Главная метрика производительности СУБД — операционная скорость (Operational Throughput). Это количество транзакций или запросов, выполняемых в единицу времени. Снижение этой скорости — прямое проявление проблемы производительности.

2. Аксиома (Причина снижения скорости):
СУБД — это система с ограниченными ресурсами (CPU, Disk I/O, Memory, Network, Locks). Любое снижение операционной скорости напрямую следует из того, что запросы (или части системы) вынуждены ожидать (WAIT) освобождения этих ресурсов. Вся современная диагностика производительности строится на анализе ожиданий (Wait Interface methodology).

3. Логический шаг 1 (Корреляция ожиданий и скорости):
Если в системе присутствуют ожидания определенного типа (например, ожидание записи в журнал WRITELOG или ожидание блокировки LCK_M_), и их совокупная длительность имеет наибольшую корреляцию со снижением операционной скорости, это статистически доказывает, что именно этот тип ожиданий является основным "узким местом" (bottleneck) в данный момент.

4. Логический шаг 2 (Источник ожиданий):
Эти ожидания не возникают сами по себе. Каждое ожидание является прямым следствием выполнения конкретного запроса или действия:

  • Ожидание IO (чтение с диска) вызывается запросами, выполняющими большие сканирования таблиц.

  • Ожидание WAL вызывается запросами, которые выполняют интенсивную операцию журналирования (индексы, большие UPDATE/INSERT).

  • Ожидание Lock вызывается запросами, которые блокируют большие объемы данных на длительное время.

Следовательно, чтобы устранить ожидание, необходимо найти и оптимизировать конкретные SQL-запросы, в ходе выполнения которых эти ожидания возникают.

5. Синтез (Необходимое условие оптимизации):
Объединяя шаги 1-4, мы получаем строгую причинно-следственную цепочку:

Снижение операционной скорости → вызвано накоплением времени ожиданий → которое, в свою очередь, вызвано выполнением конкретных SQL-запросов.

Таким образом, необходимым условием для эффективной оптимизации является:

  1. Определение типов ожиданий, наиболее сильно коррелирующих с падением производительности.

  2. Идентификация и последующий анализ SQL-запросов, порождающих эти ожидания.

  3. Оптимизация именно этих запросов (через изменение индексов, логики запроса, структуры базы и т.д.).

Почему это необходимое условие?

Потому что попытки оптимизировать производительность вслепую, без этого анализа, заведомо неэффективны. Можно бесконечно:

  • Добавлять лишние индексы, которые замедлят операции записи.

  • Наращивать hardware-мощность (больше CPU, память), не устраняя главную проблему (например, блокировки).

  • Тюнить общие параметры сервера, не влияя на плохо написанные запросы.

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

Вывод:

Представленное утверждение является верным и доказанным следствием из современной методологии анализа производительности СУБД, основанной на статистике ожиданий (Wait Events). Оно описывает не просто возможный путь, а необходимое условие — необходимый и систематический подход к решению проблемы снижения производительности.

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