План производственных мощностей: Система

Цель

Цель этого упражнения – выявить любые потенциальные системные проблемы на производственной площадке. Приложение Operation monitor (Монитор операций) удобно предоставляет эту информацию, чтобы на нее можно было легко ссылаться.

Есть ряд показателей, на которых следует сосредоточиться:

Engine CPU (ЦП движка)
Engine RAM (ОЗУ движка)
Users per Engine (Пользователей на движок)
Intra-day Reloads (Обновление приложений в течение дня)
Batch Window (Пакетное окно)

Примечание

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

Operation Monitor (Монитор Операций)

Чтобы найти ссылку на соответствующую документацию, пожалуйста, обратитесь к странице Монитора Операций.

Подтвердите, что Монитор Операций работает

Перейдите к Monitoring apps (приложения Мониторинга) и нажмите кнопку Details(«подробности») (значок информации) в приложении «Мониторинг операций». Убедитесь, что данные приложения актуальны.

Если «Монитор операций» не обновлен, обратитесь к документации Монитора операций для получения сведений о настройке и действиях по устранению неполадок.

Сбор метрик

Выберите лист Performance (Производительность) в Мониторе операций.

Выберите в фильтре Month (Месяц) последние три месяца, если это задание выполняется ежеквартально.

ЦП движка

Теперь сосредоточимся на диаграмме Qlik Sense Engine CPU (ЦП движка Qlik Sense). Убедитесь, что в качестве показателя выбран Max CPU (Максимальный ЦП). Обратите внимание, что на этой диаграмме по умолчанию отображается месяц, однако она может быть развернута с точностью до дня, часа и десяти минут. Рекомендуется следить за длительными периодами высокой загрузки ЦП и проверять, повторяются ли эти события. На приведенной ниже диаграмме мы видим, что эти серверы не очень загружены, так как максимальная загрузка ЦП не превышает 32%.

ОЗУ движка

Затем обратите внимание на диаграмму Qlik Sense Engine RAM (GB) (ОЗУ движка Qlik Sense (Гб)). Эта диаграмма имеет ту же структуру, что и предыдущая, за исключением того, что основное внимание уделяется использованию оперативной памяти. Важно отметить, что эта диаграмма показывает не только «базовый объем ОЗУ» приложений, но также «ОЗУ кэша набора результатов», а также ОЗУ для вычислений и т. д. Найдите время, чтобы просмотреть приведенную ниже таблицу и поищите продолжительные периоды времени очень высокого использования ОЗУ, скажем, около 90%, когда сервер постоянно борется за очистку кеша, чтобы освободить место для новых наборов результатов. Соответственно сервер является перегруженным в случае когда периоды высокого использования идут непрерывно. В данном примере серверы выглядят исправными.

Поскольку здесь нет простого способа показать, какие приложения потребляют какой процент от общего объема ОЗУ, для отрисовки пограничной линии потребления можно воспользоваться следующим подходом:

Общий базовый объем ОЗУ всех приложений, доступных для загрузки в движок, должен составлять <= 40% от общего объема ОЗУ сервера.

* Данный способ является хорошим средством для предохранения сервер от «схода с рельс», но он не является гарантией. Если тысячи пользователей одновременно будут работать в такой конфигурации, они, скорее всего, будут потреблять больше, чем оставшийся доступный объем ОЗУ. Поэтому также важно иметь достаточное количество движков и правильно распределять пользователей по ним.

Чтобы рассчитать показатель общего базового объёма ОЗУ всех приложений, нам нужно использовать приложение App Metadata Analyzer (Анализатор Метаданных Приложений). Убедитесь, что оно настроено, а затем перейдите к листу App Availability (Доступность Приложения).

В таблице Engine Node: Available Apps & Base RAM Footprint (Узел движка: Доступные приложения & Базовый объём ОЗУ) можно посмотреть общий базовый объем ОЗУ для всех приложений, которые могут быть запущены на каждом отдельном движке.

Примечание

Эту практику также следует повторить, выбирая только самые часто используемые приложения, так как маловероятно, что все приложения будут открыты в ОЗУ одновременно в продуктивной среде, если только не развернуто всего несколько приложений. Предлагается выбирать только часто используемые приложения, которые можно найти в диаграмме Operations Monitor -> Session Overview sheet -> Top 50 Apps (Монитор операций -> Лист Обзор сеанса -> Топ 50 приложений).

Без выбранных конкретных приложений:

Здесь видно, что все приложения доступны на всех движках – это означает, что пользовательские правила балансировки нагрузки не установлены. Общий объем ОЗУ всех приложения составляет 155 ГБ, и в этом примере серверы имеют по 512 ГБ ОЗУ. Таким образом, общий базовый объем ОЗУ приложений составляет 30% от общего объема ОЗУ сервера, что ниже отметки в 40% из описанного выше подхода оценки, так что пока все в порядке.

Максимальное количество одновременных пользователей на ядро

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

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

Чтобы создать эту диаграмму, откройте Монитор операций и создайте новый лист. Назовите его Max Concurrent Users by Hostname «Максимальное количество одновременных пользователей на хост».

Перетащите диаграмму Pivot Table (Сводная Таблица), затем добавьте поле Hostname (Хост) в качестве измерения.

Затем добавьте в качестве меры показатель «Максимальное количество одновременных пользователей».

Назовите диаграмму Max Concurrent Users by Hostname (Максимальное количество одновременных пользователей на хост). Затем оцените общее количество одновременных пользователей на каждом хосте.

Обновление приложений в течение дня

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

Оставаясь в Мониторе операций, перейдите на лист Task Overview (Обзор задач).

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

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

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

Дублируйте лист и скопируйте гистограмму Reload Count (Количество обновлений).

Освободите место для новой диаграммы и вставьте ее.

Удалите измерение Reload Status (Статус обновления) с новой гистограммы.

Добавьте поле Hostname (Хост).

Перетащите поле Hostname (Хост) вверх, чтобы оно было над полем Task Name (Название задачи).

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

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

* Если в производственной среде есть узел «песочница», этот узел можно игнорировать в этом обзоре, так как на нём будут происходить обновления в хабе.

Пакетное окно

Как правило, в этом разделе представлена емкость пакетного окна сайта (преимущественно ночного). Шаги по оптимизации пакетного окна можно найти здесь: Оптимизировать пакетное окно.

Прочитав процесс оптимизации, можно применить следующие правила:

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

Пример вывода

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

Движок ЦП	Движок ОЗУ	Пакетное окно	Среднее количество обновлений за день
Хороший	Хороший	Хороший	354

	Максимальное количество одновременных пользователей на движок
Движок 1	1
Движок 2	2
Движок 3	1

	Обновление приложений в течение дня	Пересечение с работой конечных пользователей
Движок 1	386	Нет
Движок 2	214	Да
Движок 3	0	Да