BAA20 Порядок анализа причин снижения производительности

• долгий ввод значений в ячейку МК;
• долгий ввод значений в ячейку МК на ДБ/КТ;
• медленное открытие отчета/отчетов (ДБ, КТ);
• долгое создание/изменение метаданных в модели: справочники/элементы справочников, мультикубы/кубы, свойства, подмножества, формулы и т.д.;
• медленная загрузка данных в модель (интеграции с внешними системами);
• фоновые процессы приложения – скрипты этой или других моделей, создание бекапа модели/восстановление из бекапа;
• фоновые процессы сервера - сервисы ОС и другие компоненты (аудиты, логирование, языки программирования и т.д.).

Шаг 1. Выявление конкретных мест снижения производительности на основании п.1. Понять, где возникает проблема (тормозит или блокируется модель): ввод данных (какие мультикубы, кубы, отчеты), изменение метаданных (какие справочники/подмножества/свойства и т.д. долго создаются или меняются), фоновые операции, которые подвешивают модели и блокируют пользователей при работе (создание и восстановление из бекапа/запуск скриптов по расписанию/прочие сервисы) и т.д.

Шаг 2. Анализ состояния сервера, на котором установлен Оптимакрос. После выполнения шага 1, проверить загрузку сервера (CPU, Memory Usage, Drive Usage) в момент выполнения ресурсоемких операций из шага 1.

Анализ необходимо произвести в панели администратора workspace в разделе «Server Status», используя вкладку «Dashboards». Если при выполнении данных операций будут достигнуты предельные величины, например, загрузка процессора ближе к 100% или достигнут лимит оперативной памяти, то причиной снижения производительности могут быть низкие характеристики сервера, которые могут не соответствовать объемам моделей на workspace, количеству одновременной работы пользователей в Optimacros или, например, сложной логике расчетов и обработки данных.

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

Решением может быть: добавление CPU, RAM на сервер, анализ железа (количество кеша процессора, количество сокетов для процессора и т.д.), проверка настроек сервера, фоновых процессов, а также перезагрузка самого WS, если все показатели сервера в норме.

Показатель Drive Usage отображает наличие места на HDD. Это влияет на работоспособность сервера. Если диск переполнен, то могут не запускаться скрипты, так как не хватает места для Maria DB. На производительность данный показатель не влияет. (уточнить)

Шаг 3. Анализ быстродействия расчетов внутри модели при выполнении операций из п.1. (ввод данных в МК, добавление элементов в справочники, добавление элементов в подмножества, копирование и загрузка данных в МК скриптами и т.д.).

Анализ скорости расчетов в модели можно произвести с помощью функционала «cxp_server_profiled»:

• в панели администратора workspace в необходимой модели включить опцию «cxp_server_profiled», сохранить и перезапустить модель;
• зайти в модель и произвести то действие, которое необходимо проанализировать (ввести данные в ячейку, проставить галочку в сабсете и т.д.);
• в панели администора WS перейти на вкладку «Requests» в необходимой модели, открыть «Requests History» и найти в списке необходимый запрос;
• в скаченном архиве открыть файл Excel с максимальным размером и произвести анализ действий/расчетов, которые были задействованы.

На основании анализа данного лога могут быть выявлены основные МК/кубы, пересчет которых занимает больше всего времени в модели, что приводит к снижению производительности системы (система подвисает в момент, пока производится пересчет). Необходимо составить реестр таких объектов и перейти к анализу каждого из них.

Шаг 4. Анализ объектов модели на основании шага 3:

• анализ формул, которые применены к кубам, выявленным на шаге 3. Формулы могут сильно влиять на производительность и часто являются одной из основных причин ее снижения. В рамках тестирования рекомендуется убрать формулы в комментарии и проверить, изменится ли производительность модели. Если да, то решением могут быть следующие действия: изменить формулу (убрать ресурсоемкие функции), применить Formula Applier, разбить формулу, если она слишком большая и т.д.;
• анализ МК и их размеров, в которых происходит долгий пересчет. Большие МК, в которых производится расчет данных, также могут влиять на производительность модели, так как часто они имеют большую разреженность данных. В рамках тестирования сделать МК меньшего объема и проверить производительность операции. Если скорость расчетов улучшится, то перейти в сторону оптимизации размеров МК. Решением может быть: использование выборок, 1D справочников, использование OLTP для хранения исторических данных или данных, которые не нужны в оперативном доступе (плоский архив), дробление модели на более мелкие и т.д.;
• анализ кубов, в которых происходит медленный расчет данных – форматы, сумматоры (итоги). Например, в кубах, в которых нет необходимости видеть итоги (суммы или расчетные данные) на консолидированных элементах, можно изменить тип суммирования на «None», тем самым ограничив объем расчетных данных, что может дать прирост производительности. Также проанализировать форматы, так как, например, кубы с текстовым форматом обрабатываются дольше, чем кубы с форматом «измерение» или «число».

Шаг 5. Если выявить конкретные объекты на шаге 3 не удалось, и при этом расчеты в модели происходят быстро, но наблюдаются проблемы с долгим открытием и вводом данных именно на ДБ или КТ, то следует произвести анализ самих отчетов:

• количество карточек на ДБ. Большое количество карточек влияет на скорость открытия ДБ;
• количество FG (flexible grid). Большое количество кастомных колонок, добавленных на отчеты, могут влиять на скорость загрузки, так как это будут дополнительные объекты;
• количество CV (custom view). Большое количество CV увеличивает время открытия/загрузки ДБ или МК;
• количество применённых Boolean-фильтров. Применение Boolean-фильтров на большом массиве данных (больших справочников/объемных МК) может привести к медленной загрузке карточек на ДБ;
• количество графиков на большом количестве элементов влияет на скорость их загрузки.

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

Шаг 6. Если наблюдается снижение скорости работы скриптов (долгое время загрузки/выгрузки данных, долгое время создания метаданных, блокировка пользователей модели и т.д.), то требуется проделать следующие действия:

• проверить ядра на актуальность. Ядра для скриптов постепенно оптимизируются и вендор выпускает обновленные версии. Таким образом устаревшие ядра могут замедлять работу скриптов и являться причиной снижения производительности;
• проверить настройки параметров скриптов, например, использование быстрых типов приемников увеличивает скорость загрузки данных в несколько раз:
• OM_MULTICUBE вместо MULTICUBE
• MYSQL_IMPORT вместо MYSQL


• проанализировать приемники и источники в работе скриптов (загрузка данных, копирование данных, экспорт данных). Приемники и источники могут иметь сложную логику обработки входящих и исходящих данных, которая будет являться причиной долгой загрузки/выгрузки. Далее при выявлении конкретных объектов (МК/кубов), которые требуют долгого пересчета при работе скрипта, необходимо вернуться к шагу 3 и 4, чтобы выявить конкретные причины.