Обычно ваше приложение будет сохранять набор запросов в ArangoDB для одного сценария (например, отображение информации об учетной записи вашего пользователя и т. д.). Когда вы хотите масштабировать свое приложение, вы запускаете в нем запросы и смотрите, как оно себя ведет. В зависимости от внутренних процессов время выполнения этих сценариев немного различается.

Мы возьмем интервалы в 10 секунд и построим график значений, которые мы там получим:

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

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

  • количество дескрипторов открытых файлов
  • количество запущенных потоков
  • используемые ресурсы процессора

Наше решение для мониторинга

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

Поскольку позже нам потребуется отслеживать файловые дескрипторы для каждого процесса, мы исправляем collectd с помощью этого pull request (или используем более новую версию, чем 5.7.2, как только она будет доступна).

В решении для постоянного мониторинга можно было бы, например, настроить графит для сбора значений. Чтобы упростить рамки этой статьи, мы используем серверную часть collectd rrd и проверяем наши показатели используя KCollectd, который представляет собой простую программу KDE, доступную в большинстве современных дистрибутивов Linux.

Мониторинг использования ЦП ArangoDB с помощью collectd

Мы сопоставляем процесс с помощью регулярного выражения, используя этот фрагмент конфигурации collectd:

Интеграция statsd в нашу настройку

Statsd (как упоминалось выше) стремится добавить в вашу программу клиентские инструменты. Поскольку нам нужна только статистика, нам не нужна 100% точность. Таким образом, нам все равно, потеряются ли некоторые измеренные значения, если мы получим преимущество, заключающееся в том, что нам не нужно задерживать программу, сообщившую об этом.

По этой причине пакеты statsd пересылаются через UDP в режиме пожарной безопасности от клиента к серверу.

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

Эта реализация идентифицирует запросы AQL, создавая хэш строки запроса, поэтому вам необходимо использовать значения привязки, чтобы получить полезные значения.

Связь с «настоящими» номерами

Вот небольшой скрипт на Python, создающий некоторую нагрузку на БД, чтобы мы могли измерить некоторые хорошие значения:

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

При первом запуске мы ограничиваем цикл, чтобы мы могли идентифицировать наши запросы в reportFileName в /tmp/abc:

Проверка результатов

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

В ветке statsd мы находим значения, которые выдает наш запрос AQL. Создадим с ним один график.

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

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

Синяя линия обозначает 95%-й процентиль, который намного ниже коричневой линии с максимальным временем ответа. Это указывает на то, что есть одиночные ответы, которые намного хуже, чем процентиль — поведение, которое вообще не хотелось бы иметь.

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

Взглянув на наш код, мы видим, что это соответствует количеству документов, которые мы заполняем в test-коллекции.

Таким образом, мы более подробно рассмотрим отслеживаемый запрос с помощью explain:

АГА! индекс не используется — поэтому он ухудшается по мере заполнения коллекции.

Почини это…

Поэтому мы создаем индекс на этапе настройки нашего тестового кода: testCol.ensureHashIndex(['count'], sparse=False)

Как только он будет там, объяснение покажет нам, что он будет использоваться:

Повторите тест и проанализируйте

и значения, которые мы измеряем, показывают гораздо лучшие результаты:

В то время как первый запуск еще не был закончен через 7 минут, второй запуск уже сделан через 4 минуты. Мы увидели, что числа Thread count вообще не находились в диапазоне значений процессорного времени, поэтому мы переместили их на график количества дескрипторов файлов.

Наблюдая за временем ответа на запрос при первом запуске, мы видим, что наихудшее время ответа составляет около 60 мс. В начале мы видим, что операция truncate дает нам немного более медленные значения, но во время обычного тестового прогона максимальные значения составляют около 5 мс, что вполне приемлемо.

Мы также видим, что использование ресурсов процессом ArangoDB намного лучше — 100 000 мига по сравнению с 900 000 мига в первом тестовом прогоне.

Мы также видим, что процессорное время системы составляет 1/3 всего процессорного времени, что означает, что мы выполняем много операций ввода-вывода (записываем новые документы на диск), слегка загружая машину вычислениями в пользовательском пространстве.

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

Что дальше

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

Как ранее публиковалось на ArangoDB