EnglishУкраїнськаmRussian
Login/New
Topic with many replies

Postgresql


Author Message
Written on: 11. 02. 2014 [07:14]
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
Из-за большого количества (примерно 500 и >>) мелких и одновременных запросов к БД падает соединение
OpenSCADA просто перестает (по понятным причинам) слать SQL запросы.

Вопросы:
1) после такого обрыва, OpenSCADA подымает связь с БД? (у меня соединение с БД появилось после ручного выкл и вкл в узле "Postgresql.Базы данных")
2) архив сообщений копит пачку сообщений и потом ее отсылает в БД? или отправляет их по одиночки?
3) есть ли в OpenSCADA какая ни будь возможность формирования пачки запросов, для отправления ее одним запросом в БД?

Хочется найти элегантное решение моей проблем (куча мелких и практически одновременных запросов к БД, из-за которых происходит падение).
Как вариант придумал обходиться рандомом временной задержки SQL запросов, но это не очень красиво :) и выглядит как костыль :)

Written on: 11. 02. 2014 [08:36]
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
заметил такую штуку
если связь с Postgresql падает
то OpenSCADA ни как не реагирует(не выдает ошибку соединения), она мне выдала ее только при заходе в узел "Postgresql.Базы данных"

и еще, стоило мне отключить архиватор сообщений, как все запахало как нужно, с чем это связанно не знаю.
проверял несколько раз, при запуске архиватора все падало и не работало, как только его убираю все пашет



[This article was edited 1 times, at last 11.02.2014 at 11:18.]
Attachment

Снимок экрана - 11.02.2014 - 13:14:06.png (File type: image/png, Size: 364.08 kilobytes) — 1884 downloads
Снимок экрана - 11.02.2014 - 13:15:55.png (File type: image/png, Size: 291.13 kilobytes) — 1858 downloads
Written on: 11. 02. 2014 [11:42]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"monia" wrote:

Из-за большого количества (примерно 500 и >>) мелких и одновременных запросов к БД падает соединение
OpenSCADA просто перестает (по понятным причинам) слать SQL запросы.

Одновременными к одной БД они не могут быть в принципе.

"monia" wrote:

1) после такого обрыва, OpenSCADA подымает связь с БД? (у меня соединение с БД появилось после ручного выкл и вкл в узле "Postgresql.Базы данных")

Если "PQstatus(connection) != CONNECTION_OK" то переподключается иначе нужно смотреть ошибку в данном случае.

"monia" wrote:

2) архив сообщений копит пачку сообщений и потом ее отсылает в БД? или отправляет их по одиночки?

Очередной раз повторяю, что БД (любая) это не место для ведения больших архивов по многим причинам, одна из которых эта!
Архив сообщений хоть и копит но в случае БД шлёт отдельно. Во первых по причине того, что унифицирующий интерфейс OpenSCADA над БД работает с отдельными записями (строками). Во вторых многие БД просто не позволяют отправлять несколько запросов одновременно, как то в случае с MySQL такая возможность только недавно включилась, а некоторые вообще имеют проблемы с размером даже одного запроса SQL, как то FireBird.

"monia" wrote:

3) есть ли в OpenSCADA какая ни будь возможность формирования пачки запросов, для отправления ее одним запросом в БД?

Создавайте отдельную процедуру архивирования на БД и шлите как угодно, прямыми SQL-запросами. Только по причинам выше это у Вас вряд-ли получится.

"monia" wrote:

Хочется найти элегантное решение моей проблем (куча мелких и практически одновременных запросов к БД, из-за которых происходит падение).
Как вариант придумал обходиться рандомом временной задержки SQL запросов, но это не очень красиво :) и выглядит как костыль :)

Ну да, и без того немалое время доступа к БД увеличивается ещё более.

Learn, learn and learn better than work, work and work.
Written on: 11. 02. 2014 [11:50]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"monia" wrote:

и еще, стоило мне отключить архиватор сообщений, как все запахало как нужно, с чем это связанно не знаю.
проверял несколько раз, при запуске архиватора все падало и не работало, как только его убираю все пашет

Что значит падало? Слова подбирайте согласно ситуации.
У меня проверять не на чем сейчас, разве только в конце недели.

Learn, learn and learn better than work, work and work.
Written on: 11. 02. 2014 [13:43]
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
С пачками стало все ясно, спасибо за разъяснение

Оптимизировал код шаблонов, вроде полегче стало, буду тестировать :), без архиватора.

Я собираюсь немного поколдовать с настройками производительности Postgresql
может еще лучше станет

PQstatus(connection) != CONNECTION_OK

а ссылку на описание можно? или данный код взят из исходников OpenSCADA?

Written on: 11. 02. 2014 [14:54]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"monia" wrote:

PQstatus(connection) != CONNECTION_OK

а ссылку на описание можно? или данный код взят из исходников OpenSCADA?

А Вы про что спрашивали? Конечно из OpenSCADA!

Learn, learn and learn better than work, work and work.
Written on: 12. 02. 2014 [11:09]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"roman" wrote:

У меня проверять не на чем сейчас, разве только в конце недели.

Проверил: не восстанавливает подключение, что не хорошо для сетевой БД.
Добавил возможность включения БД даже в случае отсутствия соединения и попытки восстановления подключения при запросах к БД. Так-же уменьшил умолчательный таймаут подключения до 1 секунды.
В MySQL тоже добавил возможность включения БД при отсутствии соединения, хотя восстановление там было.
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.


Learn, learn and learn better than work, work and work.
Written on: 18. 02. 2014 [12:56]
monia
Олег Намятов
Topic creator
registered since: 21.05.2012
Posts: 173
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.

Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ

[This article was edited 1 times, at last 18.02.2014 at 13:01.]
Written on: 19. 02. 2014 [10:30]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"monia" wrote:

Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.

Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ

Наверное не скоро, поскольку c FireBird быстро не получилось в виду отсутствия там прямого механизма проверки состояния подключения (во всяком случае пока не нашёл) и запутанного механизма транзакций.

Но для PostgreSQL обновиться Вам ничего не мешает!

Learn, learn and learn better than work, work and work.
Written on: 24. 02. 2014 [12:10]
roman
Roman Savochenko
Moderator
Contributor
Developer
registered since: 12.12.2007
Posts: 3750
"roman" wrote:

"monia" wrote:

Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.

Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ

Наверное не скоро, поскольку c FireBird быстро не получилось в виду отсутствия там прямого механизма проверки состояния подключения (во всяком случае пока не нашёл) и запутанного механизма транзакций.

Пересмотрел концепцию восстановления подключений сетевых БД на отключение БД в случае отсутствия подключения и периодические попытки включить БД (раз в 10 секунд). Что облегчает доступ к БД в целом, исключая попытки переподключения при каждом запросе и ступор на таймаутах при этом. А также сам механизм доступа БД заметно упрощается.
Прогнал тесты на восстановление подключения и общие тесты БД в Special.SystemTests для FireBird, MySQL, PostgreSQL.

Ещё погляжу на модуль архиватора DBArch, на предмет его включение при выключенной БД и сохранение указателя обработанных данных буфера, чтобы при восстановлении связи он их перегружал и не терял на глубину буфера.

Learn, learn and learn better than work, work and work.



22295