This is topic Ошибка архива in forum SIAD/SQL. Архивирование в TRACE MODE / SIAD/SQL. Data Logging in TRACE MODE at Форум TRACE MODE: техническая поддержка.


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

Posted by Алексей Шелепов (Участник № / Member № 6361) on :
 
Здравствуйте!
Подскажите,пожалуйста. В проекте архивируется 63 канала Float. Через месяц после запуска проекта файл архива - 17Гб. Появился файл "siaderr" с сообщениями "Insert Queue is big=0 или 1 или 2 или 3". Вход с тренда в архив блокируется. В настройках архива период сохранения выставлен максимально возможный 65535, остальные настройки стандартные. КАК УМЕНЬШИТЬ ДАННЫЕ?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Не следует увеличивать "Период сохранения". Качество архивирования при этом ухудшается, а очередь на запись увеличивается.
Надо оставить эту настройку заданной по умолчанию.

Размер файла архива не рекомендуется задавать более 1 ГБ.
 
Posted by Алексей Шелепов (Участник № / Member № 6361) on :
 
Размер файла установлен 1000Мб. Откуда тогда файл в 17 гб. Как правильно настроить архив?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Сначала надо добиться отсутствия ошибок.
Возможно, что сбой размера архива возник именно по причине недостаточности ресурсов.
Начните архив сначала с с корректной настройкой периода сохранения.
 
Posted by Алексей Шелепов (Участник № / Member № 6361) on :
 
О каких ресурсах идет речь? Периоды пробовались разные, от по-умолчанию до максимального. Всегда неимоверные файлы архивов. Какие еще есть методы уменьшить файл архива?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
В данном случае речь может идти не об "уменьшении файла архива" (он все равно уже поврежден и, как правило, неработоспособен), а об обеспечении устойчивости работы архива и недопущении его разрушения.
Надо мониторить системные ресурсы (системным монитором), надо диагностировать процесс с периодическим сбросом данных в файл с помощью системных и диагностических переменных
@e_SIAD (подключить к ChGroupReq) и
@RTM_Parameter:
Параметр = 71, Memory – используемая память, MB;
Параметр = 72, Memory Peak – максимум использования памяти;
Параметр = 73, Swap – использование файла подкачки;
Параметр = 74, Swap Peak – максимум использования файла подкачки;
Параметр = 76, CPU – загрузка ЦП;
 
Posted by Алексей Шелепов (Участник № / Member № 6361) on :
 
Здравствуйте! Возвращаясь к вопросу о размере файла архива. В том же проекте - 63 архивируемых каналов FLOAT при стандартных параметрах СПАД архив пишется. Глубина архива около 3 суток, размер файла 128мб. Для увеличения времени архивирования изменил размер файла до 1000мб. Через неделю опять блокировка архива и "Insert Queue is big=0 или 1 или 2 или 3". Вопрос: каким параметром СПАД задается величина архива, до каких размеров, необходимо ли разделить архивируемые каналы по разным СПАД? Архив по ТЗ заказчика необходим 5 ЛЕТ!!!
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Если архив заполняется слишком быстро и есть возможность распределить переменные по разным архивам, следует это сделать.
Архив на 5 лет при такой интенсивности записей фактически сделать нельзя - с ним нельзя будет работать.
Надо использовать штатный механизм копирования архивов. Для просмотра или документирования данных из копий архивов их можно подключать программно или вручную.
Для просмотра старых копий архивов, возможно, целесообразно иметь отдельное рабочее место (например, профайлер IDE) на котором можно запустить тот же узел.
 
Posted by Алексей Шелепов (Участник № / Member № 6361) on :
 
С разделением по архивам понятно, а насчет размера файла подбирать эмпирическим путем?
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
Т.к. формализовать поток архивируемых данных в реальном процессе, скорее всего, не удастся, придется идти на эксперимент. Оценивать результаты эксперимента необходимо с допуском, определяемым по тому, насколько опытный процесс соответствует возможным версиям реального процесса.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
Тоже проблема с архивом произошла при достиг размере 503МБ ().На архивном тренде при нажатии перехода в архив иконка становится неактивной и время 1980 год. В архив (в узле только один) пишется всего 24 float. Подскажите в чем м.б. дело присоединяю файл с DEBUGON=700CDFD0

(17:28:21) INF_LOAD:Starting... asep_6-09-TwiceRevo_0
(17:28:21) INF_RTM:Detected NT6.RTM 6.1
(17:28:21) INF_RTM:Professional TRACE MODE 6 Profiler T-Factory RTM+ ver. 6.09.0
(17:28:21) ._.:RTM
(17:28:21) INF_LOAD:max channel = 65535
(17:28:21) INF_LOAD:Load Channels = 248
(17:28:21) INF_LOAD:Templates=19 (math=11 sql=0 scr=10 doc=14 pnl=0)
(17:28:21) INF_LOAD:Objects = 3
(17:28:21) INF_RTM:Timer=0.3s CalcLoop=300ms
(17:28:21) INF_ER:size f=172 g=208 len=157 filename=alrm.txt
(17:28:21) INF_LOAD:LoadTime=0.424s CalcPeriod=300ms
(17:28:21) INF_RTM:available(MB): pm=8061 vm=2047; free(MB): pm=5990 vm=1927 em=0 after load
(17:28:21) INF_RTM:total use(MB): pm=2070 vm=120 after load
(17:28:21) INF_RTM:use(MB): pm=19(19) vm=20(21) pf=0 after load
(17:28:21) INF_RTM:gh:27 uh:74 hh:112 after load
(17:28:21) INF_RTM:start Main[5884] idle
(17:28:49) INF_RTM:start Ext Graph[5400] normal
(17:28:49) INF_RTM: OXP[1X.xxxx.00]
(17:28:49) INF_RTM:start EVENT[5468] low
(17:28:50) INF_SIAD:1: siad1.rep Size=1500(0,-1) CommitPeriod=60 CashSize=48
(17:28:50) INF_SIAD:First data at ... (0)
(17:28:50) INF_SIAD:Last data at 01/01/80 00:00:00 (315525600)
(17:28:50) INF_RS:init string is \\.\COM2: baud=115200 parity=N data=8 stop=1
(17:28:50) ERR_RS:create COM Handler error = 2
(17:28:50) INF_RS:init string is \\.\COM3: baud=38400 parity=N data=8 stop=1
(17:28:50) ERR_RS:create COM Handler error = 2
(17:28:50) INF_RS:init string is \\.\COM4: baud=38400 parity=N data=8 stop=1
(17:28:50) ERR_RS:create COM Handler error = 2
(17:28:50) INF_RTM:start SDDE[5416] low
(17:28:50) INF_RTM:start ACT[5408] idle
(17:28:50) INF_IP:hostname is Dell7720
(17:28:50) INF_IP:card0 addr=0.0.0.0
(17:28:50) INF_IP:card1 addr=192.168.1.203
(17:28:50) INF_RTM:start CALC[5488] above
(17:28:50) INF_RTM:fast channels not found
(17:28:50) INF_RTM:start GRAPH[5484] low
(17:28:50) INF_RTM:start time is 1.189 s
(17:28:50) INF_RTM:total use(MB): pm=2122 vm=319 after start
(17:28:50) INF_RTM:use(MB): pm=60(66) vm=190(241) pf=47830 after start
(17:28:50) INF_RTM:gh:1580 uh:218 hh:276 after start
(17:28:50) INF_FLT:ModeSwitch e15=0000 e18=0000 e20=0000 [0]
(17:28:50) INF_RTM:mode=2(Work) e15=00 e18=00 e20=00 [src4]
(17:28:50) INF_FLT:No detect condition
(17:28:50) INF_GRAPH:scr:10:popup=3 scrref=0 trend=5,0 update=1
(17:28:58) INF_SIAD:arch_1 after start ... 01/01/80 00:00:00
(17:28:58) INF_RTM:Thread Enable
(17:29:13) DBG_RTM:(L) g_ID=150 Index=3 LVal=1452698789 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=4 LVal=1452698969 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=3 LVal=1452698760 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=4 LVal=1452698940 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698789 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452698969 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698760 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452698940 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=3 LVal=1452698880 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=4 LVal=1452699060 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698880 id_attr=-1

(17:29:13) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452699060 id_attr=-1

(17:30:24) DBG_RTM:(L) g_ID=150 Index=3 LVal=315525600 id_attr=-1

(17:30:24) DBG_RTM:(L) g_ID=150 Index=4 LVal=315525780 id_attr=-1

(17:30:24) INF_SIAD:trendSHSR_1:142[1] trend ID=16 ch=208.0(point=603) from=315525600(315525600) to=315525780(315525780) first=0 at 1452699024(0-1)
(17:30:24) INF_SIAD:trendSHSR_1:142[1] trend ID=17 ch=210.0(point=603) from=315525600(315525600) to=315525780(315525780) first=0 at 1452699024(0-2)
(17:30:24) INF_SIAD:trendSHSR_1:142[1] trend ID=18 ch=212.0(point=603) from=315525600(315525600) to=315525780(315525780) first=0 at 1452699024(0-3)
(17:32:29) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698985 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452699165 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698940 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452699120 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=3 LVal=315525600 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=4 LVal=315525780 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=3 LVal=1452698940 id_attr=-1

(17:32:29) DBG_RTM:(L) g_ID=150 Index=4 LVal=1452699120 id_attr=-1

(17:33:24) INF_SIAD:timeout recieve data for = 16
(17:33:24) INF_SIAD:timeout recieve data for = 17
(17:33:24) INF_SIAD:timeout recieve data for = 18
(17:33:24) INF_SIAD:trendSHSR_1:142 snap ID=20 ch=? from=0 to=315525600 first=0 at 1452699204(1) 303548
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
"INF_SIAD:1: siad1.rep Size=1500(0,-1) CommitPeriod=60 CashSize=48 "
Период сохранения в настройках архива следует оставить заданный по умолчанию.

"INF_SIAD:First data at ... (0)
INF_SIAD:Last data at 01/01/80 00:00:00 (315525600)"
Архив поврежден.
Он мог быть поврежден либо при нештатном выключении RTM, либо при наличии очень больших очередей на запись.
Информация о повреждениях может быть записана в файле tm6_log.txt и в файле siaderr.txt.
 
Posted by Алекс К (Участник № / Member № 1337) on :
 
1.Период сохранения в настройках архива стоит = 300 (вообще никогда его не трогал).
2. в файле siaderr.txt записи Insert Queue is big=0
(много их, меньше с 1 или 2). после повреждения архива постоянно увеличивают файл (зачем без метки времени?).
3. В tm6_log вот что
LOAD [0] 609 Jul 17 2013
10:04:20 0000 00000000[0] 11/18/15
10:04:20 0000 00000000[53] login ok
10:04:33 0000 00000001[1545] Start
14:49:24 0000 00000000[0] logout failed
14:49:27 0000 00000000[0] logout failed
14:49:38 0000 00000000[53] logout
14:49:40 1439569694 00000005[0] Stop
LOAD [0] 609 Jul 17 2013
09:34:59 0000 00000000[0] 11/19/15
09:34:59 0000 00000000[53] login ok
09:35:26 0000 00000001[1545] Start
09:50:17 0000 00000000[0] logout failed
09:50:25 0000 00000000[0] logout failed
09:50:42 0000 00000000[0] logout failed
09:50:57 0000 00000000[53] logout
09:50:59 1439569694 00000006[0] Stop
LOAD [0] 609 Jul 17 2013
14:19:41 0000 00000000[0] 11/19/15
14:19:41 0000 00000000[53] login ok
14:20:14 0000 00000001[1545] Start
18:04:38 0000 00000000[53] logout
18:04:40 1439569694 00000003[0] Stop
LOAD [0] 609 Jul 17 2013
08:15:26 0000 00000000[0] 11/24/15
08:15:26 0000 00000000[53] login ok
08:15:52 0000 00000001[1545] Start
LOAD [0] 609 Jul 17 2013
11:19:46 0000 00000000[0] 12/03/15
11:19:46 0000 00000000[53] login ok
11:20:33 0013 00000041[1] COM
11:20:33 0013 00000041[1] COM
11:20:33 0013 00000041[1] COM
11:20:33 0000 00000004[1545] Start
12:20:58 0000 00000000[0] 12/06/15
12:20:58 0000 00000000[53] logout
12:21:01 1439569694 00000006[0] Stop
12:21:32 0000 00000000[0] 06.12.2015
12:21:32 0000 00000000[53] logout
12:21:35 1439569694 00000003[0] Stop
LOAD [0] 609 Jul 17 2013
12:21:42 0000 00000000[0] 12/06/15
12:21:42 0000 00000000[53] login ok
12:21:56 0000 00000001[1545] Start
12:09:44 0000 00000000[0] 21.12.2015
12:09:44 0000 00000000[53] logout
12:10:47 1439569694 00000003[0] Stop

4.Подскажите значение этих строк они возникают при рабочем архиве. Это ошибки?

(17:32:29) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698985 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452699165 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=14 LVal=1452698940 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=15 LVal=1452699120 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=3 LVal=315525600 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=4 LVal=315525780 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=3 LVal=1452698940 id_attr=-1
(17:32:29) DBG_RTM:(L) g_ID=150 Index=4 LVal=1452699120 id_attr=-1
 
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
 
1. Прошу прощения. В протоколе действительно указывается реальный цикл сохранения в RTM.

2. Чрезмерное увеличение очереди на запись может быть
- из-за слишком большой нагрузки на выборки из архива, в том числе и при поврежденном архиве,
- из-за частого копирования архивов,
- из-за торможения в файловых операциях со стороны ОС,
- недостаточности выделяемой оперативной памяти, в результате недостаток восполняется за счет виртуальной памяти и свопинг приводит к общему замедлению записей в файлы,
- из-за работы каких-либо внешних приложений (например, антивирусов, дефрагментаторов и пр.),

3. В приведенном тексте tm6_log.txt нет ситуаций, фиксирующих повреждение архива. Возможно, он был поврежден раньше 18.11.2015.

4. Эти сообщения выводятся в соответствии с заданным Вами отладочным ключом - это фиксация изменений переменных за счет действий пользователя (возможно, например, с заданием временных границ выборки из архива).
В ключе DEBUGON=700CDFD0 за это отвечает бит 0x1000.

Целесообразно продолжить обсуждение по почте с предоставлением более полной информации (файла проекта и папки узла).
 


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



Powered by Infopop Corporation
UBB.classic™ 6.7.2