Настройка производительности платформы

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

1. Поток измерений, поступающий на обработку в платформу;
2. Количество параметров, измерения которых требуют обработки контрольными процедурами и правилами;
3. Количество объектов, параметров;
4. Сложность дашбордов.

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

Для контроля производительности платформы используются следующие метрики:

Кроме потока измерений на платформу поступают потоки сигнальных значений и события, но они не оказывают существенного влияния на производительность, поскольку скорости их потоков малы.
Показатели MeasureProcessMeanXX указаны из расчета, что на 50% всех параметров наложены контрольные процедуры/правила. Это не означает, что 50% потока измерений требуют обработки, например, могут быть параметры с большой амплитудой и высокой скоростью изменения, такие параметры могут занимать 80% потока, но они могут не требовать обработки.

Показатель процента загрузки CPU на сервере приложений, при потоке более 100 измерений в сек. не должен быть низким. Указанная цифра в 25% не является точной, и получена по результатам мониторинга. Она не учитывает работу пользователей и дает оценку только для обработки измерений. Низкое значение показателя должно быть коррелироваться с показателями CPUiowaitPostgres и объемом занятой оперативной памяти.
Высокое значение CPUiowaitPostgres означает, что сервер приложений ждет БД. При этом на сервере приложений растет объем оперативной памяти и увеличиваются кэши. В этой ситуации нужно исправлять производительность БД.
Если значение показателя близко к максимумам ( > 80% загрузки), следует обратить внимание на поведение оперативной памяти сервера. Если оно стабильно, скорее всего JVM сервера приложений не хватает java-heap памяти (-Xmx и -Xms). Увеличение кучи JVM должно позволить снизить показатель CPUusertimeApp и использовать серверу приложений больше физической RAM. Проблемы с кучей также могут проявиться в логе сервера приложений сообщением

java.lang.OutOfMemoryError: Java heap space

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

Показатели, характеризуют скорость обработки сервером приложений потока измерений от момента их поступления с сервера сбора (MQTT брокер), до записи в БД обработанного измерения. Приведенные средние значения получены опытном путем, по результатам мониторинга. Аппаратные ресурсы соответствовали требованиям Medium. Значения этих показателей коррелируются с показателя MeasureProcessRate и CPUiowaitPostgres.
При проблемах обработки, первыми начинают заметно расти показатели MeasureProcessMean95 и MaesureProcessMean99. Их стабильно высокие значения могут существенно влиять на рост очереди на обработку (MeasureProcessRate). В тоже время, если показатели имеют периодические всплески и быстро приходят в норму, необходимо проверить лог сервера приложений на наличие ошибок обработки (неправильный вычислительный параметр, некорректная контрольная процедура, отсутствие параметра в системе, присланное контроллером), связанные с не корректной настройкой.
На графиках ниже для потока в 500 измерений в сек. показаны графики штатного поведения параметров MaesureProcessMeanXX и проблемного.

График штатного поведения параметров MaesureProcessMeanXX.

График плохого поведения параметров MaesureProcessMeanXX.

Основными причинами замедления обработки могут быть:

1. Высокая загрузка сервера приложений, нехватка физических ресурсов серверу (см. материал выше про CPUusertimeApp)
2. Проблемы с производительностью сервера БД. (см. материал ниже по CPUiowaitPostgres).

Настройки конфигурационного файла СУБД PostgresSQL приведены в материале настройка_конфигурационных_файлов_postgresql Настройка файлов БД. Если считать, что все настройки оптимальны, показатель CPUiowaitPostgres достаточно точно показывает достаточность производительности дисковой системы для входящего потока данных. По результатам мониторинга, для аппаратных серверов Medium и потока 500 измерений в сек., производительность дисковой подсистемы должна составлять не менее 1000 IOPS для разделов, которые обслуживают оперативную обработку данных.
Ниже представлен штатный график загрузки CPU сервера БД.

Вот такой график CPU явно указывает на проблему дисковой подсистемы БД

Наиболее радикальным способом лечения такой проблемы является переход на SSD диски. Ниже показан график IOPS для Medium конфигурации и потока в 500 измерений.

Рост CPUiowaitPostgres всегда сопровождается ростом показателей MeasureProcessMean. Нужно начинать беспокоиться, когда показатель MeasureProcessRate более чем на 30 минут не догоняет скорость входящего потока MQTTmeasure ( MeasureProcessRate < MQTTmeasure ). Эту проблему невозможно решить настройками, она может потребовать больших изменений в замене дисковой подсистемы (переход на быстрые диски), либо логического снижения скорости потока (увеличение порогов измерений, интервалов опроса), поэтому за показателями MeasureProcessMean и и CPUiowaitPostgres нужно следить постоянно.
Проблемы отставания MeasureProcessRate от MQTTmeasure проявляются в приложениях платформы, пользователи могут видеть, что измерения имеют отставание по дате. При этом, поскольку потоки обработки сигнальных значений и событий отделены от потоков измерений, часть измерений (сигналы) и механизмы оповещений будут работать штатно.

Два наиболее наглядных показателя. Если MeasureProcessRate часто начинает отставать от MQTTmeasure - значит есть проблема производительности.
Приведем некоторые цифры для оценки мощности инфраструктуры:

• Поток в 500 измерений в сек. генерит 1 Mbps сетевого трафика на сервере сбора (MQTT брокере).
• Поток в 500 измерений в сек. генерит 10 Mbps входящего и 30 Mbps исходящего сетевого трафика на сервере СУБД
• Весь трафик (10 Mbps и 30 Mbps) происходит между серверами приложений и СУБД.
• Отставание MeasureProcessRate от MQTTmeasure на 1 млн. измерений, для конфигурации Medium означает отставание на 1 час для HDD с IOPS до 1000, и на 15 минут для IOPS > 1000.

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

В настоящее время технические решения, которые точно масштабируют проблему отлика пользователей находятся в разработке. Отклик web-приложений в основном зависит от количества данных, которыми манипулируют приложения. Например, даже если в системе несколько тысяч параметров или объектов, но пользователю доступны до 200 из них, он может не испытывать проблем. Но, если пользователю доступны несколько тысяч объектов, параметров - их загрузка в элементы «дерево объектов», «карта объектов» может занимать до 10 сек. Улучшения работы с большими данными в web-интерфейсе платформы ведется постоянно. После завершения работы по масштабированию rest сервисов в данном разделе будут приведены данные тестов. Ниже даны рекомендации по улучшению пользовательской производительности:

• Систему отчетности не настраивайте на оперативную БД
• При построении дашбордов используйте разумное кол-во параметров на один дашборд (до 1000). При большом кол-ве параметров даш может «тормозить»
• Не рекомендуется использовать на одном даше большое кол-во интервальных виджетов (больше 10) с большим периодом (месяц и более). Такие виджеты могут могут сильно тормозить браузер.