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/000296.html

Posted by VadimNN (Участник № / Member № 5312) on :
 
Приблизительно раз в месяц почему-то устанавливается недостоверность (атрибут I) SNMP-каналов, причем опрашиваемое оборудование и канал связи работает корректно. МРВ продолжает некоторое время работать и корректно опрашивать остальные каналы. Потом МРВ падает полностью, т.е. появляется стандартное сообщение Windows о том, что прекращена работа программы Trace Mode RealTime Monitor.

в логе сообщения вида:
00:11:41 0000 00000000[0] 30.09.2012
...
20:59:37 0029 00000000[2] Insufficient: Memory
20:59:38 0029 00001878[1045] pf:6305 fm:805.9 vm:1410.6
...
00:29:12 0000 00000000[0] 03.10.2012

07:11:26 0029 00000000[3] Insufficient: Memory
07:11:26 0029 00001875[1051] pf:5799 fm:863.0 vm:1559.1
...

00:13:58 0000 00000000[0] 04.10.2012
...

19:58:32 0202 00000032[4] UPS2_Battery
19:58:32 0202 00000032[4] UPS2_Input
19:58:32 0202 00000032[4] UPS2_Output
19:58:32 0202 00000032[4] UPS2_Bypass
...

09:40:18 0017 00000002[36]
09:41:18 0017 00000002[36]

Т.е. у МРВ через какое-то время после запуска появляются проблемы с памятью, потом обмен по SNMP-каналам прекращается. Складывается впечатление, что при работе SNMP появляется утечка памяти, что в итоге и приводит к падению МРВ. Или возможно проблема с неустойчивым SNMP-трафиком не была до конца решена? http://forum.adastra.ru/cgi-bin/ultimatebb.cgi/ubb/get_topic/f/35/t/000238.html?#000000

[ 15.10.2012, 09:54: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Из приведенного Вами фрагмента протокола нельзя определить, что является первичной причиной перегрузки памяти, недостоверности в каналах SNMP и падения МРВ, и лежит ли эта причина в области Trace Mode 6.
Задайте в файле конфигурирования запуска узла *.cnf ключ
DEBUGON=E01044F0
и пришлите нам полные файлы протокола профайлера и tm6_log.txt с пометкой моментов появления недостоверности в каналах SNMP и падения МРВ.
 
Posted by VadimNN (Участник № / Member № 5312) on :
 
Отправил на hotline@adastra.ru
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Проект получен.
По предварительным оценкам проблема в недостаточности ресурсов оперативной памяти.
Прямой связи с SNMP-трафиком не выявлено.
Вопросы и рекомендации по дальнейшей диагностике отправлены почтой.
 
Posted by VadimNN (Участник № / Member № 5312) on :
 
Оперативной памяти на сервере 2Гб. И ранее я уже обращался в техподдержу по этому поводу, но рекомендации не помогли. Наш объект уже сдан заказчику, находится в необслуживаемом помещении и возможностей для предложенной вами диагностики нет. Для связи с SNMP-оборудованием был применен SNMP/OPC-сервер.

[ 23.10.2012, 13:02: Сообщение отредактировал / Message edited by AdAstra Technical Support ]
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Действительно при обращении к несуществующему SNMP-серверу у каналов возникает недостоверность и процессор нагружается регулярными попытками установления связи (в потоке с очень низким приоритетом).
Однако, при этом в профайлерном протоколе появляются сообщения
ERR_TCP:SNMP_API wrong request ...

А в присланном Вами протоколе ни одного такого сообщения нет.
Из этого можно заключить, что обмен по SNMP не является причиной возникающих коллизий.
 
Posted by VadimNN (Участник № / Member № 5312) on :
 
Из этого можно заключить что у меня все IP доступны. Проверил отправленный вам файл, там сообщения типа
ERR_TCP:SNMP_API request wrong name ...
Т.е. несколько часов все было нормально и данные приходили, а потом вдруг "wrong name".
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Это сообщение сформировано на основе ответа SNMP-сервера.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Предложенный драйвер протокола SNMP вполне успешно работает в целом ряде серьезных реальных проектов.
И своим письмом от 24.03.2011 dlesnikov подтвердил снятие обнаруженных проблем после корректировки драйвера с учетом неустойчивости SNMP-трафика.

Вопрос о модификации драйвера для сложных и нагруженных конфигураций с неустойчивым, не достаточно строго регламентированным трафиком может рассматриваться при формировании объемной потребности в реализации такого обмена.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2