| Автор |
Повідомлення |
|
Повідомлення створено: 18. 06. 2014 [13:55]
|
|
Alexx
Александр Иванов
Автор теми
Зареєстрован(а) с: 16.07.2012
Повідомлення: 64
|
Тем не менее архивация происходит (это видно в БД). Настройки времени были сделаны что называется от балды, как возможное временное решение. С такими настройками интерфейс тормозиться на меньшее время и позволяет хоть немного работать, хотя и очень проблемно.
|
|
Повідомлення створено: 18. 06. 2014 [14:01]
|
|
Alexx
Александр Иванов
Автор теми
Зареєстрован(а) с: 16.07.2012
Повідомлення: 64
|
Когда я поочередно ставил флаги архивирования на всех параметрах (сейчас подсчитал- их у меня 171) у меня на 9 параметров уходило тоже около 0,5сек. При периодичности 10 секунд и периоде 60 секунд. И интерфейс не тормозил. После того как я добавил все остальные - появились дикие тормоза.
|
|
Повідомлення створено: 18. 06. 2014 [14:04]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Alexx" wrote:
Тем не менее архивация происходит (это видно в БД). Настройки времени были сделаны что называется от балды, как возможное временное решение. С такими настройками интерфейс тормозиться на меньшее время и позволяет хоть немного работать, хотя и очень проблемно.
Я и не говорил, что архивации так не будет вообще, просто реально она происходит в каждом четвёртом цикле и архивируется одно значение по каждому параметру при этом из-за медленного доступа к БД одно значение пропускается, раз реальная запись занимает 27 секунд.
Ну и интерфейс меньше так блокируется просто потому, что БД блокируется на 27 секунд, но часто вместо 2 минут, но редко.
В любом случае это проблема времени доступа к БД!
P.S. Мне вообще не понятен смысл использования сетевой БД, в вашем случай! Согласно логике, и OpenSCADA обычно конфигурируется таким образом, данные используемые локально, особенно если они тут и формируются, архивируются на локальные архивы, что гарантирует быстроту доступа к ним. А те данные, которые нужны внешним системам уже архивируются на сетевые БД и редко когда с периодичностью меньше 60 секунд, при этом локально данные на сетевой БД никак не используются.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 18. 06. 2014 [15:46]
|
|
Alexx
Александр Иванов
Автор теми
Зареєстрован(а) с: 16.07.2012
Повідомлення: 64
|
Спасибо. Поковыряли сервер БД. В результате время архивирования при периодичности 10сек. и периодом архивирования 60 сек. с ~5 мин. сократилось до 8-9 сек. Пока тормозов не наблюдаю.
"roman" wrote:
Мне вообще не понятен смысл использования сетевой БД, в вашем случай! Согласно логике, и OpenSCADA обычно конфигурируется таким образом, данные используемые локально, особенно если они тут и формируются, архивируются на локальные архивы, что гарантирует быстроту доступа к ним. А те данные, которые нужны внешним системам уже архивируются на сетевые БД и редко когда с периодичностью меньше 60 секунд, при этом локально данные на сетевой БД никак не используются.
У меня данные, которые используются локально, локально же и архивируются. Просто параллельно еще и архивируются на сетевой БД для других целей, не связанных непосредственно с техпроцессом и обрабатываются эти данные тоже удаленно.
[Повідомлення редагувалось 1 раз(ів), останній раз 19.06.2014 в 11:15.]
|
|
Повідомлення створено: 19. 06. 2014 [12:55]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Alexx" wrote:
Спасибо. Поковыряли сервер БД. В результате время архивирования при периодичности 10сек. и периодом архивирования 60 сек. с ~5 мин. сократилось до 8-9 сек. Пока тормозов не наблюдаю.
Да, это уже близко к моим значениям.
"Alexx" wrote:
У меня данные, которые используются локально, локально же и архивируются. Просто параллельно еще и архивируются на сетевой БД для других целей, не связанных непосредственно с техпроцессом и обрабатываются эти данные тоже удаленно.
Как-же интерфейс тогда лочится если используются локальные данные? Вы как и какие архивные данные используете в визуальном интерфейсе?
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 19. 06. 2014 [14:41]
|
|
Alexx
Александр Иванов
Автор теми
Зареєстрован(а) с: 16.07.2012
Повідомлення: 64
|
Попробую объяснить на картинках. Надеюсь будет понятно. На картинке 4 архивируемые параметры. На картинке 5 архиватор локальный на файловую систему. На картинке 6 использование архивных данных.
П.С. Сейчас осенило: при построении трендов указывается только имя архивируемого параметра, но не указывается откуда он берется из локальной базы или удаленной. А так как имена у них одинаковые может они берутся из удаленной? Как тогда правильнее сделать?
|
|
Повідомлення створено: 19. 06. 2014 [16:56]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Alexx" wrote:
П.С. Сейчас осенило: при построении трендов указывается только имя архивируемого параметра, но не указывается откуда он берется из локальной базы или удаленной. А так как имена у них одинаковые может они берутся из удаленной? Как тогда правильнее сделать?
Один параметр с архивацией его различными архиваторами это нормально.
Выбор-же архиватора зависит от того какие периодичности у локального архиватора и сетевого, а так-же ширина окна тренда. Порядок вообще такой, при выборе архиватора в режиме "Все":
- Если периодичность данных, нужных для тренда (время точки в пикселе обычно), меньше чем есть архиваторы, то берётся самый "качественный-детальный" (меньшая периодичность).
- Если периодичность точки в тренде достигает низкокачественного архиватора, скажем 10 секунд для сетевого, то берётся из него.
Я тут подумал, что нужно добавить приоритетность используемого архиватора, как минимум при одной периодичности, что-бы он при запросе выбирал всегда локальный, если он есть.
Сейчас-же, в тех-же трендах, можно принудительно указать использование только локального архиватора, хотя конечно он и данные из буфера показывать не будет.
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 25. 06. 2014 [15:04]
|
|
Alexx
Александр Иванов
Автор теми
Зареєстрован(а) с: 16.07.2012
Повідомлення: 64
|
Вчера были проблемы с сервером MySQL. Соответственно данные туда не писались некоторое время. Сегодня просматривая графики обнаружил, что часть данных как раз за это время не отображается. Похоже что для отрисовки графиков данные берутся из удаленной базы. В текущей версии СКАДы можно каким нибудь способом указать из каких архивов брать данные для трендов из локальных или удаленных?
|
|
Повідомлення створено: 25. 06. 2014 [21:35]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"Alexx" wrote:
В текущей версии СКАДы можно каким нибудь способом указать из каких архивов брать данные для трендов из локальных или удаленных?
Да, я говорил, указанием архиватора в тренде. Т.е. если там пусто то это фактически "Все", где нет ещё приоритета, который позволил-бы учитывать время доступа и наверное ещё статус наличие связи.
Т.е. указать скажем: FSArch.10s (зависит от реального названия).
Learn, learn and learn better than work, work and work.
|
|
Повідомлення створено: 02. 07. 2014 [22:50]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зареєстрован(а) с: 12.12.2007
Повідомлення: 3750
|
"roman" wrote:
Я тут подумал, что нужно добавить приоритетность используемого архиватора, как минимум при одной периодичности, что-бы он при запросе выбирал всегда локальный, если он есть.
Добавил приоритетность и теперь, по умолчанию, FSArch сильно приоритетнее чем DBArch, а также архиватор можно из выбора исключить вообще, нулём. Кроме того, если DBArch недоступен по отсутствию связи то будет подставляться следующий доступный.
Learn, learn and learn better than work, work and work.
|
