Sergei
Forum Professor / Завсегдатай форума
Участник № / Member № 161
отправлено / posted
В проекте завел каналы "ПотеряСПАД", которые несколько раз в сутки осуществляют принудительную запись всех каналов в СПАД. Теоретически это должно было увеличить скорость обращения к архиву за счет сохранения значений редко изменяющихся каналов. Однако, надежды, кажется, не оправдываются . Глобальный регистратор пишет в арихв размером 100 Мб около 600 каналов. При отработке канала ПотеряСПАД видно, как увеличивается очередь, что свидетельствует о правильной его работе. Но, при работе с Supervisor-ом переход на конец архива и дальнейшая работа, как то переход на шаг или переход по экранам, все так же сопровождается задержкой в 3-5 мин. Другими словами - все равно дико тормозит. При этом архивные тренды работают вполне нормально с задержкой всего около 5-15 сек (так было и раньше). Проводились ли эксперименты, определяющие влияние результатов работы этого канала на скорость выборки из архива? Почему возникают задержки? Что он пытается найти, если вот только что были записаны ВСЕ каналы?
Сообщения / Posts 157 | Из / From: russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Какой у Вас релиз ТМ? Дело в том, что для корректной работы принудительного сохранения канал ДИАГНОСТИКА-Потеря СПАД должен быть OUTPUT. Но до настоящего релиза 5.11 в РБК была ошибка - он не позволял установить для этого канала тип в OUTPUT. Поэтому есть сомнения в том, что механизм принудительного сохранения у Вас работает корректно. Ипытания нами проводились и они действительно практически доказали, что механизм принудительного сохранения позволяет значительно оптимизировать перемещение по архивным данным.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Sergei
Forum Professor / Завсегдатай форума
Участник № / Member № 161
отправлено / posted
Релиз инструментальной - 5.11, ГР - 5.11, supervisor - 5.10 Я знаю об этой ошибке (сам писал в форум)Сохранение в СПАД действительно работает. Это видно и по подскакивающему значению очереди и по содержимому архива при просмотре через ODBC. Только почему-то время обращения к архиву не уменьшилось. Такое ощущение, что архив начинает просматриваться с начала и до запрошенного момента. При переходе на начало архива задержки практически не ощущаются. Если это действительно так, то это все объясняет. Как происходит запрос? Извлекаются данные за запрошенный момент и раньше пока не найдутся значения для всех каналов? Тогда это должно работать. Как часто рекомендуется производить принудительное сохранение? Раз в сутки, раз в час, или это подбирается экспериментально исходя из приемлемой задержки при запросе?
Сообщения / Posts 157 | Из / From: russia
| IP / IP: IP адрес / IP address |
отправлено / posted
Период принудительного сохранения естественно зависит от динамики сохранения данных в СПАД. Мы производили испытания с почасовым принудительным сохранением данных. Однако период зависит от соотношения объемов сохраняемых данных с более высокой динамикой записи и более низкой. Чем больше объем сохранения данных в промежутках между сохранением данных с меньшей динамикой, тем меньше должен быть период принудительного сохранения данных в архив. На эти выходные мы попробуем смоделировать и оставить работать два одинаковых проекта с сохранением данных в СПАД с различной динамикой накопления истории. Только в одном из проектов будет реализовано принудительное сохранение данных. В понедельник проведем испытания и попробуем определить примерную кореляцию периода принудительного сохранения от объемеов и динамики данных. О результатах сообщим в нашем форуме.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Исследования заняли некоторое время, поэтому мы берем дополнительный таймаут до вторника (15.10.2002).
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
отправлено / posted
Параметры проекта для проведения испытаний: СПАД архив - 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%.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Sergei
Forum Professor / Завсегдатай форума
Участник № / Member № 161
отправлено / posted
Спасибо за информацию. Должен сказать, что по мере перезаписи архива данными с принудительным сохранением время доступа уменьшается. Так, если ранше переход на конец архива осуществлялся примерно за 5 мин, то при перезаписи архива процентов на 70, уже около 30-40 сек. Это уже кое-что. Одно неприятно: после того как переход на время произошел, переход по экранам вызывает повторное подчитывание значений и соответсвенно такие же задержки. Разве переход на время не вызывает чтение среза данных? Если это так, то зачем заново перечитывать архив?
Сообщения / Posts 157 | Из / From: russia
| IP / IP: IP адрес / IP address |
Styxx
Forum Member / Участник форума
Участник № / Member № 74
отправлено / posted
В ТМ 5.12 уже реализовано? А нельзя ли описать подробнее, как вычислить необходимые параметры для максимальной эффективности? Сообщения / Posts 60 | Из / From: Ukraine
| IP / IP: IP адрес / IP address |
отправлено / posted
В нашем примере были взяты параметры пропускной способности шины винчестера и динамика изменения значений в базе каналов - см. сообщение выше.
Сообщения / Posts 17321 | Из / From: Россия
| IP / IP: IP адрес / IP address |
Printer-friendly view of this topic
![[Неодобрение / Frown]](frown.gif)
.
![[Вращающиеся глаза / Roll Eyes]](rolleyes.gif)
![[Недоумение / Confused]](confused.gif)
