| Автор |
Сообщение |
|
Сообщение создано: 11. 02. 2014 [07:14]
|
|
monia
Олег Намятов
Создатель темы
Зарегистрирован(а) с: 21.05.2012
Сообщения: 173
|
Из-за большого количества (примерно 500 и >>) мелких и одновременных запросов к БД падает соединение
OpenSCADA просто перестает (по понятным причинам) слать SQL запросы.
Вопросы:
1) после такого обрыва, OpenSCADA подымает связь с БД? (у меня соединение с БД появилось после ручного выкл и вкл в узле "Postgresql.Базы данных")
2) архив сообщений копит пачку сообщений и потом ее отсылает в БД? или отправляет их по одиночки?
3) есть ли в OpenSCADA какая ни будь возможность формирования пачки запросов, для отправления ее одним запросом в БД?
Хочется найти элегантное решение моей проблем (куча мелких и практически одновременных запросов к БД, из-за которых происходит падение).
Как вариант придумал обходиться рандомом временной задержки SQL запросов, но это не очень красиво :) и выглядит как костыль :)
|
|
Сообщение создано: 11. 02. 2014 [08:36]
|
|
monia
Олег Намятов
Создатель темы
Зарегистрирован(а) с: 21.05.2012
Сообщения: 173
|
заметил такую штуку
если связь с Postgresql падает
то OpenSCADA ни как не реагирует(не выдает ошибку соединения), она мне выдала ее только при заходе в узел "Postgresql.Базы данных"
и еще, стоило мне отключить архиватор сообщений, как все запахало как нужно, с чем это связанно не знаю.
проверял несколько раз, при запуске архиватора все падало и не работало, как только его убираю все пашет
[Сообщение редактировалось 1 раз(а), в последний раз 11.02.2014 в 11:18.]
Вложенный файл
|
|
Сообщение создано: 11. 02. 2014 [11:42]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"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.
|
|
Сообщение создано: 11. 02. 2014 [11:50]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"monia" wrote:
и еще, стоило мне отключить архиватор сообщений, как все запахало как нужно, с чем это связанно не знаю.
проверял несколько раз, при запуске архиватора все падало и не работало, как только его убираю все пашет
Что значит падало? Слова подбирайте согласно ситуации.
У меня проверять не на чем сейчас, разве только в конце недели.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 11. 02. 2014 [13:43]
|
|
monia
Олег Намятов
Создатель темы
Зарегистрирован(а) с: 21.05.2012
Сообщения: 173
|
С пачками стало все ясно, спасибо за разъяснение
Оптимизировал код шаблонов, вроде полегче стало, буду тестировать :), без архиватора.
Я собираюсь немного поколдовать с настройками производительности Postgresql
может еще лучше станет
PQstatus(connection) != CONNECTION_OK
а ссылку на описание можно? или данный код взят из исходников OpenSCADA?
|
|
Сообщение создано: 11. 02. 2014 [14:54]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"monia" wrote:
PQstatus(connection) != CONNECTION_OK
а ссылку на описание можно? или данный код взят из исходников OpenSCADA?
А Вы про что спрашивали? Конечно из OpenSCADA!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 12. 02. 2014 [11:09]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"roman" wrote:
У меня проверять не на чем сейчас, разве только в конце недели.
Проверил: не восстанавливает подключение, что не хорошо для сетевой БД.
Добавил возможность включения БД даже в случае отсутствия соединения и попытки восстановления подключения при запросах к БД. Так-же уменьшил умолчательный таймаут подключения до 1 секунды.
В MySQL тоже добавил возможность включения БД при отсутствии соединения, хотя восстановление там было.
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 18. 02. 2014 [12:56]
|
|
monia
Олег Намятов
Создатель темы
Зарегистрирован(а) с: 21.05.2012
Сообщения: 173
|
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.
Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ
[Сообщение редактировалось 1 раз(а), в последний раз 18.02.2014 в 13:01.]
|
|
Сообщение создано: 19. 02. 2014 [10:30]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"monia" wrote:
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.
Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ
Наверное не скоро, поскольку c FireBird быстро не получилось в виду отсутствия там прямого механизма проверки состояния подключения (во всяком случае пока не нашёл) и запутанного механизма транзакций.
Но для PostgreSQL обновиться Вам ничего не мешает!
Learn, learn and learn better than work, work and work.
|
|
Сообщение создано: 24. 02. 2014 [12:10]
|
|
roman
Roman Savochenko
Moderator Contributor Developer
Зарегистрирован(а) с: 12.12.2007
Сообщения: 3747
|
"roman" wrote:
"monia" wrote:
Позже проверю работу без подключения для FireBird и для всех сетевых БД прогоню тесты подключения и восстановления подключений.
Можешь отписаться, когда сделаешь
Что бы обновить САКАДУ
Наверное не скоро, поскольку c FireBird быстро не получилось в виду отсутствия там прямого механизма проверки состояния подключения (во всяком случае пока не нашёл) и запутанного механизма транзакций.
Пересмотрел концепцию восстановления подключений сетевых БД на отключение БД в случае отсутствия подключения и периодические попытки включить БД (раз в 10 секунд). Что облегчает доступ к БД в целом, исключая попытки переподключения при каждом запросе и ступор на таймаутах при этом. А также сам механизм доступа БД заметно упрощается.
Прогнал тесты на восстановление подключения и общие тесты БД в Special.SystemTests для FireBird, MySQL, PostgreSQL.
Ещё погляжу на модуль архиватора DBArch, на предмет его включение при выключенной БД и сохранение указателя обработанных данных буфера, чтобы при восстановлении связи он их перегружал и не терял на глубину буфера.
Learn, learn and learn better than work, work and work.
|
