This is topic Принудительная запись в СПАД in forum Архивирование в TRACE MODE / Data Logging in Trace Mode at Форум TRACE MODE: техническая поддержка.
В проекте завел каналы "ПотеряСПАД", которые несколько раз в сутки осуществляют принудительную запись всех каналов в СПАД. Теоретически это должно было увеличить скорость обращения к архиву за счет сохранения значений редко изменяющихся каналов. Однако, надежды, кажется, не оправдываются . Глобальный регистратор пишет в арихв размером 100 Мб около 600 каналов. При отработке канала ПотеряСПАД видно, как увеличивается очередь, что свидетельствует о правильной его работе. Но, при работе с Supervisor-ом переход на конец архива и дальнейшая работа, как то переход на шаг или переход по экранам, все так же сопровождается задержкой в 3-5 мин. Другими словами - все равно дико тормозит. При этом архивные тренды работают вполне нормально с задержкой всего около 5-15 сек (так было и раньше). Проводились ли эксперименты, определяющие влияние результатов работы этого канала на скорость выборки из архива? Почему возникают задержки? Что он пытается найти, если вот только что были записаны ВСЕ каналы?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Какой у Вас релиз ТМ? Дело в том, что для корректной работы принудительного сохранения канал ДИАГНОСТИКА-Потеря СПАД должен быть OUTPUT. Но до настоящего релиза 5.11 в РБК была ошибка - он не позволял установить для этого канала тип в OUTPUT. Поэтому есть сомнения в том, что механизм принудительного сохранения у Вас работает корректно. Ипытания нами проводились и они действительно практически доказали, что механизм принудительного сохранения позволяет значительно оптимизировать перемещение по архивным данным.
Posted by Sergei (Участник № / Member № 161) on :
Релиз инструментальной - 5.11, ГР - 5.11, supervisor - 5.10 Я знаю об этой ошибке (сам писал в форум)Сохранение в СПАД действительно работает. Это видно и по подскакивающему значению очереди и по содержимому архива при просмотре через ODBC. Только почему-то время обращения к архиву не уменьшилось. Такое ощущение, что архив начинает просматриваться с начала и до запрошенного момента. При переходе на начало архива задержки практически не ощущаются. Если это действительно так, то это все объясняет. Как происходит запрос? Извлекаются данные за запрошенный момент и раньше пока не найдутся значения для всех каналов? Тогда это должно работать. Как часто рекомендуется производить принудительное сохранение? Раз в сутки, раз в час, или это подбирается экспериментально исходя из приемлемой задержки при запросе?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Период принудительного сохранения естественно зависит от динамики сохранения данных в СПАД. Мы производили испытания с почасовым принудительным сохранением данных. Однако период зависит от соотношения объемов сохраняемых данных с более высокой динамикой записи и более низкой. Чем больше объем сохранения данных в промежутках между сохранением данных с меньшей динамикой, тем меньше должен быть период принудительного сохранения данных в архив. На эти выходные мы попробуем смоделировать и оставить работать два одинаковых проекта с сохранением данных в СПАД с различной динамикой накопления истории. Только в одном из проектов будет реализовано принудительное сохранение данных. В понедельник проведем испытания и попробуем определить примерную кореляцию периода принудительного сохранения от объемеов и динамики данных. О результатах сообщим в нашем форуме.
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Исследования заняли некоторое время, поэтому мы берем дополнительный таймаут до вторника (15.10.2002).
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Параметры проекта для проведения испытаний: СПАД архив - 2Гб (2000 Мбайт). Цикл пересчета - 100 мс. 50 каналов (генератор пила) сохраняются в архив с периодом пересчета узла. 4 "медленных" канала (генераторы) - с периодами пересчета 20мин., 1час., 80мин., 3часа. Пнринудительное сохранение - раз в 15 минут. Данный параметр подбирался исходя из динамики системы. Т.е., винчестер UDMA100 - это примерно 10Мбайт в секунду. Этих 10Мбайт достаточно для сохранения данных с "быстрых" каналов примерно на 21 минуту. Выбрав 15 минут - получим примерно 7Мбайт между двумя записями для "медленных" каналов (т.е. поиск следующей записи по каналу будет занимать в архиве не более 1 секунды). Таким образом, если на тренде я собираюсь отображать диапазон в 120-180 минут, то выборка (перемещение по кривой) должно занимать 6-9 секунд. На практике испытания показали результаты от 5 до 10 секунд при перемещении по скроллбару и до 30 секунд при переходе на время. На том же проекте, но без принудительного сохранения, аналогичные действия занимали 5-10 минут! Архив во всех испытаниях был предварительно заполнен данными на 70-90%.
Posted by Sergei (Участник № / Member № 161) on :
Спасибо за информацию. Должен сказать, что по мере перезаписи архива данными с принудительным сохранением время доступа уменьшается. Так, если ранше переход на конец архива осуществлялся примерно за 5 мин, то при перезаписи архива процентов на 70, уже около 30-40 сек. Это уже кое-что. Одно неприятно: после того как переход на время произошел, переход по экранам вызывает повторное подчитывание значений и соответсвенно такие же задержки. Разве переход на время не вызывает чтение среза данных? Если это так, то зачем заново перечитывать архив?
Posted by AdAstra Technical Support (Участник № / Member № 4) on :
Эта функция будет модифицирована в ближайшем релизе.
Posted by Pentagon (Участник № / Member № 74) on :
В ТМ 5.12 уже реализовано? А нельзя ли описать подробнее, как вычислить необходимые параметры для максимальной эффективности? Posted by AdAstra Technical Support (Участник № / Member № 4) on :
В нашем примере были взяты параметры пропускной способности шины винчестера и динамика изменения значений в базе каналов - см. сообщение выше.
![[Неодобрение / Frown]](frown.gif)
.![[Вращающиеся глаза / Roll Eyes]](rolleyes.gif)
![[Недоумение / Confused]](confused.gif)