СТА №2/2017

● на стороне приёмника данных фор- мируются запросы с выборкой 100 тыс., 1 млн значений к БД архива и замеряется время их выполне- ния; запросы должны ограничивать выборку (табл. 2) по глубине таким образом, чтобы размер архива не влиял на длительность выполнения запроса (например, ограничение по временному периоду, количеству па- раметров и т.д.). Оценка скорости чтения параметров Описание сценария: ● на стороне приёмника данных за- пускается запрос на выборку зна- чений из архива (не менее) 50 000, 150 000, 450 000, 1 350 000, 4 050 000 значений; ● оценивается время выполнения каж- дого из запросов; ● на стороне приёмника данных парал- лельно запускается несколько запро- сов на выборку не менее 500 000 зна- чений из архива: 3, 6, 10, 30 запросов (при наличии возможности); ● оценивается время выполнения за- просов (наибольшее значение); за- просы должны ограничивать вы- борку (табл. 3) по глубине таким об- разом, чтобы размер архива не вли- ял на длительность выполнения за- проса (например, ограничение по временному периоду, количеству па- раметров и т.д.). Оценка выполнения расчётов и их влияние на загрузку системы Описание сценария: ● на имитаторе данных создаётся OPC-сервер с 10 000 аналоговых па- раметров; ● создаётся скрипт, позволяющий гене- рировать значения параметров; ● на стороне приёмника данных подго- тавливается 10 000 тегов с подпиской на параметры источника данных; ● на стороне приёмника данных подго- тавливается 5 000 расчётных тегов, рассчитываемых по формуле: значение расчётного тега = среднеe значение [исходный тег OPC]; ● для расчёта используется массив из 500 последних архивных значений исходного тега OPC; ● расчёт должен производиться в режи- ме «по изменению»; ● на стороне приёмника данных подго- тавливается 5 000 расчётных тегов, рассчитываемых по формуле: значение расчётного тега = средне- квадратичное отклонение [исходный тег OPC]; ● для расчёта используется массив из 500 последних архивных значений исходного тега OPC; ● расчёт должен производиться в режи- ме «по изменению»; ● инициируется генерация значений с дискретностью 1 секунда длитель- ностью 10 минут; ● на стороне приёмников данных оцени- вается полнота архива сборных и рас- чётных параметров и загрузка системы: уровень загрузки процессора, свобод- ной оперативной памяти (табл. 4); ● производится сравнение параметров загрузки системы с аналогичным сце- нарием без выполнения расчётов. Как видно из приведённых примеров, система успешно справлялась со всеми запросами и изменяемыми нагрузками. Хорошим знаком является то, что с уве- личением количества обрабатываемой информации в относительных цифрах происходит оптимизация работы кла- стера, то есть работа под нагрузкой и с большими данными для кластера яв- ляется оптимальным режимом функ- ционирования. Р ЕКОМЕНДАЦИИ Выбор аппаратной части следует осу- ществлять с привязкой к размерности предполагаемых задач. Для рассмотрен- ных в ходе тестирования задач нет не- обходимости использовать большие мас- сивно-параллельные платформы для вы- числений, достаточно двух либо трёх двухсокетных вычислительных узлов. Для эффективного решения задач большей размерности (> 500 тыс. точек) либо решения оптимизационных задач целесообразно использование вычисли- тельной мощности нескольких узлов, блейд-системы отлично подходят для реализации проектов в области АСУ ТП, когда дело касается обработки больших данных. Также значительным преиму- ществом такого «железа» становится от- казоустойчивость и возможность линей- ного наращивания вычислительных способностей. Стоит отметить, что выпущена новая версия 10.95 программного обеспечения от IСONICS, которая уже показала значительное повышение производи- тельности по результатам вычислений, но на момент написания статьи она находи- лась на бета-тестировании. Официаль- ные данные по производительности теку- щего релиза можно найти на DVD-диске компании ПРОСОФТ или ICONCIS со- ответствующей версии. Документ назы- вается “Hyper Historian Performance”. Всё, что касается работы программ- ного комплекса, будет раскрыто в сле- дующей статье по этой тематике. ● Авторы – сотрудники фирмы ПРОСОФТ Телефон: (495) 234-0636 E-mail: info@prosoft.ru 28 СТА 2/2017 ОБ ЗОР / Т Е Х НОЛОГ ИИ www.cta.ru Таблица 2 Оценка загрузки системы при изменении количества собираемых параметров Параметры Количество тегов 10 000 30 000 50 000 100 000 Загрузка процессора при сохранении данных, % 3,60 9,60 14,50 22,80 Использование оперативной памяти при сохранении данных, Мбайт 1240,00 2050,00 2520,00 3340,00 Загрузка процессора при сборе данных, % 4,60 8,60 11,90 19,50 Использование оперативной памяти при сборе данных, Мбайт 930,00 1420,00 1790,00 2250,00 Время обработки 100 000 значений, с 7,60 7,70 7,80 7,60 Время обработки 1 000 000 значений, с 63,00 62,00 65,00 61,00 Таблица 3 Оценка скорости чтения параметров Тест на количество читаемых значений Количество значений Менее 50 000 50 000… 150 000 150 000… 450 000 450 000… 350 000 1 350 000... 4 050 000 Время обработки, с 3,40 9,30 29,20 86,80 254,40 Тест на количество запросов Количество запросов с выборкой более 500 000 3 6 10 30 Максимальное время выполнения, с 37 68 107 384 Таблица 4 Влияние выполнения расчётов на загрузку системы Параметр С расчётом Без расчёта Загрузка процессора, % 65,70 7,10 Использование оперативной памяти, Мбайт 7200 1870