Методы Диагностики Postgresql - Владимир Бородин И Ильдус Курбангалиев

Одним из самых популярных докладов на конференции PG Day в 2015 году стал рассказ Владимир Бородин И Ильдуса Курбангалиев о ситуациях, когда пост-гресс базы данных становятся плохими, нужно их диагностировать и искать узкие места.

Все примеры в отчете взяты из реальной практики Яндекса, сопровождаются иллюстрациями и подробным рассказом о поиске «узкого места».

Несмотря на то, что проблемы рассматривались в контексте версий 9.4 и 9.5 базы данных, общая ценность и практическая применимость советов Владимира и Ильдуса остаются неизменными.

Мы рады предложить Вам транскрипцию этот отчет .

Вступительное слово Ильи Космодемьянского.

: сейчас у нас будет история о том, как жить, если очень хочется иметь Oracle, но у тебя его нет. На самом деле это полезный доклад, потому что одна из проблем, которая у нас сейчас есть, — это проблема диагностических средств.

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

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

А сейчас ребята из Яндекса и PG Pro расскажут о том, какие методы диагностики Postgres они используют, как ими пользоваться, и немного расскажут о том, как они собираются улучшить этот мир.

Владимир Бородин : Всем привет. Меня зовут Вова, и я админ почты Яндекса.

Доклад совместный с Ильдусом, он занимается разработкой PostgreSQL в PostgreSQL. Отчет о диагностике Postgres и важный момент в нем – это картинки.

Первая часть отчета посвящена тому, что делать, если у вас не работает мониторинг.

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

Мы считаем, что Postgres — хорошая база данных.

А хорошая база данных, когда все плохо, обычно на что-то натыкается.

В большинстве случаев это какой-то системный ресурс.

Ему не хватает процессора.

Ей не хватает дисков или даже сети.

Он вполне может опираться на тяжеловесные шлюзы, линейные замки, знаки или что-то еще.

Но бывают случаи, когда база натыкается на что-то другое.

Несколько фотографий с того же производства.

Вот, например, htop из одной базы данных Postgres, которая застряла на процессоре.

Нагрузка Средняя 200, много сессий и процессор в пользовательском пространстве, такое бывает.

Основание также можно упереть в диски.

Посгрес — довольно популярная штука.

Переработка на паре дисков близка к 100%.

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

Диск может исчерпать не только количество операций ввода-вывода или пропускную способность, но, к сожалению, он также может исчерпаться по местоположению.

Это изображение базы данных, где закончился раздел xlog.

У нас бывают ситуации, когда база данных зависает в сети для передачи ixlogов на реплики, в архив или еще куда-то для «толстых» ответов клиентам.

В случае с памятью все сложнее.

Как правило, вы не увидите, что у вас проблемы с памятью.

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

Все это довольно хорошо диагностируется внешними по отношению к Postgres инструментами.

То есть ваши любимые топоподобные утилиты, dstat, iostat и т.п.

Я говорю в основном о Linux. Если в базе данных встречаются тяжелые блокировки, эту информацию можно просмотреть через PG-блокировки, и существует ряд запросов, которые облегчают анализ вывода оттуда глазами.

Но они собраны в вики Postgres. Собственно, пример выше всё прекрасно показывает.

Произошел взрыв, вы на что-то наткнулись.

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

До версии 9.4 существовал хороший инструмент pg_stat_statements. Вы можете увидеть, вплоть до запроса, какой из них занимает больше всего времени.

То есть на какие запросы база данных тратит больше всего времени.

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

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

Это время можно потратить на различные ресурсы.

Можно читать с диска, можно принудительно процессор, можно что-то сортировать, можно ожидать какой-то блокировки и так далее.

Начиная с 9.4 появилась замечательная штука под названием pg_stat_kcache, которая позволяет просматривать с точностью до запроса в том числе потребление процессора в пользовательское время и потребление процессора в системное время.

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

Несколько примеров.

Например, запрос, который также отображает информацию по топовым запросам.

Опять же сортировка по времени.

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

Вы можете просмотреть тексты этих запросов.

Сам запрос выглядит так.

Этот текст можно скопировать.

На самом деле это не так уж и сложно.

Здесь все просто.

Берем данные из pg_stat_statements, pg_stat_kcache и сортируем их, в данном конкретном случае, еще и по времени, потраченному БД на этот запрос.

Но это не самое большое преимущество pg_stat_kcache. Вы можете сортировать данные по чтению с диска, записи на диск и т. д. Например, одни и те же операторы pg_stat_statements могут разделять Shared_hit и Shared_read. Это означает чтение из общей памяти (общих буферов) и всего остального.

А все остальное может быть из страничного кэша операционной системы, а может быть физически с диска.

pg_stat_kcache может разделить их.

Это делается с помощью системного вызова getrusage(), который запускается после каждого запроса.

Например, у нас была база данных, которая была ограничена чтением с диска, и мы создали эту штуку: запрос, который сортирует данные по физическому чтению с диска.

И это относительные величины.

Здесь вы можете видеть, что у нас есть запросы, которые находятся в топе.

Для них несколько процентов доходят до диска и читают что-то с диска.

Все остальное обслуживается либо из общей памяти, либо из кэша операционной системы.

То есть кэширование в этой базе данных работало достаточно эффективно.

Если вы используете версию 9.4, обязательно используйте pg_stat_kcache, отличная штука.

Есть более сложные проблемы, которые вообще не определяются конкретными запросами.

Например, это проблема.

Возьмите его и увеличьте дисковый ввод-вывод с помощью первой стрелки.

Описание полей в середине картинки.

Эти два столбца — это iops. Увеличиваем iops с 10 тысяч до 100 тысяч.

И через какое-то время наша база данных начинает убивать весь процессор в системное время.

В этот момент все становится плохо и вообще непонятно, что она делает. А если мы заглянем в pg_stat_statements или pg_stats_kcache, то увидим, что в системное время система проводит почти все запросы.

Это не проблема для какого-либо конкретного запроса.

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

Это совершенно не «насилует» систему.

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

При этом понятно, что, скорее всего, мы делаем спинлокинг для получения облегченных блокировок.

И, скорее всего, в той области, где работает буферный кэш.

Называется PinBuffer, UnpinBuffer, ReadBuffer и так далее.

Глядя на эти выходные данные perf top, вы можете понять, на что процесс тратит системное время, или догадаться, где именно в базе данных он тратит.

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

Здесь должна быть картинка-мем.

Мы можем пойти глубже, посмотреть, что там происходит и с чем мы имеем дело.

Для этого существует ряд инструментов.

Одними из них являются dtrace и systemtap (в случае Linux).

Его преимущество в том, что с его помощью можно смотреть буквально все.

Но для этого нужно написать немного кода.

Это первое.

Во-вторых, вам нужно пересобрать Postgres, чтобы в него мог попасть systemtap. И самая большая проблема в том, что systemtap неприменим ни при каких условиях.

Его можно использовать на стендах нагрузочных испытаний.

Потому что это не всегда работает надежно и может помешать вашему «производству».

Это случалось с нами несколько раз.

В качестве рекламы в «блоге» я написал об отладке ситуации с помощью systemtap.

Другой инструмент — классический отладчик GDB, и мы его используем.

Очень просто, он присоединяется к процессу, удаляет бэктрейс с потоков, в случае с Postgres — один процесс, один поток.

Поэтому мы просто удалим backtrace. И он отсоединяется от процессора.

Вывод выглядит следующим образом.

Оно показывает, что нас ждет легковесная блокировка в области работы с буферным кешем, причем не просто где-то там, а на конкретной строчке исходного кода.

Мы можем перейти к исходному коду в строке 591 файла bufmgr.c и посмотреть, что там происходит. Даже если вы не знаете Си, есть неплохие комментарии и можно понять, где и что происходит.

Единственное, у GDB есть неприятный недостаток.

Если вы присоединитесь к процессу и скажете Ctrl+C , то он не дойдет до процесса СИГТЕРМ или СИГНАЛИЗАЦИЯ , но он полетит СИГКИЛЛ , и Postgres добавит это за вас.

Поэтому мы написали совершенно дурацкую обвязку.

Он просто не отправляет все сигналы, которые вы отправляете по этому жгуту, в GDB. Соответственно, до постгресс-бэкендов он тоже не доходит. Обвязка позволяет нам удалить трассировки стека из пост-гресс-бэкенда, а затем посмотреть на них глазами и понять, что там происходит. Преимущество в том, что работает стабильно и на «бой» не влияет. Вам не нужно ничего перестраивать, чтобы это работало.

Вам просто нужно установить пакеты debuginfo: postgresql-debuginfo, libc-debuginfo, kernel-debuginfo и будет вам счастье.

Важно отметить, что это дает понимание, вплоть до строки кода, где именно бэкенды проводят свое время.

Вторая часть презентации посвящена тому, что делать, если вы не столкнулись с какой-то проблемой производительности, а уверенно воспроизводите ее.

Вы не знаете, как с ней дальше обращаться.

И вам говорят, что вам следует написать в список рассылки и спросить, что делать.

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

Несколько примеров.

Например, у нас была такая ситуация.

Мы стреляли по базе, которая упиралась в процессор.

Вот на второй картинке видно, что желтый — это процессор в пользовательском пространстве, он почти весь съеден.

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

Все было поставлено на карту.

Видимых скачков со стороны операционной системы не было.

В выводе perftop также не было ничего, что бросалось бы в глаза.

Единственное, на что мы обратили внимание на тот момент, это то, что при появлении этого разрыва в выводе появлялись вызовы для работы с джином.

Несмотря на то, что на это тратится очень мало времени.

Но как только происходит сбой, они появляются.

Как только все наладится, они исчезнут. В этой базе данных у нас был один индекс джина.

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

Потом начали разбираться.

Оказалось, что мы не дочитали документацию, как обычно.

Фастапдейт для джина появился в версии 9.4. В большинстве случаев это ускоряет время вставки, но иногда может привести к недетерминированному времени вставки.

Для нас стабильность времени важнее, чем интервал самого этого времени, условно говоря.

Мы отключили fastupdate, все было нормально.

Поэтому первая рекомендация — прежде чем писать в любую рассылку, необходимо прочитать документацию.

Скорее всего, там вы найдете ответ.

Второй пример.

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

Со стороны производительности это выглядело так.

Вверху — Compaction_alloc, а дальше вообще ничего необычного не было.

Классическая картина потребления процессора.

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

Важно, что это начало происходить после обновления до 9.4. В 9.3 этого не произошло.

Ловить это начали потому, что в 9.4 появилась поддержка огромных страниц, а в операционных системах на базе Red Hat прозрачные огромные страницы включены по умолчанию и работают они отвратительно.

На самом деле, мы далеко не первые, кто столкнулся с этой проблемой.

Вот ссылка на тему, где обсуждается эта проблема.

Отключил прозрачные огромные страницы, все начало летать.

Это вторая рекомендация, область как чтение документации не помогло.

Хотя в 95% случаев это поможет. Имеет смысл поискать в Интернете; скорее всего, кто-то кроме вас уже сталкивался с этой проблемой.

Третий пример.

Та же проблема, когда через некоторое время после увеличения дискового ввода-вывода база данных начинает проводить все свое время в системе.

Весь процессор.

И в выводе perf это выглядит как спин-блокировка.

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

Вам даже не нужно обращаться к исходному коду.

Классическая рекомендация в этом случае — сократить общие буферы.

Обычно те, кто начинает работать с Postgres, отсекают всю доступную оперативную память для общих буферов.

Как правило, это заканчивается плохо.

Классическая рекомендация - 25% от общей памяти , но не более 8 ГБ.

На самом деле уменьшение до 8 ГБ решит эту проблему за вас.

Но нам почему-то очень хотелось отключить множество общих буферов.

Мы подошли к источникам и посмотрели, где встречаются эти строки.

Мы увидели, что они касаются блокировок раздела буферного кэша.

В версии 9.5 значение по умолчанию будет 128. В 9.4 всё равно 16. Мы взяли и увеличили.

Это уменьшило количество блокировок.

Кроме того, в 9.5 есть пара патчей, о которых уже говорилось.

Это улучшенная производительность при многих типах нагрузки.

Единственное, эти патчи в основном касаются нагрузки на чтение.

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

Если у вас там много записей, то рано или поздно вы все равно столкнетесь с этой проблемой.

Вики «postgres» собирает идеи, как улучшить эту ситуацию в будущем.

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

Но, похоже, это довольно редко.

Четвертый пример.

Описание проблемы доступно здесь.

Суть примерно следующая: большая таблица размером около миллиарда строк, большой индекс B-дерева (размером 200 ГБ).

Вы говорите этой пластине ВАКУУМ, и в течение 15 минут накат изменений на репликах прекращается.

Мы говорим о потоковой репликации.

И при этом видно, что реплики начинают много читать с диска, с того раздела, где лежат сами данные.

Видно, что процесс запуска, тот самый, что накатывает xlog, съедает много чтения с диска.

В этом случае смотреть на вывод перф топа бесполезно, так как мы всё проводим в IO, а не в процессоре.

В GDB видно, что мы действительно зависаем на чтении с диска.

Это вызов libc. И вы можете увидеть вплоть до строки кода, где мы это делаем.

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

Может быть улучшена.

Ссылка на обсуждение этой проблемы, о путях ее решения.

Закончилось все патчем к Postgres, позволяющим уменьшить лаг реплик.

Не убрать его совсем, а уменьшить.

Здесь на картинке как раз две реплики.

Зелёный - реплика без патча.

Синий — копия с нашивкой.

На графике видно отставание.

А это на графике чтения диска [прим.

ред.: верно].

Объем чтения не увеличивается.

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

Но, если вы не знаете С, как я, например, то для данной конкретной ситуации, когда у нас большой знак, большой B-дерево index и в то же время у вас там мало изменений, в основном только для вставки load, имеет смысл разбить его на разделы и такой проблемы у вас не будет.

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

Мы тоже так думали.

Поэтому я приглашаю сюда Ильдуса, который расскажет нам о светлом будущем, которое нас ждет.

Ильдус Курбангалиев : Всем привет. Меня зовут Ильдус.

Я работаю в Postgres Professional разработчиком.

На данный момент занимаюсь мониторингом.

То есть я делаю патч мониторинга, который позволит мне отслеживать эти ожидания в Postgres. Ожидание — это именно то, что такое Postgres. Это, например, диск, сеть, «защелки», легкие «замки», возникающие внутри, или сами тяжелые «замки».

Эти ожидания делятся на множество подтипов.

Всего может быть 50 легких замков.

Имеется 9 замков.

Сеть – можно читать или писать.

Хранение такое же.

Зачем вам нужен отдельный инструмент мониторинга? Часто второй пункт на самом деле является первым.

Потому что их очень много, и с каждым нужно разбираться отдельно.

Желательно иметь инструмент, который их совмещает. У меня была именно такая задача.

Например, systemtap — хороший инструмент, но его нельзя использовать в продакшене.

Поэтому я разработал pg_stat_wait, который может выполнять профилирование, отслеживание файлов и историю ожидания.

Есть специальный параметр, их можно записать и сохранить, потом прочитать отдельно.

Профилирование считывает количество и время ожидания для каждого ожидания.

Вы можете включить трассировку для отдельных процессов.

Там оказывается PID процесса, имя файла и все ожидания от этого процесса написаны.

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

Я сделал профилирование, чтобы его можно было использовать в производстве.

Здесь я написал требования, которые были поставлены.

То есть патч должен работать онлайн.

Не перегружайте саму базу данных.

Судя по всему, желательно получить точные данные.

А именно время в миллисекундах, количество и главная цель — объединить кучу инструментов в один.

Вот как это выглядит.

Есть возможность профилировщика вызывать отдельную функцию, возвращающую эти данные.

То есть по каждому ожиданию можно увидеть сколько времени прошло, количество.

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

Здесь видно, что основная часть времени здесь уходит на «патчи» и на работу с сетью.

И тут один удар LWLock.

История выглядит следующим образом.

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

И мы видим именно параметры каждого ожидания.

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

И посчитаем саму таблицу, которую мы выгружаем.

Здесь мы начинаем трассировку: вызываем функцию ( PID, файл ) и мы видим этот результат. Здесь написано, когда было начало, а когда все закончилось, можно посчитать время и посмотреть, где делается эта запись.

Немного о реализации.

Изначально в мониторинге был только один параметр.

Это пять типов, и они были собраны методом выборки, и на их основе был составлен профиль.

Это оказалось не очень полезно, поскольку выборка, во-первых, ставит блок в список процессов.

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

Сейчас это сделано немного по-другому.

То есть каждый бэкенд собирает агрегацию внутри себя и время от времени сбрасывает ее в общую память.

Оттуда дается профиль.

Историю собирает желтый коллекционер: он сортирует ProcArray и записывает то, что там происходит сейчас.

Есть Текущий вид отдельный, который может Теги: #Хранение данных #Администрирование сервера #Администрирование баз данных #postgresql #устранение неполадок #perf #производительность #оптимизация #отладка #GDB