Тема / Topic: Проблемы ТМ v 6.05.1 при работе ч/з ODBC с БД
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Уважаемые Господа разработчики! Открываем новый топик, так как в топике "Настройка времени цикла монитора" раздела "Мониторы реального времени" тема сменилась на работу с SQL/ После продолжительных проверок выяснилось, что проекты работающие и скомпилированные в версии ТМ 6.05 не вызывают проблем при работе с ODBC драйвером ОС, при переходе в ТМ6.05.1 начинаются проблемы описанные в вышеуказанном топике, напомню: //Нами был обнаружен тот факт, что при включении обмена с БД канала CALL связанного с шаблоном и программы посылающей раз в 10 с. во входное значение этого канала номер запроса наблюдается периодическое многократное (на порядок!!!) превышение цикла монитором, что подтверждает скачкообразное, одновременно с CalculateCycle, возрастание IdleLoop. При чём это происходит в промежутках между обращениями (запросами) из БД. К примеру запрос происходит при старте монитора, потом через каждые 50 циклов (1цикл=200мс) т.е. около 10 с, так вот не при старте не спустя 10 с скачков не наблюдается, всё присходит ориентировочно в промежутках между обращениями. Когда открываем шаблон в среде разработки (на той же машине что и РТМ запускаем) проверяем запросы, связь с БД всё ОК, компилируем запускаем, что в профайлере что в РТМ, такая же картина! И такая картина не только в том проекте который есть у Вас но и в другом который разрабатывала сторонняя организация для нашей задачи и работает он сдругой БД и на другой машине. (там обмен с интервалом в 1 мин) Тогда вопросы: 1. Какие операции выполняет ТМ6.05.1 в промежутках между обращениями к БД? 2. Как можно диагностировать обмен с БД, но так чтоб выявить причину возникающей проблемы?// Вобщем господа, проверьте пожалуйста этот релиз на предмет работы с ODBC, почтой мы вам отправим скриншет с журналом просмотра событий ОС, там открыта как раз ошибка связанная с этим драйвером.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
PMA
Forum Professor / Завсегдатай форума
Участник № / Member № 1387
отправлено / posted
Добрый день ! Действительно проблема появилась в релизе 6.05.1. При запуске канала выполняющего запись в таблицу MS SQL-2005,обязательно появляется сообщениие Calc Loop is Big и происходит потеря управления объектом на время от 5 до 10 сек, в это время система ни на что не реагирует, соответсвенно выходные сигналы не изменяются и происходит запаздывание, которое существенно влияет на состояние объекта. Запись в БД формируется 1 раз в 2 минуты. Когда я пишу, что система не реагирует, имеется в виду, что графика останавливается и через несколько секунд все значения изменяются скачком.
Сообщения / Posts 159 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Уважаемая техподдержка, вы проверяли обмен ч/з ODBC/SQL драйвер c SQL сервером? Сделайте простой тестоваый проект в котором будет запрос из БД и передача в каналы значений аргументов канала CALL вызова шаблона связи с этой БД и увидите что происходит! Если надо мы Вышлем разные варианты тестовых проектов где используются разные сервера (SQL базы) с log файлом трассировки, у всех у них те же проблемы которые мы описываем. У нас нет документации для анализа этого файла, попробуете разобраться что происходит при обмене. А главное, вы сами можете проверить всё и без нас, неужели у вас нет SQL сервера? Вы же писали на сайте, что проверяли работу релиза 6.05.1!
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Прямо сейчас накидали тестовый проект с разными шаблонами (но все они SELECT), запускали с разных машин и работали с разными базами, везде наблюдается большёй скачёк времени цикла при работе монитора, в файле трассировщика явных свидетельств об ошибках не наюлюдается, более того все запросы идут с ответами (видно из содержания этого же файла), но и там же наблюдается большая куча дополнительной информации. Уменьшали частоту запросов, уменьшали количество выбираемых данных (до одного значения!!!) превышений цикла меньше не становилось. Господа убедительно просим Вас проверьте пожалуйста у себя в тестовом режиме обмен с использованием драйвера SQL-ного, вы увиде то же самое, уверен на 99%.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Мы конечно понимаем Вашу загруженность работой, но всё же и у нас тоже проблема эта висит не решённой. Как можно решить эту проблему в более короткий срок? Уже прошёл месяц, мы думаем что пора принять какое то решение в этом направлении! Надеемся на Ваше понимание!
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Настроил SQL Server 2005, подключение осуществлялось очень долго. Этот процесс мы будем изучать и, если сможем, оптимизировать.
Создание SQL запросов не заняло много времени.
Выполнение записи данных в БД не вызвало подвисаний системы. Осуществлялась запись 2 параметров по кнопке.
Чтение из базы также прошло без подвисаний. Считывались те же два параметра (без фильтров).
У нас SQL Server и проект запускались на одной машине. У Вас тоже или по сети? Можете прислать нам Ваши тестовые примерчики?
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Да по сети конечно, прислать сможем, хотя вроде уже присылали и отчёт (трассировщика ODBC) тоже...
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Проверили работу по сети. Зависаний также не было обнаружено. Ждем Ваших примеров.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
Все необходимые материалы отправили на адрес техподдержки. Давайте будем разбираться с проблемой уважаемые Господа разработчики.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Скажите пожалуйста в релизе 6.06 по этой тематике проблем не будет? Мы ждём результата теперь хотябы к новому релизу! Все исчерпывающие комментарии по проблеме (возникающей необратимой ситуации при определённых условиях, вплоть до повисания ОС) работы РТМ были отосланы на адрес техподдержки, так что повторяться не будем.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Для того, чтобы при потере соединения с базой данных этот канал не загружал всю систему его надо перевести в поток Idle. Переподключение в таком случае будет происходить без влияния на остальную систему.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Да спасибо конечно, попробуем, только в поток idle переводить оба канала CALL, т.е тот что шаблон связи с БД вызывает и тот что посылает в его входное значение номер запроса? Но уважаемые Господа, ведь в версии 6.05 при процедурах восстановления связи с БД такого перегруза системы небыло. Поэтому мы очень обеспокоены как будут обстоять дела на эту тему в релизе 6.06!
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Господа можно чуть оперативнее отвечать!
Дайте пожалуйста ответ на вопрос: в поток idle переводить оба канала CALL, т.е тот что шаблон связи с БД вызывает и тот что посылает в его входное значение номер запроса?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Данная проблема возникла из-за того, что начиная с релиза 6.05.1 все SQL операции были переведены в основной поток для ускорения их реализации. До этого SQL операции производились в потоке IDLE.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
... Да, действительно после перевода в поток idle канала, вызывающего шаблон связи с БД, мониторы стали работать более устойчиво, т.е. при любых нарушениях касающихся связи с удалённой БД, и в том числе перезагрузки удалённого сервера под которым она работает, РТМ что называется "колом" не встаёт, но если он не засыпет сообщениями операционку, в ОС число открытых окон зависит от ресурсов железа и является ограниченным. Но не смотря на это Вам всё таки ещё надо поработать с процедурами которые определяют обмен с драйвером ODBC, ввести некое подобие таймаута для отключеня канала (выставлять недостоверность) отвечающего за обмен с БД в проекте в случаях любых нарушений работы даже самого драйвера. Можете провести следующий эксперимент: У Вас есть проект ранее нами отправленный, который очень интенсивно ведёт обмен с удалённой БД. Но можете и свой сделать на скорую руку. 1. Запускаем трассировщик ODBC. 2. Запускаем РТМ, работаем. 3. Во время работы РТМа останавливаем трассировщик. После 3-го шага РТМ "вылетает" сообщив об ошибке и предлагая запустить отладчик.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Попробовали Ваш вариант. Не получилось. "Вылета" МРВ не удалось добиться, даже удалив соответствующий драйвер.
Сообщения / Posts 17106 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
