| Автор |
Сообщение |
|
Сообщение создано: 08. 07. 2009 [19:09]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Есть две станции, соединённые 100 мбит/сек ethernet (сеть не нагружена, пинги <= 1мсек):
1. Имеет на логическом уровне 8 контроллеров по 83 параметра в каждом с периодом обновления 100 мсек (загрузка процессора 40-50%, свободно ram 80%, своп отсутствует, обмен с HDD близок к нулю, трафик в сеть 5-10 кбайт/сек)
2. Имеет в шлюзе данных отражение логического уровня станции 1 с периодом обновления 1000 мсек, так как фактический опрос колеблется от 100 до 800 мсек (загрузка процессора 50-60%, свободно ram 60%, своп есть, но не используется, обмен с HDD 2-5 кбайт/сек, трафик в сеть 5-10 кбайт/сек.)
Передаваемых параметров много, но, судя по всему, есть запас ресурсов для увеличения производительности шлюза данных, которая составляет в среднем около 500 мсек на каждый контроллер логического уровня.
Возникли вопросы:
1. Где затор данных (асинхронный метод сбора данных через шлюз, группировка множества параметров в пакеты протокола self или др.)?
2. Как можно улучшить производительность шлюза данных до значения 100 мсек?
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 07. 2009 [09:07]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
1. Имеет на логическом уровне 8 контроллеров по 83 параметра в каждом с периодом обновления 100 мсек (загрузка процессора 40-50%, свободно ram 80%, своп отсутствует, обмен с HDD близок к нулю, трафик в сеть 5-10 кбайт/сек)
Модель убрали? Или это у Вас такая логика в контроллерах?
almaz wrote:
2. Имеет в шлюзе данных отражение логического уровня станции 1 с периодом обновления 1000 мсек, так как фактический опрос колеблется от 100 до 800 мсек (загрузка процессора 50-60%, свободно ram 60%, своп есть, но не используется, обмен с HDD 2-5 кбайт/сек, трафик в сеть 5-10 кбайт/сек.)
Передаваемых параметров много, но, судя по всему, есть запас ресурсов для увеличения производительности шлюза данных, которая составляет в среднем около 500 мсек на каждый контроллер логического уровня.
Если 500 на каждый, то у вас должно было выйти 4 секунды. 
Они то запрашивают один источник, а значит и грузят его одновременно, в целом увеличивая время опроса каждого контроллера.
almaz wrote:
1. Где затор данных (асинхронный метод сбора данных через шлюз, группировка множества параметров в пакеты протокола self или др.)?
Для этого нужно проводить полноценный анализ, т.е. профайлинг этого процесса.
almaz wrote:
2. Как можно улучшить производительность шлюза данных до значения 100 мсек?
Делать выводы из профайлинга и выполнять оптимизацию.
Сейчас я этого делать не буду. Сейчас главное стабильность.
Из наиболее доступных и видимых решений это выключить, если включена, упаковку трафика по протоколу SelfSystem.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 07. 2009 [09:34]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
В контроллерах логического уровня всего лишь массив переменных, которые обрабатываются блочным вычислителем. Все написано с чистой базы OpenSCADA.
4 секунды не получается они же работают параллельно.
Абсолютно согласен, что главное стабильность. Просто хотелось сделать динамичную визуализацию реального времени с периодом в 100 мсек. Ну да ладно пока устраивает и 1 сек.
Зато мы знаем, что Вы знаете, что есть еще резервы для увеличения производительности.
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 07. 2009 [10:29]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
В контроллерах логического уровня всего лишь массив переменных, которые обрабатываются блочным вычислителем. Все написано с чистой базы OpenSCADA.
А проц тогда какой? У меня полноценная модель большого ТП на 40% проца 2ГГц ест.
almaz wrote:
Зато мы знаем, что Вы знаете, что есть еще резервы для увеличения производительности.
Это какие-же? Я профайлинга не проводил.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 07. 2009 [11:05]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Да у нас 1 станция - миникомпьютер-контроллер с 1 ГГц процессором. В OpenSCADA, в основном, работают логический уровень, блочный вычислитель и сбор данных. ТП можно классифицировать как средний.
Упаковка/неупаковка пакетов протокола Self уменьшает/увеличивает кол-во трафика, а на производительность не влияет или влияет слабо.
Вроде нашел способ увеличить производительность:
- контроллеры шлюза данных, содержащие около 5 параметров, пролетают через сеть за 10-50 мсек;
- контроллеры, содержащие около 10 параметров, за 30-100 мсек;
- контроллеры, содержащие около 80 параметров, за 100-800 мсек.
Причем это независимо от количества контроллеров.
Так что, думаю, надо правильно расставить переменные для передачи через шлюз, задать правильно периоды сбора контроллеров шлюза и все будет хорошо.
[Сообщение редактировалось 1 раз(а), в последний раз 09.07.2009 в 11:06.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 07. 2009 [12:18]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
almaz wrote:
Вроде нашел способ увеличить производительность:
- контроллеры шлюза данных, содержащие около 5 параметров, пролетают через сеть за 10-50 мсек;
- контроллеры, содержащие около 10 параметров, за 30-100 мсек;
- контроллеры, содержащие около 80 параметров, за 100-800 мсек.
Причем это независимо от количества контроллеров.
Так что, думаю, надо правильно расставить переменные для передачи через шлюз, задать правильно периоды сбора контроллеров шлюза и все будет хорошо.
Врядли. Исходящие транспорты сейчас работают монопольно, следовательно пока он не дождётся ответа запроса первого контроллера остальные будут ждать.
Попробую сейчас добавить разные идентификаторы источников транспортов, для разных контроллеров. В таком случае будут создаваться разные исходящие транспорты для разных контроллеров и запросы будут параллельны.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 07. 2009 [12:59]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
А, если в модуле "Транспорты" станции 2 добавить несколько внешних хостов с одним IP адресом и разными портами (соответственно на станции 1 добавить несколько входных сокетов), и каждый контроллер шлюза данных пустить через свой отдельный шлюз?
Конечно тогда это получится не список внешних хостов, а список шлюзов.
[Сообщение редактировалось 1 раз(а), в последний раз 09.07.2009 в 13:00.]
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 09. 07. 2009 [13:31]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3750
|
Уже сделал. Теперь создаются и используются отдельные транспорты на контроллер. Пробуйте.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 09. 07. 2009 [19:37]
|
|
almaz
Almaz Karimov
Contributor
Создатель темы
Зарегистрирован(а) с: 25.09.2008
Сообщения: 516
|
Спасибо!!! Скачал 928 срез. Будем тестировать
21 век - век повсеместной автоматизации. Главное - во благо всем людям.
|
|
Сообщение создано: 10. 07. 2009 [09:54]
|
|
Aleksey
Aleksey Popkov
Contributor
Зарегистрирован(а) с: 31.07.2008
Сообщения: 326
|
almaz wrote:
Спасибо!!! Скачал 928 срез. Будем тестировать
Как там тестирование прошло ? Интересно весьма.
|
