При устранении неполадок в RDBM разработчик обычно подозревает медленные запросы.
А что, если это не они? О том, какие типы запросов создают нагрузку на базу данных, не давая вашему приложению работать корректно, администратор базы данных Data Egret Андрей Сальников рассказал в своем докладе на конференции Saint HighLoad++ Online 2020. Он рассказал, как бэкенд-разработчик может идентифицировать такие запросы и какой инструмент лучше для этого использовать.
Эти знания будут особенно полезны, если вам нужно найти проблемы в работающей системе здесь и сейчас, когда каждая минута на счету, а работа приложения с базой данных идет медленно.
До момента всеобщей изоляции Data Egret поддерживала сервис, на котором основная база данных проводила около 50 тысяч транзакций в секунду.
Когда наступила изоляция и онлайн-сервисы стали особенно популярны, компания достигла потолка процессорной мощности этой базы данных, после чего решила перейти на новое оборудование.
Количество транзакций, обрабатываемых базой данных после переезда, подскочило выше 100 тысяч в секунду, и это только на Мастер-Сервере.
Что было сделано
- Перенос базы данных и приложений на более мощные серверы с большим количеством процессоров и памяти;
- Увеличение количества заявок, поскольку есть необходимость обслуживать более мощную онлайн-нагрузку.
Но удвоение транзакций выглядело подозрительно.
Дело в том, что нагрузка на чтение базы данных распределяется между несколькими, поэтому нагрузка на запись, характерная для базы данных Мастер-Сервера, растет слабо при большом увеличении онлайн-активности на сервисе.
В этой статье речь пойдет о причине увеличения транзакций и о том, какую проблему обнаружили специалисты Data Egret после переноса базы данных.
В первую очередь компания обратилась к данным мониторинга:
- Среднее время выполнения запроса уменьшилось на 10 мс по сравнению с предыдущим оборудованием и предыдущей рабочей нагрузкой;
- Сетевой трафик практически не изменился;
- Количество запросов увеличилось.
Использование ресурсов трудно оценить, поскольку поменялось оборудование, и трудно дать однозначную оценку, больше или меньше ресурсов используется в такой ситуации;
- Оценить изменение параметров сервера не удалось.
Но проблема осталась нерешенной.
Поскольку мы говорим о базе данных, необходимо было посмотреть, что изменилось с профилем нагрузки на базу данных, и что произошло с запросами.
Мониторинг не дал результатов.
Но есть и другие инструменты.
Например, пг_ стат_ заявления.
В Data Egret этот инструмент используется постоянно, так как у него есть три приятных бонуса:
- Исторические отчеты обновляются каждый день;
- стр_ статистика _statements регистрирует абсолютно всё, включая частые запросы.
В отличие от pgBadger, который зависит от настроек;
- Вы можете оценить влияние запросов на ресурсы сервера и соответственно на базу данных, поскольку база данных использует ресурсы сервера (дисковую память и процессорное время).
Есть общая нагрузка по количеству запросов, поступивших в базу данных за день.
Вот общее количество запросов: 3,555,539,206 (уникальные: 2268).
Существует специальная позиция Other, в которую группируются запросы, не дающие значительной нагрузки на базу данных: вызовы: 1,977,858,485 (43,42%) avg_time: 0,06 мс (IO: 33,3%).
В отчете присутствуют запросы, создающие значительную нагрузку на базу данных, и запросы, несравнимо малые по сравнению с остальными.
Последних почти 2 миллиарда.
То есть более половины запросов не дают существенной нагрузки.
Эта фотография была до начала режима самоизоляции.
Все остальные запросы в отчете выглядят примерно так: ВЫБЕРИТЕ поле1, поле2 ИЗ таблицы1 ГДЕ поле3 = ? и поле4 между? и ? Они просты: какая-то выборка по простым условиям, иногда 1-2 объединения — ничего сверхъестественного, что могло бы навредить базе данных и требует нашего расследования.
После роста онлайн отчет изменился: 
Что изменилось с начала самоизоляции?
- Время запроса сократилось
В отчетах показано общее время, в течение которого база данных потратила больше ресурсов на выполнение запросов.
В старом на это ушло 90 часов, в новом - 60. Получается, что база данных стала тратить меньше времени на запросы.
Вы можете использовать этот рисунок в качестве руководства.
Понятно, почему стало лучше: поменялся сервер, стало больше памяти и меньше обращений к диску.
- Количество запросов увеличилось
Общее количество запросов, поступивших в базу данных, значительно возросло (примерно в 1,5 раза).
Это можно увидеть на графиках.
- Отсутствие пропорций
Казалось бы, запросов должно быть 3 миллиарда, но на самом деле прирост составляет всего несколько процентов.
Это значит, что что-то изменилось в нагрузке на базу данных, и вам нужно смотреть отчет дальше.
Давайте посмотрим глубже
Просматривая отчет, мы прокрутили вниз до позиции 17 и увидели запрос, который был вызван 1,5 миллиарда раз и выглядел как SELECT 1:
По сути, это пинг подключения к базе данных, который отправляется до того, как приложение или пул отправит туда запрос.
Казалось бы, запрос почти не тратит ресурсов, лишь немного процессорного времени.
Но на самом деле он может сыграть плохую роль.
Во время этого пинга мы берем соединение из базы данных и не отправляем туда полезную информацию, которая может служить нашему бэкенду (например, небольшой образец, рендеринг веб-формы и т. д.).
В результате SELECT 1, являясь стандартным пингом соединения, в то же время приводит к отрицательным результатам.
Ведь на момент этого пинга мы:
- Мы теряем возможность использовать эту связь для действительно полезного запроса;
- Создаём дополнительную нагрузку на CPU (ресурсы сервера базы данных);
- У нас есть дополнительная нагрузка на сеть, поскольку нам нужно связаться между серверной частью приложения и базой данных, чтобы узнать, что произошло и доступна ли база данных.
Это глупая трата ресурсов.
После правок
Посмотрим на график количества транзакций после внесения изменений в ORM:
Выглядит не очень впечатляюще.
Подумайте только, транзакций стало на 20 тысяч меньше! Но с точки зрения процессорного времени на вышибалах после выхода патча дела пошли намного лучше.
Также можно отслеживать результат по общей загрузке: 
До 4 апреля приложение имело непропатченную ORM. После этого пика в 100 тысяч транзакций больше не было.
База данных выделяется только для полезных запросов, которые необходимо выполнить.
Какая здесь мораль? Плохой запрос не всегда выглядит так, и негативный эффект в виде увеличения нагрузки на диск, процессор или сетевую систему может быть виден не сразу.
Однако оно есть.
На стороне приложения это может привести к тому, что приложение не сможет отправлять необходимые запросы.
Приложение ждет, пока не пройдут все пинги.
Особенно, если у вас повышенная нагрузка, и она идет волнами.
Сначала была волна пингов, потом вы запустили обычный запрос.
SELECT 1 — реальный случай.
На его месте могут быть более простые запросы.
Например, в ситуации, когда вам нужно прочитать справочники, чтобы нарисовать веб-форму.
Несмотря на то, что они предоставляют полезную информацию, она никогда не меняется.
Желательно кэшировать его на внутренней стороне, а не обращаться за ним к базе данных.
Маленькие запросы могут принести большие проблемы, которые могут быть не сразу заметны.
Мы говорили о быстрых запросах.
Теперь перейдем к мертвецам.
Живые и мертвые
В какой-то момент сервер базы данных внезапно начал использовать много процессорного времени.
Этот вариант более тривиален с точки зрения расследования — далеко копать не надо: 
План действий тот же:
- Изучаем мониторинг;
- Смотрим статистику в pg_ стат_ заявления;
- Исправляем;
- Рассказываем об обнаруженной проблеме разработчикам.
В верхнем положении дается самая большая нагрузка.
Исключение составляют другие, где вся оставшаяся нагрузка, не топовая, аккумулируется.
Он может находиться в любой позиции отчета.
Сразу видим поз:1 общее время: 02:05:26 (20,3%, Процессор: 38,6% , ИО: 2,0%).
На этот запрос база данных тратит 38% процессорного времени.
Допустим, мы с определенной периодичностью ищем в платежной системе последние транзакции, созданные для каждого платежного сервиса отдельно: выбрать отдельный на (платеж система), * из порядка транзакций по созданным по убыванию; В этой ситуации запрос виден сразу, и вам не придется листать отчет, как в предыдущем примере.
Обычно проблема в простых запросах, которые не вызывают подозрений и могут быть переданы в продакшн ответственным лицом во время проверки кода.
Исправление будет выглядеть так: 
Из маленького запроса, занимающего 1 с, получаем большой запрос, занимающий 2 мс.
Идем в комнату разработчиков и просим их переписать запрос.
Мы разворачиваемся, и ситуация возвращается в норму.
Сообщить о странице_ статистика _statements позволяет нам быстро находить запросы, которые портят нам жизнь.
Инструменты
Давайте рассмотрим плюсы и минусы инструментов, с помощью которых мы можем значительно облегчить себе жизнь.
pgBadger
Плюсы:- Полная информация обо всех запросах;
- Красивые картинки.
Минусы:
- Специальный конфиг для логов;
- Дополнительная нагрузка на диски, поскольку резко увеличивается количество записываемых логов;
- Анализ запросов постфактум;
- pgBadger требует много места.
pg_stat_statements
Плюсы:- Стандартное расширение PostgreSQL, поставляется сразу из коробки;
Вам просто нужно установить его в PostgreSQL, дополнительно подключив загрузку библиотеки pg_ стат_ заявления.
- Собирает информацию по всем запросам;
- Группирует одинаковые запросы;
- Вы можете сбросить статистику;
- Вы можете сделать свой собственный отчет на основе pg_ стат_ заявления.
- Накладные расходы на выполнение запроса 2-5%;
- Запросы анонимны;
- Несущественные запросы отбрасываются;
- Практически нет систем мониторинга, способных с ним работать;
- Не видит разницы между SELECT. и SELECT. FOR UPDATE;
- В необработанном виде данные трудны для понимания.
Такие картинки можно собирать по всем запросам, которые записаны в pg_ стат_ операторов, а затем со временем посмотреть, сколько времени тратится на выполнение того или иного запроса, какие ресурсы он потребляет и как часто он вызывается.
Типичные проблемы
С какими проблемными запросами можно столкнуться на практике? Давайте рассмотрим самые распространенные из них.
- Результат запроса нигде не используется;
Они крутятся, ходят в базу данных, периодически запрашивают данные по своим алгоритмам, но ничего с ними не делают. Отключив этот бэкенд, мы уменьшим нагрузку на базу данных.
- Неоптимально выполняющийся запрос;
- Постоянное обращение к справочникам;
- Отсутствие индексов для простых запросов;
Это можно увидеть в отчете и исправить.
- Смешивание рабочих нагрузок OLTP и OLAP на репликах.
Последнему может быть сложно объяснить, что нагрузка OLAP не может быть актуальной на реплике, отстающей, скажем, на 2 секунды.
Потому что если отчет выполняется 2 часа, то информация в нем устарела уже на 2 часа.
Соответственно, когда одного сервера недостаточно, нагрузку OLTP и OLAP необходимо разделить между разными серверами.
Длинные отчеты начинают тормозить воспроизведение валов на реплике, из-за чего она отстает от мастера.
Если мы включим hot_standby_feedback, реплика больше не будет лагать.
Но тем самым мы нагрузим внутренние механизмы базы данных и получим удар по производительности на всех серверах баз данных, пытаясь совместить нагрузку OLAP + OLTP на сервере-реплике с включенным hot_standby_feedback. Не путайте причины проблем с запросами и длительными транзакциями базы данных.
Когда к нам приходит разработчик и говорит, что его запросы медленные, это не всегда так.
Часто речь идет о проблеме на стороне приложения: например, оно открывает длинные транзакции в базе данных.
Выглядит это так: есть долго выполняющиеся транзакции, которые длятся 30-40 минут, и в то же время есть миллисекундные всплески запросов.
Если мы посмотрим на статус соединения в базе данных в это время, то увидим множество простаивающих соединений (они отмечены желтым цветом): 
простоя в транзакции — это соединение, когда приложение открыло транзакцию в базе данных, выполнило один запрос и занялось своими делами, забыв закрыть транзакцию.
По сути, это основная причина многих проблем.
Как только она будет решена, вы сможете делать то, с чего началась статья: искать запросы, которые мешают вам жить.
Вместо заключения
Основная цель этой статьи — дать читателям понять, что мониторинг и анализ всех запросов — важная часть работы с базой данных.Правильно настроив мониторинг и проведя качественную аналитику, вы сможете добиться хороших результатов для конечной работы сервиса.
Но не забывайте об основных метриках, загрузке процессора, диска и сети, а также правильных настройках базы данных.
Все это вместе даст возможность вашему проекту без технических проблем работать с базой данных, а вы сможете сосредоточиться исключительно на ее развитии.
Конференция HighLoad++ 2020 пройдет 20 и 21 мая 2021 года.Теги: #базы данных #Администрирование баз данных #postgresql #highload #запросы #rdbmsКупить билеты ты можешь сделать это сейчас.
Хотите получить бесплатные материалы с мини-конференции Saint HighLoad++ 2020? Подписаться в нашу рассылку.
И мы приветствуем тех, кто интересуется миром Java на онлайн-встреча Luxoft TechFest #2: Java с Ontico. Поговорим о приватных константных полях в Jira, неочевидных нюансах Java Reactive Stack и работе с распределенным кешем.
А после выступлений звезды митапа ответят на ваши самые актуальные вопросы.
До встречи 10 февраля в 19:00 по мск.
-
Введение В Хранилище Данных
19 Oct, 24 -
Что Такое Srt-Macgo Srt Player
19 Oct, 24 -
Худший Интерфейс Управления Громкостью
19 Oct, 24 -
Британские Ученые Обеспокоены Брекзитом
19 Oct, 24 -
Библиотека Шпаргалок Для Разработчиков
19 Oct, 24
