This is topic copia_s1 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/000297.html

Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
МРВ версии 6.08. Аварийных остановов МРВ не было. При запуске МРВ дважды получал сообщения: copia_s1. Каждый раз при получении такого сообщения МРВ снова останавливался и, во избежание дальнейших проблем, удалялись copia_s1 и spad1. Т.е. многократного наложения ошибок друг на друга не было.
Сегодня заметил что не возможно просмотреть архив трендов. После перезапуска получил новое сообщение: SAID spad1.rep wrong size. При запуске МРВ опять создал copia_s1 и повис.
Т.к. я подозревал что перезапуск добром не кончится - после остановки МРВ я создал копию spad1, могу выслать для анализа.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Высылайте проект, файл tm6_log.txt и архив на hotline@adastra.ru.
Задайте в файле *.cnf ключ DEBUGON=800 и отслеживайте сообщения в профайлерном протоколе и файле tm6_log.txt.
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
Файлы выслал. Ключ задам, но результата возможно придется ждать долго. Баг проявлялся трижды (включая сегодня) за полгода.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Судя по записи в полученном протоколе
LOAD [0] 608 Jan 17 2012,
Вы работаете не со штатным релизом 6.08.
Штатный релиз 6.08, выложенный на сатйе имеет дату сборки 23.01.2012.
Соответствующая запись в tm6_log.txt
LOAD [0] 608 Jan 23 2012.
Необходимо обновиться с нашего сайта до штатного релиза 6.08.

По протоколу tm6_log.txt после старта
LOAD [0] 608 Jan 17 2012
09:07:36 0000 00000000[0] 11.09.2012
09:07:36 0000 00000000[1544] Start
вплоть до останова
10:17:56 0000 00000000[0] 15.10.2012
10:17:56 0000 00000004[0] Stop

у Вас не было ни одного штатного останова и перезапуска узла.
А архив, который Вы прислали, содержит непрерывный поток записей с 27.09.2012 23:23:00 по 15.10.2012 6:17:52.

Из этого никак нельзя установить, каким образом, как Вы пишете, Вы осуществляли остановку и перезапуск узла и как заменяли архив.

Любые нештатные остановки и выгрузки МРВ могут привести к искажениям, в том числе и файловых архивов.
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
quote:
Вы работаете не со штатным релизом 6.08.
Штатный релиз 6.08, выложенный на сатйе имеет дату сборки 23.01.2012.

Скачал, вижу разницу в датах. "Не штатную" версию скачал с адастры 25.01.2012, после информационного письма...

quote:
у Вас не было ни одного штатного останова и перезапуска узла.
А архив, который Вы прислали, содержит непрерывный поток записей с 27.09.2012 23:23:00 по 15.10.2012 6:17:52.
Из этого никак нельзя установить, каким образом, как Вы пишете, Вы осуществляли остановку и перезапуск узла и как заменяли архив.

В указанный период не было остановов и перезапусков, архив не заменялся. МРВ честно писал данные в новый пустой архив, но судя по сообщению написал больше чем следовало.

Удаления архивов происходили по сценарию:
1. Остановлен МРВ
2. После проведения работ запущен МРВ
3. ЕСЛИ получено сообщение "copia_s1" останавливается МРВ
4. Удаляются copia_s1, spad и tm6_log
5. Запускается МРВ
Соответственно если не было пункта 3, пункты 4 и 5 не выполняются.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Описанные Вами процедуры ни в какой степени не соответствуют присланным Вами протоколу tm6_log.txt и файлу архива.
Ни в одном из этих файлов нет ни прямых, ни косвенных указаний на штатные остановки и выгрузки МРВ с 11.09.2012 по 15.10.2012.

2. После остановки МРВ должна обязательно следовать штатная выгрузка (не диспетчером задач!) и последующая перезагрузка МРВ и узла. Все процедуры с файлами архивов можно выполнять только при ВЫГРУЖЕННОМ МРВ.
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
1. В указанный период не было остановов и перезапусков. А то что записи в архиве только с 27.09 - значит более ранние уже вытеснены, размер спада установлен на 256 МБ.
Возможно я не ясно описал проблему. Первый абзац первого поста - это сообщение о возникавших ранее проблемах и как я с ними боролся, версия была та же - 6.08. Спады сохранить своевременно не догадался, предоставить дополнительную информацию не могу, это просто уведомление: "проблемы со спадом есть".
Второй абзац - описание событий последних дней. Результат работы с новым не поврежденным спадом, лог относится к этому же периоду работы.

2. Так я и делал. В пункте 3 "сценария" я упустил концовку: выгружается МРВ. Выгружал как положено, диспетчером не пользовался.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В узле создается файл siaderr.txt, в котором сообщается о неудачных попытках осуществить запись в архив больших объемов данных. Причины таких задержек лежат вне МРВ.
Этими же причинами могут быть вызваны повторяющиеся в tm6_log.txt сообщения о превышении цикла

0000 00000001[21] Calc loop is big

на достаточно большое количество периодов.

Большой объем очереди на запись может быть причиной переполнения архива.

Возможно, наличие на ПК кроме МРВ еще по крайней мере 3 ресурсоемких приложений (2 OPC-сервера и База данных) может вызвать перегрузки как по памяти, так и по процессору.
Необходимо мониторить системные ресурсы и сопоставлять их с диагностическими данными МРВ.

Можно ключом DEBUGON=C4810 расширить диагностику в профайлерном протоколе МРВ по OPC- и SQL-интерфейсам, а также по архивным процедурам.

Уточните в папке МРВ дату создания и объем библиотеки TMArchNET.dll - должно быть ‎17 ‎января ‎2012 ‎г. и 249 856 байт.

Желательно перевести обмен с БД в поток IDLE.
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
siaderr.txt был создан при старте МРВ, одновременно с сообщением "SAID spad1.rep wrong size", до этого момента файла не было, это точно.

Диагностику расширил. TMArchNET.dll правильная, но это теперь. Какая была до переустановки ТМ сказать не могу. Пока больше ничего предпринимать не буду. Понаблюдаю что получилось после смены версии ТМ, может этого достаточно.
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
Ошибка повторилась, данные выслал на hotline@adastra.ru
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Ваше письмо получено со следующим текстовым вложением вместо Вашего:

"FILE QUARANTINED

Microsoft Forefront Protection for Exchange Server removed a file since it was found to be infected.
File name: "err_spad.rar"
Malware name: "Large uncompressed size""
 
Posted by Сергей Морозов (Участник № / Member № 2076) on :
 
Отправил с другого почтового ящика.
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Результаты анализа отправлены почтой.
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2