Postgresql
Author |
Message |
Written on: 25. 02. 2014 [00:00]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"roman" wrote:
Ещё погляжу на модуль архиватора DBArch, на предмет его включение при выключенной БД и сохранение указателя обработанных данных буфера, чтобы при восстановлении связи он их перегружал и не терял на глубину буфера.
Для архивации значений это добавил, а вот для сообщений пока нет, поскольку там буфер читается концептуально не по времени, да и попадать могут сообщения туда не последовательно. Хотя подумаю над этим ещё.
Learn, learn and learn better than work, work and work.
|
Written on: 02. 03. 2014 [18:17]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"roman" wrote:
Для архивации значений это добавил, а вот для сообщений пока нет, поскольку там буфер читается концептуально не по времени, да и попадать могут сообщения туда не последовательно. Хотя подумаю над этим ещё.
Переписал архиватор сообщений на предмет обеспечения независимого отслеживания записи из буфера сообщений в архиваторы.
Learn, learn and learn better than work, work and work.
|
Written on: 08. 03. 2014 [10:34]
|
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
|
После просмотра лога Postgresql
у меня возник вопрос
в логе я виде постоянно подключение и отклчение сесий openscada-ой
так и должно быть? или можно как то установить постоянную сесию?
наверное я что - то не допонимаю, но мне кажеться лудше вести общение в постоянной сесии, чем нежели каждый раз обрывать и переподымать ее заново.
часть лога
2014-03-08 09:56:46 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 09:56:46 MSK LOG: unexpected EOF on client connection
2014-03-08 09:58:18 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 09:58:18 MSK LOG: unexpected EOF on client connection
2014-03-08 09:59:50 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 09:59:50 MSK LOG: unexpected EOF on client connection
2014-03-08 10:01:23 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 10:01:23 MSK LOG: unexpected EOF on client connection
2014-03-08 10:03:42 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 10:03:42 MSK LOG: unexpected EOF on client connection
2014-03-08 11:16:55 MSK LOG: could not receive data from client: Соединение разорвано другой стороной
2014-03-08 11:16:55 MSK LOG: unexpected EOF on client connection
еще хотел спросить про потери циклов
я просто не могу понять, по чему иногда они теряются и что при это происходит (выполнится ли шаблон логического параметра до конца или выпонение прервется)
вроде для узла логичского уровня выставил время планирования вычислений 2 сек, а время выполнения шаблона 10сек (максимальное время выпонения шаблона 0.05 сек (вычислил), если идет запись в postgresql)
Можно сылку на инфу про циклы выполнения задач, хочу понять что такое и что влияет на время выполнения цикла
Attachment
scada.png (File type: image/png, Size: 142.71 kilobytes) — 890 downloads
scada2.png (File type: image/png, Size: 77.46 kilobytes) — 893 downloads
|
Written on: 08. 03. 2014 [11:35]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"monia" wrote:
в логе я виде постоянно подключение и отклчение сесий openscada-ой
так и должно быть? или можно как то установить постоянную сесию?
OpenSCADA не обрывает соединений и у меня нет обрывов, исходник смотрим.
Скорее всего плохая связь и соединение обрывается из-за потери пакетов.
"monia" wrote:
еще хотел спросить про потери циклов
я просто не могу понять, по чему иногда они теряются и что при это происходит (выполнится ли шаблон логического параметра до конца или выпонение прервется)
Потому что время выполнения задачи выходит за время заявленного цикла, например, по таймауту PostgreSQL, когда потерялось подключение.
А так-же пользовательское планирование циклических вызовов не гарантирует строгого соблюдения цикличности, если это не RT политика.
Learn, learn and learn better than work, work and work.
|
Written on: 08. 03. 2014 [17:45]
|
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
|
в итоге цикл выполнится до конца или он завершиться по таймауту и часть параметров не обработается?
мое понимание выполнения цикла:
+ логический уровень
----+ контроллер (планирование вычислений - как часто они будут запускаться)
---------+ параметр 1 (в используемом шаблоне, максимальное время вычисление - по истечению которого идет принудительное завершение потока)
---------+ параметр 2
,,,,,,,,,,,,,,,,,,,,
---------+ параметр n
как я понял, при старте обсчета контроллера запускаются потоки обсчета параметров, которые принудительно завершаться по таймауту ( максимальное время вычисление), если они сами не завершили свою работу.
По идеи не принципиально как часто будет запускаться обсчет контроллера. Главное, что бы корректно завершился обсчет параметра, в этом случае все вычисления произведутся полностью.
И если обсчет контроллера не завершился до начала нового обсчета, то обсчет продолжиться до завершения и параллельно ему начнется новый обсчет контроллера
Я правильно рассуждаю? если нет, подкинь нужную инфу, хочу все таки в этом разобраться
[This article was edited 1 times, at last 08.03.2014 at 17:47.]
|
Written on: 08. 03. 2014 [21:17]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"monia" wrote:
в итоге цикл выполнится до конца или он завершиться по таймауту и часть параметров не обработается?
Выполнение может прерваться только таймаутом безопасности. В случае с LogicLev прерывается только шаблон виновник.
"monia" wrote:
как я понял, при старте обсчета контроллера запускаются потоки обсчета параметров, которые принудительно завершаться по таймауту ( максимальное время вычисление), если они сами не завершили свою работу.
Поток для объекта контроллера один и принудительно он не завершается
"monia" wrote:
И если обсчет контроллера не завершился до начала нового обсчета, то обсчет продолжиться до завершения и параллельно ему начнется новый обсчет контроллера
Не начинается ничего нового. Один объект контроллера — одна задача!
Learn, learn and learn better than work, work and work.
|
Written on: 08. 03. 2014 [22:09]
|
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
|
спасибо за разъяснение
|
Written on: 11. 03. 2014 [07:22]
|
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
|
Рома, после обновления OpenSCADA возникла проблема с PostreSQL, только при архивирование сообщений и параметров
лог PostreSQL:
2014-03-11 09:12:21 MSK STATEMENT: SELECT count(*) FROM pg_catalog.pg_class c JOIN pg_catalog.pg_roles r ON r.oid = c.relowner LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','v','S','') AND n.nspname <> 'pg_catalog' AND n.nspname !~ '^pg_toast' AND pg_catalog.pg_table_is_visible(c.oid) AND c.relname = 'DBAMsg_r01k092_Arch'
2014-03-11 09:12:21 MSK ERROR: current transaction is aborted, commands ignored until end of transaction block
2014-03-11 09:12:21 MSK STATEMENT: SELECT count(*) FROM pg_catalog.pg_class c JOIN pg_catalog.pg_roles r ON r.oid = c.relowner LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','v','S','') AND n.nspname <> 'pg_catalog' AND n.nspname !~ '^pg_toast' AND pg_catalog.pg_table_is_visible(c.oid) AND c.relname = 'DBAMsg_r01k093_Arch'
2014-03-11 09:12:21 MSK ERROR: current transaction is aborted, commands ignored until end of transaction block
2014-03-11 09:12:21 MSK STATEMENT: SELECT count(*) FROM pg_catalog.pg_class c JOIN pg_catalog.pg_roles r ON r.oid = c.relowner LEFT JOIN pg_catalog.pg_namespace n ON n.oid = c.relnamespace WHERE c.relkind IN ('r','v','S','') AND n.nspname <> 'pg_catalog' AND n.nspname !~ '^pg_toast' AND pg_catalog.pg_table_is_visible(c.oid) AND c.relname = 'DBAMsg_r01k094_Arch'
а сама OpenSCADA говорит:
3|/sub_BD/mod_PostgreSQL/db_oscada_AM/ | Ошибка запуска транзакции!
3|/sub_BD/mod_PostgreSQL/db_oscada_AM/ | Ошибка запуска транзакции!
4|/sub_BD/mod_PostgreSQL/db_oscada_AM/ | Ошибка запроса к БД: PGRES_FATAL_ERROR. ERROR: current transaction is aborted, commands ignored until end of transaction block
4|/sub_Archive/ | Message buffer process error.
Ошибки перестали валиться в лог, после отключения архивирования сообщений и параметров
[This article was edited 1 times, at last 11.03.2014 at 07:23.]
|
Written on: 11. 03. 2014 [09:18]
|
roman
Roman Savochenko
Moderator Contributor Developer
registered since: 12.12.2007
Posts: 3750
|
"monia" wrote:
Рома, после обновления OpenSCADA возникла проблема с PostreSQL, только при архивирование сообщений и параметров
Обновление тут не причём, поскольку работа с транзакциями там не менялась.
А проблема в том, что Вы меня не слушали про проблемы прямого использования транзакций при немонопольном доступе к БД и затулили в свои запросы
сбивающие входы-выходы в транзакции почему и получили это!
Ещё раз повторяю, если используете БД из разных узлов OpenSCADA то и транзакционный механизм используете из OpenSCADA иначе и будете получать то, что получаете!
"monia" wrote:
Ошибки перестали валиться в лог, после отключения архивирования сообщений и параметров
Тоже произойдёт если прибрать Вашу левую задачу!
Learn, learn and learn better than work, work and work.
|
Written on: 11. 03. 2014 [14:17]
|
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
|
Т.е. если я использую архиватор OpenSCADA, то я должен создать в PostgerSQL БД, к которой будет иметь доступ только один пользователь (к примеру User)
Соответственно OpenSCADA должна работать с архивами только через этого пользователя (User), а выполнение моих SQL запросов должно происходить в другие БД и через других пользователей?
|
|
|