This is topic Ошибка архива in forum SIAD/SQL. Архивирование в TRACE MODE / SIAD/SQL. Data Logging in TRACE MODE at Форум TRACE MODE: техническая поддержка.
Здравствуйте! Подскажите,пожалуйста. В проекте архивируется 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: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.Подскажите значение этих строк они возникают при рабочем архиве. Это ошибки?
1. Прошу прощения. В протоколе действительно указывается реальный цикл сохранения в RTM.
2. Чрезмерное увеличение очереди на запись может быть - из-за слишком большой нагрузки на выборки из архива, в том числе и при поврежденном архиве, - из-за частого копирования архивов, - из-за торможения в файловых операциях со стороны ОС, - недостаточности выделяемой оперативной памяти, в результате недостаток восполняется за счет виртуальной памяти и свопинг приводит к общему замедлению записей в файлы, - из-за работы каких-либо внешних приложений (например, антивирусов, дефрагментаторов и пр.),
3. В приведенном тексте tm6_log.txt нет ситуаций, фиксирующих повреждение архива. Возможно, он был поврежден раньше 18.11.2015.
4. Эти сообщения выводятся в соответствии с заданным Вами отладочным ключом - это фиксация изменений переменных за счет действий пользователя (возможно, например, с заданием временных границ выборки из архива). В ключе DEBUGON=700CDFD0 за это отвечает бит 0x1000.
Целесообразно продолжить обсуждение по почте с предоставлением более полной информации (файла проекта и папки узла).
