This is topic Время использования процессора in forum Мониторы Реального Времени / Real Time Monitors at Форум TRACE MODE: техническая поддержка.


To visit this topic, use this URL:
http://forum.adastra.ru/ultimatebb.php/ubb/get_topic/f/35/t/000111.html

Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
 
Добрый день. Возникла следующая проблема: запускаем на выполнение проект, собирающий информацию с трёх контроллеров по Modbus RTU, сразу же после этого смотрим загрузку процессора процессом rtcx.exe - 11-15%, всё нормально. С течением времени загрузка процессора начинает возрастать, пока не упирается в 100% (из них процентов 95% занимает rtcx.exe), графика тормозит, работать невозможно, приходится перегружать компьютер. Машина нормальная (P3, 1 ГГц, 1 Гбайт ОЗУ, WinXP только что переустановили).
Есть ли у Вас какие-либо мысли по-поводу того, на что может со временем расходоваться процессорное время? Что в проекте может быть сделано не так? Два других узла из этого же проекта на подобных машинах работают без замечаний.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Не имея реального проекта, точно определить причину увеличения загрузки процессора нельзя.
Можно предположить, что какой-то из потоков (с большой вероятностью это графика) требует значительных ресурсов памяти, постепенно увеличивая объем процедур свопинга, что приводит к дополнительной загрузке процессора.
Если Вы работаете в релизе 6.05 и можете предоставить нам проект (на адрес техподдержки), на котором мы могли бы воспроизвести ситуацию без реальной связи с внешними устройствами, мы могли провести более детальный анализ.
К проекту приложите, пожалуйста, ясные комментарии, указывающие как добиться наблюдаемого эффекта.
 
Posted by lutskvk (Участник № / Member № 2710) on :
 
Добрый день. Возникла аналогичная проблема: запускаем на выполнение проект, собирающий информацию с шести контроллеров по Modbus RTU,
отображение на трендах информацию по параметрам, запись в БД ACCES и СПАД. Сразу же после этого смотрим загрузку процессора процессом rtcx.exe - 03-08%, всё нормально. С течением времени загрузка процессора начинает возрастать, пока не упирается в 100%,постепенно увеличивается объем свопинга , приходится перезагружать компьютер. Машина P3, 1 ГГц, 1 Гбайт ОЗУ ).
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Тот же вопрос и тот же ответ.
Очень мало вероятно, что критическая ситуация возникает за счет обмена по MODBUS RTU (если только Вы не работаете через эмулятор COM-порта по сети Ethernet).
Более вероятна перегрузка из-за графики.
Если без подключения внешних устройств у Вас наблюдается тот же эффект, присылайте проект для анализа.
 
Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
 
Добрый день. В продолжение начатой темы. Добавил в проект канал, привязанный к диагностической переменной @e_Modbus. В процессе работы RTM значение этого канала изменяется: 776, 1032, 520. Это коды ошибок? В хелпе нет объяснения таким кодам. Объясните пожалуйста, что обозначают эти значения канала. Спасибо.
Выслал свой проект по электронной почте.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В полученном от Вас проекте достаточно много внешних подключений, которые нам воспроизвести очень сложно.
К связи с этим и воспроизвести описанные Вами ситуации мы не сможем.

Рекомендации.
1. В релизе 6.05.1 существенно расширена диагностическая информация в окне "Компоненты".
В средней части этого окна есть индикаторы (CALC и далее), каждый из которых индицирует долю процессорной загрузки, которая приходится на этот поток. Понаблюдайте за этими индикаторами. Они могут показать, какие именно потоки увеличивают свою долю загрузки процессора. По этой информации можно выявить узкие места и искать рациональные решения.

2. Для выяснения причин некорректной связи по MODBUS RTU с одним из контроллеров следует запустить перехватчик трафика соответствующего COM-порта и запротоколировать его транзакции. По этому протоколу можно увидеть, как реагирует контроллер на посылаемые запросы.

Коды ошибок обмена по последовательному интерфейсу сопровождаются дополнительной информацией в старшем байте канала диагностики - это номер COM-порта. Приведенные Вами коды ошибок соответствуют коду ошибки "8" по COM-портам соответственно 3, 4 и 2.
 
Posted by Karpelyanskiy S.V. (Участник № / Member № 2191) on :
 
quote:
Отправитель / Originally posted by AdAstra Technical Support:

1. В релизе 6.05.1 существенно расширена диагностическая информация в окне "Компоненты".
В средней части этого окна есть индикаторы (CALC и далее), каждый из которых индицирует долю процессорной загрузки, которая приходится на этот поток.

Где можно найти подробное описание значения каждого из этих индикаторов?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Эти индикаторы не документированы, поскольку эти функции в настоящее время отрабатываются.
GSYS - поток графики,
CALC - поток пересчета,
RMAIN - основной поток (в реализации этой функции есть проблемы),
IDLE, ACT (действие), FAST - потоки из списка "Потоки монитора",
IPGET, IPSND - потоки запросов и передач по IP,
TCP_CS, TCP_RS - потоки запросов и ответов по TCP,
TCP_MDB, TCP_SMDB - потоки мастера и Slave MODBUS TCP,
RS - потоки последовательных каналов,
DRV - потоки драйверов.
 


Новости АСУ ТП / News | SCADA / HMI | Обучение / Trainings | Свяжитесь с нами / Contact Us



Powered by Infopop Corporation
UBB.classic™ 6.7.2