Интеграция метрик производительности запросов на основе perf events в ClickHouse

Размещено на http://www.allbest.ru/

ПРАВИТЕЛЬСТВО РОССИЙСКОЙ ФЕДЕРАЦИИ

ФЕДЕРАЛЬНОЕ ГОСУДАРСТВЕННОЕ АВТОНОМНОЕ

ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ ВЫСШЕГО ОБРАЗОВАНИЯ

НАЦИОНАЛЬНЫЙ ИССЛЕДОВАТЕЛЬСКИЙ УНИВЕРСИТЕТ

«ВЫСШАЯ ШКОЛА ЭКОНОМИКИ»

Факультет компьютерных наук

Образовательная программа «Программная инженерия»

Выпускная квалификационная работа

На тему Интеграция метрик производительности запросов на основе perf events в ClickHouse

А.Д. Брейман

Москва 2020



Содержание

Определения, обозначения и сокращения

Введение

1. Обзор источников

1.1 RUsage

1.2 Perf Events

1.3 PAPI

1.4 Intel PCM

1.5 AMD мProf

1.6 Постановка задач для разработки

2. Предлагаемые решения

2.1 Выбранная технология и алгоритм работы

2.2 Используемые методы

3. Технологический раздел

3.1 Требования к выполняемым функциям

3.2 Средства и инструменты разработки

3.3 Особенности реализации

3.4 Описание классов

3.5 Диаграмма классов

3.6 Примеры тестирования

Заключение

Аннотация



Определения, обозначения и сокращения

ПО - программное обеспечение.

СУБД - система управления базами данных.

ОС - операционная система.

Метрика - вычисляемая величина, характеризующая какое-либо явление.

Репозиторий, хранилище - место, где хранятся и поддерживаются какие-либо данные.

Pull request - запрос к управляющему каким-либо репозиторием (человеку, группе людей или вообще роботу) на применение изменений (из вашего репозитория и/или указанной вами ветки).

Ревью - анализ, разбор, некоторая оценка программного кода.

Парсинг - принятое в информатике определение синтаксического анализа - процесс сопоставления линейной последовательности лексем естественного или формального языка с его формальной грамматикой.



Введение

Интеграция метрик производительности в базу данных - обычная практика для разработчиков баз данных. Используя встроенные метрики, конечные пользователи не только экономят время на поиск специализированного программного обеспечения, но и работают только с тем подмножеством метрик, которые разработчики базы данных посчитали важными. По этой причине многие (если не все) популярные базы данных записывают информацию о системных событиях и внутренних задачах туда, откуда её может при необходимости прочитать пользователь - обычно в отдельную таблицу внутри базы данных. Хотя наличие такой информации и не является обязательным условием для существования базы данных и её использования, всё же конечные пользователи ожидают её присутствие. Этим и объясняется значимость текущей работы. Что касается новизны: хоть все широко используемые метрики и были уже интегрированы в различные проекты, большая часть столбцовых СУБД (тип СУБД важен, так как текущая работа фокусируется на метриках для СУБД такого вида) является программным обеспечением с закрытым исходным кодом, что не позволяет узнать внутреннее устройство ПО и интеграции метрик. В связи с этим приходится интегрировать метрики с чистого листа, что можно трактовать как новизну.

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

Для достижения поставленной цели необходимо решить следующие задачи:

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

Выбрать один или несколько лучших инструментов по результатам сравнения и реализовать получение метрик из системы с помощью этих инструментов в отдельном приложении - прототипе;

Во время реализации прототипа следить за ограничениями используемых инструментов и после реализации сделать выводы о необходимости дальнейшего использования выбранных инструментов при интеграции в ClickHouse;

Интегрировать метрики производительности в ClickHouse на основе лучшего инструмента по результатам сравнения в прототипе;

Отправить Pull request в репозиторий ClickHouse с изменениями, пройти процедуру ревью и добавить код в главную ветку репозитория.

Структура выпускной квалификационной работы

В первой главе рассматриваются особенности СУБД ClickHouse и инструменты, позволяющие записывать метрики производительности на платформе Linux. Во второй главе обосновывается выбор конкретной технологии (perf events) и рассматриваются особенности системы Linux и проблемы, которые могут возникнуть при работе с perf events. В третьей главе рассматривается решение проблем из главы 2 с демонстрацией наличия этих проблем.



1. Обзор источников

Перед описанием источников, аналогов и проведением анализа стоит обозначить условия выполнения работы, которые повлияли на выбор всего вышеперечисленного. Начать стоит с упоминания того, что интеграция метрик производилась в СУБД ClickHouse. Это столбцовая система управления базами данных для онлайн обработки аналитических запросов. Основное её назначение - хранение большого количества данных об унифицированных событиях из внешних источников и выполнение запросов на получение этих данных в меньшей размерности. Документация по ClickHouse доступна на официальном сайте [1]. Основные сведения, необходимые при интеграции метрик можно найти в следующем списке:

Сборка ClickHouse на Linux [2];

Требования к стилю кода на C++ [3];

Существующая система мониторинга [4];

Описание системных таблиц [5]:

system.asynchronous_metrics [6] - метрики, вычисляющиеся в фоне;

system.metrics [7] - метрики с текущими значениями;

system.events [8] - количество определённых событий с запуска сервера;

system.query_log [9] - информация о запросах;

ClickHouse накладывает следующие ограничения:

Получение метрик должно работать на ОС Linux, так как ClickHouse поддерживает эту платформу;

Расчёт метрик должен корректно работать в случае получения их значений из разных потоков, так как большая часть запросов внутри ClickHouse выполняется параллельно;

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

Способы получения значений из системы для расчёта метрик, удовлетворяющие обозначенным требованиям:

RUsage [10];

Perf Events [11];

PAPI (Performance Application Programming Interface) [12];

Intel PCM (Processor Counter Monitor) [13];

AMD мProf [14].

Рассмотрим каждый из обозначенных вариантов:

Название	Количество доступных значений	Удобство работы	Достоинства	Недостатки
RUsage	Сравнительно невелико (16 согласно документации)	Высокое	? Легко добавляется в исходный код	? Малое количество доступных значений
Perf Events	Много (100+)	Среднее	? Наличие в ядре Linux ? Большое количество метрик ? Универсальный интерфейс для работы с событиями и Intel, и AMD
PAPI	Много (100+)	Среднее	? Большое количество метрик ? Универсальный интерфейс для работы с событиями и Intel, и AMD	? Необходимость подключения в виде библиотеки
Intel PCM	Много (100+)	Среднее	? Большое количество метрик ? Поддержка всех метрик, доступных на процессорах Intel	? Необходимость подключения в виде библиотеки ? Нет поддержки метрик, доступных на процессорах AMD
AMD мProf	Много (100+)	Среднее	? Большое количество метрик ? Поддержка всех метрик, доступных на процессорах AMD	? Необходимость подключения в виде библиотеки ? Нет поддержки метрик, доступных на процессорах Intel

Рассмотрим кандидатов по отдельности:

1.1 RUsage

getrusage - функция в Linux для получения сведений о ресурсах, используемых в системе. Умеет выдавать сведения для текущего процесса и для текущего процесса вместе с подпроцессами. Основные значения, которые могут понадобится в ClickHouse, это:

ru_utime - время, потраченное на исполнение пользовательского кода;

ru_stime - время, потраченное на исполнение системного кода, используемого внутри пользовательского;

ru_minflt - количество отказов страницы, которые не привели к вводу/выводу в системе;

ru_majflt - количество отказов страницы, которые привели к вводу/выводу в системе;

ru_inblock - количество операций чтения с диска, выполненных по требованию процесса;

ru_oublock - количество операций записи на диск, выполненных по требованию процесса.

Данная функция выдаёт текущие значения после её выполнения. Это значит, что при необходимости узнать, сколько событий произошло между двумя моментами времени (к примеру, между “пользовательская функция начала работу” и “пользовательская функция закончила работу”), необходимо получить данные в первый момент времени, во второй и найти разницу между вторым и первым. Основной сложностью здесь является момент, когда количество событий превышает диапазон значений переменных, куда эти количества записываются. В этот момент значение счётчиков сбрасывается. В связи с этим необходимо вызывать функцию каждые n секунд (устанавливается экспериментально) для получения корректных данных.

1.2 Perf Events

Perf - средство профилирования, доступное на платформе Linux, позволяющее получать счётчики производительности устройств, программные счётчики производительности и поддерживают работу с ещё несколькими системными интерфейсами, которые не рассматриваются в текущей работе. Perf (или Perf Events) состоит из двух частей: части ядра (kernel space) и пользовательской части (user space). Часть ядра используется посредством функции perf_event_open, файлового дескриптора и отображённой области памяти. Пользовательская часть состоит из консольной программы perf, которая реализует удобное взаимодействие с perf events со стороны пользователя. В рамках текущей работы рассматривается взаимодействие только с частью ядра через perf_event_open, так как работа с API напрямую происходит быстрее и удобнее, нежели через промежуточное звено в виде perf. Основным достоинством perf, как уже было отмечено в таблице, является интеграция в ядро системы, которая позволяет не добавлять новые библиотеки в проект и сохраняет при этом хороший баланс между производительностью и удобством использования.

1.3 PAPI

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

1.4 Intel PCM

Рисунок 1 - Интерфейс Intel PCM console

Intel PCM (Рисунок 1) - программный комплекс (программа и библиотека), предоставляющая информацию о производительности и использованию ресурсов системой, работающей на процессорах компании Intel. Главным достоинством является возможность получения так называемых “uncore” счётчиков [15], другими словами получение информации, которая хранится не в общепринятых регистрах для хранения счётчиков, а в регистрах, специфичных для конкретных моделей процессоров. Стоит отметить, что значения таких счётчиков можно получить, используя perf events, но придётся прописывать конкретные значения типов счётчиков для каждой модели процессоров Intel [16], которые доступны “из коробки” в Intel PCM.



1.5 AMD мProf

Рисунок 2 - Интерфейс AMD мProf

AMD мProf (Рисунок 2) - в чём-то похожий на Intel PCM программный комплекс, который позволяет получить специфическую для процессоров AMD информацию об используемых ресурсов. Основное отличие в плане функциональности заключается в том, что AMD мProf в большей степени сконцентрирована на взаимодействии с ПО на уровне визуального интерфейса, а не программного. Так, на программном уровне доступно получение информации только об энергозатратах устройства через AMDPowerProfileAPI.

1.6 Постановка задач для разработки

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

Выбрать один или несколько лучших инструментов по результатам сравнения и реализовать получение метрик из системы с помощью этих инструментов в отдельном приложении - прототипе;

Во время реализации прототипа следить за ограничениями используемых инструментов и после реализации сделать выводы о необходимости дальнейшего использования выбранных инструментов при интеграции в ClickHouse;

Интегрировать метрики производительности в ClickHouse на основе лучшего инструмента по результатам сравнения в прототипе;

Отправить Pull Request в репозиторий ClickHouse с изменениями, пройти процедуру ревью и добавить код в главную ветку репозитория.



2. Предлагаемые решения

2.1 Выбранная технология и алгоритм работы

Под обозначенные ранее требования все 5 технологий подходят. Из них только 3 можно назвать созданными специально для программного взаимодействия с ними, это RUsage, Perf Events и PAPI. Из этих технологий RUsage уже используется внутри ClickHouse, поэтому рассматривать эту технологию в качестве решения текущей работы - делать то, что уже сделано и не нуждается в исправлении. Поэтому конечный выбор происходит между Perf Events и PAPI. Обе технологии хорошо приспособлены к использованию их внутри продукта и удовлетворяют всем требованиям, которые к ним предъявляются. Окончательное решение - использовать Perf Events из-за наличие оного в ядре системы и, следовательно, отсутствия необходимости подключать дополнительную библиотеку к проекту.

Теперь про интеграцию метрик в ClickHouse. Как уже было сказано в предыдущем абзаце, в ClickHouse реализовано получение системной информации через RUsage. Это означает, что в ClickHouse уже есть некий макет того, как должен работать код с метриками, какие функции доступны во время выполнения этого кода, и на какие события в СУБД можно полагаться для отслеживания жизненного цикла используемых компонентов СУБД.

В моей работе используются компоненты ClickHouse, отвечающие за выполнение отдельных запросов к базе (queries). Работа пользователя с СУБД выполняется посредством отправки запросов на собственном диалекте SQL. Каждый запрос представляет собой SQL выражение, которое парсится на уровне СУБД, выполняется, и результат выполнения которого возвращается пользователю (Рисунок 3).



Рисунок 3 - Пример выполнения запроса в ClickHouse

Подсчёт метрик выполняется для каждого запроса по отдельности, поэтому для корректной работы необходимо знать, когда запрос начал выполнение, когда закончил, и куда нужно записывать итоговые значения. В случае с отслеживанием выполнения необходимые методы: initPerformanceCounters и finalizePerformanceCounters (Рисунок 4).

Рисунок 4 - Методы ClickHouse, используемые для запуска и остановки записи событий

Рисунок 5 - Верхнеуровневая последовательность записи событий

Верхнеуровневая последовательность записи событий состоит из малого количества элементов (Рисунок 5). Она служит исключительно для понимания основной логики и не претендует на достоверное отражение сложности взаимодействия с системной библиотекой. Схему, которая отражает сложность взаимодействия, можно найти в главе 3.

2.2 Используемые методы

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

Вызов функции perf_event_open - затратная по процессорному времени операция, которая может в некоторых случаях занимать более 50% времени выполнения отдельных запросов, что приводит к заметному увеличению времени работы СУБД;

У Linux есть ограничение на количество открытых файловых дескрипторов;

Запись метрик является одним из уязвимых мест в системе [17], поэтому для работы с ними программа должна иметь специальные привилегии;

У процессора ограниченное количество аппаратных счётчиков.

Работа с perf events осуществляется с помощью вызовов системных функций read, ioctl, close на файловом дескрипторе, возвращаемом функцией perf_event_open при успешной настройке записи события. Вызовы функций read, ioctl, close осуществляются достаточно быстро (незначительная часть от общего времени выполнения запроса), в то время как вызов perf_event_open может привести к серьёзному ухудшению производительности. Запись метрик с помощью perf events без вызова perf_event_open невозможна, поэтому, хоть и требуется максимально уменьшить количество вызовов функции, избавиться от её вызова совсем не получится. Каждый запрос выполняется в потоке, который берётся из пула потоков, то есть для нескольких запросов может использоваться один и тот же поток. Было решено вызывать функцию для открытия дескрипторов единственный раз при первом выполнении запроса на потоке, в последующих же запросах переиспользовать дескрипторы, открытые ранее. Это первый шаг к исправлению проблемы (1). метрика репозиторий код

Вторым шагом к исправлению проблемы (1) является возможность настройки списка событий, которые будут отслеживаться, со стороны пользователя. С помощью настроек пользователь может явно задать только те события, которые ему важны, остальные же не будут использовать ресурсы системы. Данный шаг так же позволяет решить проблему (2).

В Linux есть ограничения на количество открытых файловых дескрипторов. Эти ограничения используются для управления количеством ресурсов, которые может использовать система/процесс. Таких ограничений 3: system limit, hard limit и soft limit. System limit задаётся на уровне ядра и отражает максимальное количество открытых дескрипторов в целом. Hard limit и soft limit задаются на уровне отдельных процессов, отражая максимальное количество дескрипторов, которые может открыть отдельный процесс. Отличие hard limit от soft limit в том, что увеличить hard limit может только пользователь с правами администратора, в то время как увеличение soft limit доступно всем пользователям. При этом soft limit не может превышать hard limit. С помощью установки hard limit пользователи с правами администратора могут задать ограничения для обычных пользователей. Для записи метрик необходимо учитывать установленные лимиты, так как в противном случае запись метрик может занять всё множество доступных дескрипторов, что приведёт к тому, что ClickHouse не сможет открывать новые дескрипторы для своего функционирования.

Как уже было сказано, запись метрик в Linux является одним из уязвимых мест [18], поэтому для их записи, и соответственно решения проблемы (3), необходимо наличие определённых прав у программы. За такие права отвечает привилегия CAP_SYS_ADMIN [19] и системная настройка perf_event_paranoid [20]. Если у процесса есть привилегия CAP_SYS_ADMIN, он может записывать все события [21]. Если у него этой привилегии нет, он может записывать только ту часть информации, которую позволяет записывать текущее значение настройки perf_event_paranoid. Программа не может получить такие права самостоятельно, поэтому единственный вариант обработки подобных ошибок - вывод пользователю сообщений об ошибке и её причинах.

Теперь разберёмся с счётчиками. Для начала стоит обозначить, что такое счётчики в общем и зачем они нужны. В любой сложной системе есть набор из компонентов, которые каким-либо образом взаимодействуют между собой. Это может быть набор из микропроцессора, оперативной памяти и видеокарты (набор аппаратных компонентов) (Рисунок 6). Это может быть набор из системной библиотеки и программы в пользовательском пространстве (набор программных компонентов). Это также может быть набор из микропроцессора, системной библиотеки и программы в пользовательском пространстве (набор аппаратных и программных компонентов).

Рисунок 6 - Пример набора аппаратных компонентов

В любом из этих случаев в отдельности взятый сложный по устройству компонент взаимодействует с другим. При развитии компонентов происходит увеличение их сложности, к примеру количество строк кода в ядре Linux за чуть больше, чем 10 лет увеличилось на 15-20 миллионов (Рисунок 7):

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

Рисунок 7 - График количества строк кода в ядре Linux по версиям ядра

Есть два типа счётчиков: аппаратные и программные. Аппаратные счётчики - те счётчики, которые используют специальные регистры в микропроцессорах, в которых происходит подсчёт событий. Программные же счётчики в микропроцессоры не встроены, а находятся на программном уровне. Список доступных счётчиков можно узнать из программы perf, выполнив команду perf list (Рисунок 8).



Рисунок 8 - Неисчерпывающий список счётчиков, доступных в системе

Специальных регистров в микропроцессорах ограниченное количество из-за физических ограничений по количеству соединений отдельных компонентов [22]. Это приводит к тому, что в отдельный момент времени может подсчитываться не более некоторого количества типов аппаратных событий, что может стать проблемой в случае, если пользователь хочет записать несколько типов аппаратных событий одновременно. Если есть аппаратная возможность это сделать, то полученные пользователем данные будут точны, если же аппаратной возможности нет, счётчики будут записывать лишь часть времени выполнения задачи, включаясь по циклическому (round-robin) алгоритму. Если на устройстве доступно N аппаратных счётчиков, будут записываться первые N событий. Через некоторый промежуток времени будут записываться вторые N событий и так далее. Таким образом, каждый тип событий будет записан, но на определённом промежутке времени.

В этом случае можно отмасштабировать количество событий до всего времени выполнения задачи по формуле “<количество исходных событий> * <время, которое был активен счётчик> / <время записи событий>”. К примеру, если событие записывалось на счётчике 100 миллисекунд (<время записи событий>), при этом он был включен 500 миллисекунд (<время, которое был активен счётчик>), и в итоге записалось 1000 событий, можно отмасштабировать результат на всю задачу и получить событий за всю задачу. В случае использования масштабирования стоит предоставить пользователю информацию о пропорции времени выполнения к времени активности, чтобы он мог решить, насколько его устраивает точность произведённых вычислений. Предоставление такой информации вкупе с перекладыванием принятия решения на конечного пользователя решает проблему (4). В программе perf применён именно такой подход (Рисунок 9).

Рисунок 9 - Пример полученных значений счётчиков при использовании perf. Проценты показывают, какую часть времени было записано отдельное событие



3. Технологический раздел

3.1 Требования к выполняемым функциям

Работа с аргументами командной строки из аргументов, переданных главному исполняемому файлу СУБД;

Вычисление метрик с помощью perf events, доступных на ОС Linux;

Сохранение результатов в таблицу СУБД;

Поддержка добавления дополнительных метрик при необходимости без существенного переписывания кода;

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

3.2 Средства и инструменты разработки

Язык разработки: C, C++ - ClickHouse написан на C и C++ для обеспечения максимальной производительности, поэтому эти языки требуется использовать при разработке;

Среда разработки: CLion - удобная IDE от JetBrains, в которой есть если и не все, то подавляющее большинство функций работы с кодом, в том числе и сопутствующие инструменты, как работа с системой контроля версий;

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

3.3 Особенности реализации

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

Для начала записи событий необходимо вызвать функцию perf_event_open, которая вызывается через syscall (системный вызов). Первоначальная идея была в начале записи счётчиков в начале выполнения запроса и остановка записи с освобождением ресурсов в конце выполнения запросов. Данная идея после реализации была забракована из-за слишком больших накладных расходов, связанных с вызовом syscall при старте запроса. На рисунках ниже можно увидеть информацию по разнице во времени выполнения функций до добавления метрик и после (Рисунок 10) и диаграмму по одному из запросов, на которой видно большой вклад syscall в замедление программы (Рисунок 11).

Рисунок 10 - Разница во времени выполнения функций до добавления метрик и после

В связи с таким ухудшением производительности было решено изменить алгоритм записи метрик. perf_event_open вызывается для создания счётчика в системе и ассоциации с ним файлового дескриптора. После вызова можно использовать функцию ioctl с специальными параметрами для включения/выключения/сброса счётчиков. Вызов ioctl согласно графику, занимает 0.08% общего времени выполнения, что при исключении вызова perf_event_open (63.88%) превращается в от общего времени работы запроса, что является несущественными накладными расходами.

Рисунок 11 - Большой вклад syscall в замедление программы

Так как вызов perf_event_open обязателен для запуска записи счётчиков, избавиться от него нельзя, но из-за того, что ClickHouse использует пул потоков для выполнения запросов, можно вызывать функцию единственный раз при запуске первого запроса, при запуске последующих запросов можно сбрасывать значение счётчика с помощью ioctl, не выполняя времязатратного системного вызова. После внесения такого изменения, лишь на отдельных тестах обнаружились проблемы с производительностью, что было приемлемо (Рисунок 12).

Вторая проблема заключается в большом количестве файловых дескрипторов, открываемых в процессе работы. Для записи значений каждого счётчика необходимо открыть файловый дескрипторов с помощью функции perf_event_open. В текущей реализации используется 16 счётчиков. Это означает, что на каждый поток выполнения открывается 16 файловых дескрипторов. В системе Linux есть ограничение на количество единовременно открытых файлов (Рисунок 13). В случае сильного распараллеливания запросов (к примеру, для 4096 потоков требуется дескрипторов) расчёт метрик может начать использовать весь доступный диапазон дескрипторов, что приведёт к невозможности записи данных основными компонентами СУБД.

Рисунок 12 - Результат тестов производительности после уменьшения количество вызовов perf_event_open

Рисунок 13 - Пример наличия ограничения в 1024 открытых файла в системе

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

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

Выборочная настройка реализована с помощью 2 настроек:

metrics_perf_events_enabled - включает запись perf событий в целом;

metrics_perf_events_list - список с записываемыми событиями, разделёнными запятой.

Итоговая схема работы сложнее высокоуровневой, но всё ещё понятна (Рисунок 14).

Рисунок 14 - Итоговая схема работы

3.4 Описание классов

PerfEventValue	Содержит информацию о значениях счётчиков в определённый момент времени
PerfEventsCounters	Обеспечивает запись и обработку данных счётчиков
PerfDescriptorsHolder	Содержит массив открытых файловых дескрипторов, используемых для записи событий и закрывает дескрипторы при уничтожении объекта
PerfEventInfo	Содержит информацию об одном типе событий

3.5 Диаграмма классов

Рисунок 15 - Диаграмма классов

3.6 Примеры тестирования

Сценарий 1, запись всех возможных событий:

Установить значение perf_event_paranoid в 1 (Рисунок 16):

Рисунок 16 - Установка значения perf_event_paranoid

Запустить сервер и клиент ClickHouse,

Включить запись всех метрик (Рисунок 17, Рисунок 18):



Рисунок 17 - Включение записи метрик

Рисунок 18 - Выбор метрик для записи

Выполнить запрос на обработку случайных чисел (Рисунок 19):

Рисунок 19 - SQL запрос на обработку случайных чисел

Получить информацию о последнем запросе (Рисунок 20):

Рисунок 20 - SQL запрос на получение информации о последнем запросе

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

Сценарий 2, проверка ограничений на количество файловых дескрипторов:

Установить значение perf_event_paranoid в 1,

Установить hard limit в системе в 400 (Рисунок 21):

Рисунок 21 - Команда на установку hard limit в Linux

Запустить сервер и клиент ClickHouse,

Включить запись всех метрик,

Выполнить запрос на обработку случайных чисел,

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

Сценарий 3, проверка закрытия неиспользуемых дескрипторов:

Установить значение perf_event_paranoid в 1,

Запустить сервер и клиент ClickHouse,

Включить запись всех метрик,

Выполнить запрос на обработку случайных чисел,

Узнать количество открытых файловых дескрипторов сервером (Рисунок 22):

Рисунок 22 - Команды для определения текущего количества открытых файловых дескрипторов для сервера ClickHouse

Выполнять шаги 4 и 5 до тех пор, пока количество открытых дескрипторов не стабилизируется (каждый поток будет хранить свои дескрипторы),

Включить запись только одной метрики (Рисунок 23):

Рисунок 23 - Команда для записи только одной метрики cpu-cycles

Выполнять шаги 4 и 5 до тех пор, пока количество открытых дескрипторов не стабилизируется (каждый поток будет хранить единственный дескриптор),

Убедиться, что количество файловых дескрипторов после 8 шага меньше их количества после 6 шага.



Заключение

На момент написания данного документа выполнены все задачи из поставленных кроме внедрения кода в главную ветку репозитория [23]. Это связано с тем, что внедрение кода завязано на людей в Яндексе, разрабатывающих ClickHouse.

В качестве дальнейшей работы можно интегрировать технологии, которые были рассмотрены в текущей работе, но не выбраны из-за необходимости более общего решения. К примеру, можно интегрировать работу с Intel PCM и AMD мProf для получения платформозависимых метрик.

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



Аннотация

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

Работа содержит 30 страниц, 3 главы, 23 рисунка, 23 источника, 4 приложения.

Ключевые слова: метрики производительности, perf events, инструменты perf, Linux ПО, ClickHouse, колоночные СУБД.

When using a database for storing and retrieving data is not an option, but the only way to operate on large sets of data, looking for the best possible performance you can get from the database is a common practice. The end users utilize the hardware features of their systems and use some integrated, their own or third-party software to profile the database's queries and inner tasks and get this performance. Although, this can be enough to get a picture of what is going wrong, integrating performance metrics right into the database could reduce the time spent on looking for the specific software for performance monitoring.

The paper contains 30 pages, 3 chapters, 23 images, 23 references, 4 appendices.

Keywords: performance metrics, perf events, perf tools, Linux software, ClickHouse, column-oriented database.

Размещено на Allbest.ru

...