Открыл новый топик поскольку появились проблемы с работой в релизе 6.05.1
Ситуация такая. В процессе отладки проекта заметили, что имеет место критическое время цикла монитора для WIndows которое, как пример, для нашего случая составило 63 мс. Проверяли так. Установили время 50 мс и реальное время цикла всё таки увеличилось и составило 63 мс, но, когда начали его увеличивать, до 100, 200, 500, 800 мс увы обнаружили тот факт, что реальное время всё же превышает на несколько (до 10) мс установленное. При чём когда цикл был 50 мс время на графику (переменная "@Graphics_Loop) "проскакивало" в пределах 31-47 мс, т.е. весь цикл, а время для первого потока "@Calculate_Cycle" 0-1 мс (тоже странно!), а когда цикл увеличили до 100 мс графика уменьшилась до 0-16 и время цикла колебалось 91-97, но периодически возрастало до 109-110 мс, причём это возрастание на 10 мс наблюдалось и при 500! Чем это объяснить?! В проекте оставили только порядка 30 каналов обмена по Ethernet c узлом embeddedRTM по ним ни одной недостоверности, всё остальное отключили и в такой ситуации в новом релизе 6.05.1 соответственно вылетают сообщения (в новом релизе 6.05.1) о превышении цикла! В топике "потоки монитора" Вы писали: "Диагностическая переменная @Calc_Loop показывает реальное время цикла монитора, оно не может быть меньше заданного." Если так, то зачем Вы сделали в релизе 6.05.1 выдачу сообщения системой о превышении цикла монитора? Проект мы Вам по почте васылали, с проблемой слоёв разбираться, так что можете глянуть в нём сами и запустить при необходимости.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Цикл (@Calc_Loop) у нас обычно был равен 50, иногда 51-56, но это в пределах погрешности квантования, так как разрешение у Вас стоит 0.01. При этом на обработку графики отводилось 85% ресурсов CPU, на обработку каналов около 13%. @Calculate_Cycle был примерно 0.6 - 0.7 мс, возрастая иногда до 2 мс. То есть превышение времени до 10 мс - это в пределах погрешности. Предупреждений о превышении времени цикла не появлялось.
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Мы нашли причину превышений цикла монитором! Но как решить эту проблему не знаем.
Нами был обнаружен тот факт, что при включении обмена с БД канала CALL связанного с шаблоном и программы посылающей раз в 10 мин. во входное значение этого канала номер запроса наблюдается периодическое многократное (на порядок!!!) превышение цикла монитором, что подтверждает скачкообразное, одновременно с CalculateCycle, возрастание IdleLoop. При чём это происходит в промежутках между обращениями (запросами) из БД. К примеру запрос происходит при старте монитора, потом через каждые 50 циклов (1цикл=200мс) т.е. около 10 минут, так вот не при старте не спустя 10 минут скачков не наблюдается, всё присходит ориентировочно в промежутках между обращениями. Когда открываем шаблон в среде разработки (на той же машине что и РТМ запускаем) проверяем запросы, связь с БД всё ОК, компилируем запускаем, что в профайлере что в РТМ, такая же картина! И такая картина не только в том проекте который есть у Вас но и в другом который разрабатывала сторонняя организация для нашей задачи. Тогда вопросы: 1. Какие операции выполняет ТМ в промежутках между обращениями к БД? 2. Как можно диагностировать обмен с БД, но так чтоб выявить причину возникающей проблемы?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Хотелось бы уточнить: 50 циклов по 200 мс - это 10 сек. Вы имели ввиду 10 сек или я не правильно Вас понял?
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Прошу прощения за неточность! Оговорился я в торопях, 10 секунд действительно имел ввиду. Делали так же с интервалом в 1 минуту, количество сообщений о превышении цикла уменьшалось пропорционально...
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Уважаемые Господа разработчики, наверно стоит перейти в другой раздел, т.к. тема касается обмена с SQL.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Ещё кое что Господа! Замечен такой факт в новой версии 6.05.1, как выдача сообщений "insufficient memory" на любых проектах, при повторном перезапуске РТМ. Если при перезапуске перезагружаешь машину вместе с рантаймом то всё ОК. Т.е. подтверждается тот факт, что ТМ оставляет "хвосты" в оперативке. Т.е. поскольку в этой версии как Вы говорите добавлена многофункциональная диагностика, то сейчас она как раз помогает обнаружить недочёты как в проекте так и собственно Вашего программного продукта
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Утверждение об обязательности "выдачи сообщений "insufficient memory" на любых проектах, при повторном перезапуске РТМ." является слишком смелым. Мы взяли Ваш проект ASM_TP_07v010, который Вы нам прислали 28.12.07, запускали его несколько раз, но только 1 раз получили сообщение "Calc loop is big" и ни разу не получали сообщения "insufficient memory". Правда, мы проводили каждый раз полную штатную остановку и выгрузку узла. Никакой корреляции с выгрузками МРВ мы не обнаружили. Поэтому говорить о гипотетических "хвостах", остающихся при штатной выгрузке узла, оснований, с нашей точки зрения, нет. Кроме того, надо иметь в виду, что в релизе 6.05.1 по умолчанию при запуске узла осуществляется захват и резервирование системных ресурсов (памяти и объектов) (см. описание файла TMcom_<ordinal>.cnf). Там же указаны размеры резервов и ключи, которые могут эти резервы изменить/отменить. Сообщение о недостаточности памяти"insufficient memory" формируется не в фатальной ситуации, а в момент, когда МРВ вынужден использовать захваченный резерв для работы. 2. Сообщение "Calc loop is big" формируется, если превышение выходит за пределы квантования времени цикла средствами ОС. В Вашем проекте квант равен 10 мс (а реально - несколько больше). Выход реального цикла за пределы 55-60 мс (у Вас задан цикл 50мс) может сопровождаться выдачей сообщения. 3. О возрастании времени цикла при формировании запросов к БД. Поток SQL-запросов, формируемых узлом, это асинхронный поток низкого приоритета (IDLE). Сам по себе этот поток вряд ли может вызвать существенное увеличение цикла обработки. Однако, если БД, ее драйвер или какое-либо другое приложение в эти моменты времени сформируют свой поток приоритета, близкого к приоритету МРВ, то не исключено, что эти новые потоки могут повлиять на выделение ресурсов основному потоку МРВ и привести к увеличению цикла обработки базы каналов. При таком малом цикле, какой задан в Вашем проекте это может оказаться сопоставимым с временем цикла. 4. Процедуры диагностики достаточно ресурсоемки. Поэтому реально системная диагностика, введенная в релизе 6.05.1, отображаемая в окне КОМПОНЕНТЫ профайлера и частично продублированная в системной переменной @RTM_Parameter, осуществляется с циклом в несколько секунд. Поэтому нельзя утверждать, что превышение цикла имело место "после отработки SQL-запроса". Правильнее сказать, что это превышение было отображено "после отработки SQL-запроса". 5. Что же касается использования результатов диагностики, то мы рассматриваем их как средство для расширения информационной базы в процессе отладки реальных проектов и поиска узких мест. В ближайшем патче мы проредим эти сообщения и даже дадим возможность совсем их отключать. Но это не исключает необходимости обращать внимание на результаты диагностики и принимать меры для восстановления нормального режима функционирования проекта.
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
Вы не делали "заплатку" на релиз 6.05.1 для конфигурирования выводом служебных сообщений на экран в виде отдельных окон? Если делали то не могли бы скинуть? Этот релиз грешит время от времени раздуванием занимаемой РТМом оперативки и в таких случаях начинают сыпать сообщения на экран и это может повесить систему, такой контроль нужен, но его можно реализовать другим методом. И есть проблемы опять же радувания архивных файлов, не смотря на установленное ограничение. У нас для узла размер для всех трёх архивов установлен 128 Mb, и периодически (около 2-х раз в месяц/монитор работает непрерывно) он ловинообразно увеличивается до 17 Gb (не больше не меньше). Этот эффект наблюдается и на других РТМах с разными проектами (т.е. дело тут не в ошибке проекта а в каком то системном сбое). По этому поводу тоже хотелось бы получить от Вас несколько комментариев.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Добавлю...
1. 16,хGb - это как раз максимально возможный файла размер поддерживаемый ОС. 2. И опять же повторюсь, при установленном в проекте ограничении на файл SIAD до 128 Мв фал достигает размера 138 Mb, но это не страшно., и после этого предполагаю начинает перезаписывать данные, но при старте РТМ всегда выдаёт предупреждение "... wrong size", почему? Всё же укладывается в размер, почему такое сообщение генерируется? А что самое интересное, в первом случае (при увеличении файла SIAD до предела 17Gb) таких сообщений система не выдаёт. Скорее всего ошибка в диагностике наверно?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Уважаемая Техподдержка! Сообщение написанное от 24-05-2008 осталось без комментариев. Вы упомянали в одном из топиков что длительность ожидания ответа составляет 2 дня...
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
1. Патчик отправили. 2. Вы говорите, что это происходит на нескольких проектах. Во всех проектах есть OPC и SQL? Есть проекты, где только пишутся данные в архив, который лавинообразно растет? 3. В какой операционной системе ограничение на размер файла 16 GB? 4. Сообщение "wrong size" появляется при изменении размера архива в инструментальной среде при уже созданном архиве. 5. Пришлите, пожалуйста, еще файл tm6_log.txt 6. Есть диагностическая переменная q_SIAD_Q. Не могли бы Вы данные по одному архиву записывать в другой, чтобы при сбое можно было посмотреть.
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
1. Отправленные библиотеки надо обновить только для РТМ? 2. Да, в одном имеется обмен по OPC, в другом ч/з ODBC. Это как то провоцирует сбои связанные с увеличением размера архивов до предельного? Прокомментируйте пожалуйста каким образом это влияет, чтоб нам можно было скорректировать и оптимизировать проект. 3. NT 4. К сожалению такой взаимосвязи не было, ранее мы с этим сталкивались и сейчас не допускаем изменение предельного размера архивов постфактум. 5. В очередной раз зафиксируем это событие и обязательно пришлём. Но почему в этом логе не фиксируется дата, там только время. Это ошибка, или так надо? 6. У нас используются все три архива, каналы по ним распределены по частоте пересчёта, для оптимизации, по Вашим рекомендациям. Тогда вопрос: можно ли писать данные по диагностике в системный архив? Мы его пока ни где не используем.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
2. Мы пытаемся выяснить как это может влиять. На Вашем проекте от 6 мая такую ситуацию мы промоделировать не смогли.
3. У Вас ошибочные сведения. ОС не ограничивает размер файла. Ограничение может накладывать файловая система.
4. Тот факт, что архив занимал 138 MB при разрешенных 128, означает, что структура архива была нарушена. В таких случаях желательно присылать файл архива и проект нам для анализа.
5. Так и должно быть.
6. Системный архив зарезирвирован. Писать в него нельзя. Пишите данные о 1-ом архиве в 3-ий, о 2-ом в 1-ый, о 3-ем во 2-ой. Или у Вас происходит нарастание одновременно всех архивов?
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
4. Мы вышлем Вам на след неделе проект с архивными файлами. К стати у нас такие "фокусы" - формирование размера в 138 Mb при установленном в проекте размере в 128 Mb на разных РТМ-ах и проектах, это у нас в порядке вещей, внимание не обращаем. Только вот в версии 6.05.1 система в таких случаях при старте выдаёт по архиву в 138 Mb сообщение "wrong size", в РТМ-ах 6.05 собщений нет, ну мы и не обращали раньше на это внимание. ... А иногда после нескольких раз запуска с сообщением "wrong size", РТМ фомирует по этому же архиву резервную копию и выдаёт сообщение "copia S_1" У нас просто 1-й SIAD заполняется быстрее всех, т.к. туда пишутся каналы с наименьшим циклом пересчёта. 6. Нет, только один из трёх. При чём этот эффект ни как не зависит от того был ли архив на 100 % занят данными от его максимального размера установленного в проекте или скажем только на 10% на момент сбоя.
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Grigorovskih
Forum Professor / Завсегдатай форума
Участник № / Member № 1915
отправлено / posted
Господа, по поводу: "Есть диагностическая переменная q_SIAD_Q" В хелпе не всё ясно, поэтому прокомментируйте пожалуйста по подробнее следующие вещи. Каким образом и какую строчку надо активировать в файле "sysdiag_queuesiad.tmc", а так же какие характеристики SIAD надо диагностировать (какой указать номер параметра)?
Сообщения / Posts 362 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Активировать ничего не надо. Диагностировать необходимо параметры 17-19 и 33-35. 17 и 33 - это для первого архива, 18 и 34, 19 и 35 - соответсвенно для второго и третьего.
Сообщения / Posts 17344 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
