www.InTouch.su

Добрый день!

Стоит InSQL версии 9.0.1.0369. Количество тэгов total = 3436. Архивные блоки в папке Circular занимают ~20-25 Мб и имеют внутри по 17 файлов. Но по пока неустановленным причинам(возможно перебои поступления данных) в архивных блоках за некоторые дни число файлов очень велико (например 10965, 29321, 131129, 236137). В сумме( в папке Circular) получается больше 7млн. файлов. Вопрос: возможно ли какая-нибудь оптимизация с целью уменьшения числа файлов без потери архивных данных?

это явно ненормальная ситуация.
приведите примеры имён таких файлов.
какого они размера в байтах?

файлы с расширением sdt (имя qualityD4_132, qualityD4_227, qualityD4_231, ..... valueD4_132, valueD4_227.....) - размерами 67,74,81,95,96,102,936,963, 970 байт.
файлы с расширением onx (имя qualityD4_132, qualityD4_227, qualityD4_231, ..... valueD4_132, valueD4_227.....) - размерам 384 байта.
из больших файлов в этой же папке:
valueD4_1.sdt - 18 Мб
qualityD4_1.sdt - 1,5 Мб
valueD4_2.sdt - 636 кб
qualityD4_2.sdt - 439 кб
а потом всё меньше и меньше размером с увеличением счётчика в имени файла.

похоже на какой-то сбой в обработке данных приходящих вне окна реального времени.
система бесконечно добавляет новые потоки данных вместо использования имеющихся.
если загрузите zip-файл с каким-нибудь блоком истории, где больше 10,000 файлов, то может быть, смогу сказать что-нибудь более определённое.
склеить эти файлы нельзя, но если такие файлы продолжают множиться в каких-то блоках истории, то можно попытаться определить причину этого.

Вот скриншоты папки. Импорт данных происходит через файлы csv которое генерирует сторонее приложение. Было обнаружено что файлы в папке FastLoad не удалялись, их оказалось очень много. Почти 900тысяч. Файлы были вынесены и порциями закидывались в папку dataimport. Это было в январе. Но папки архивных блоков с большим количеством файлов встречаются и на ещё двух других серверах с InSQL, там с импортом файлов csv проблем не замечено.

Файлы с fastload csv данными должны быть помещены в папку C:\Historian\Data\DataImport\FastLoad, которую мониторит процесс aahManStSvc.exe, и как только он там замечает файл, то он его импортирует и если импорт прошёл успешно, то автоматически удаляет. Если при импорте файла возникла ошибка, то файл будет перемещён в папку C:\Historian\Support. B обоих случаях должно быть сообщение в логгере про то, что файл импортирован или нет. Если файлы скопились в той самой папке FastLoad, которую мониторит aahManStSvc, то это означает, что aahManStSvc не успевает обрабатывать файлы быстрее, чем они поступают и надо что-то с этим делать.
Дикое количество потоков данных в некоторых блоках истории объясняется неправильным образом организованным импортом данных внешней утилитой. Она должна либо накапливать гораздо больше данных для каждого fastload csv файла, либо вместо fastload импорта использовать обыкновенный csv импорт с ORIGINAL INSERT-ами. Разница в том, что fastload импорт всегда создаёт новый поток данных для каждого файла импорта, что описано в документации. То есть надо минимизировать число fastload файлов и запихивать в каждый файл как можно больше данных. Если посылать в каждом fastload файле малое число значений, то как раз и получится то, что получилось. Если использовать обыковенный csv импорт, который должен производиться в папку C:\Historian\Data\DataImport и csv файлы которого немного отличаются в заголовке, то он будет пытаться использовать уже имеющиеся потоки данных и создавать новые только когда имеющиеся превысят некоторый размер.
Если импорт данных через csv файлы является основным способом сбора данных для этой системы, я бы посоветовал попробовать версию 2014 R2 (11.6) построенной на системе хранения данных нового поколения, где описыаемые проблемы отсутствуют по определению.

Переключил импорт данных не через csv, а напрямую запись в БД. Вижу что данные поступают. В наличии три InSQL сервера для разных объектов, так вот на двух судя по логам идет обработка файлов из папки LateData, а на третьем сервере таких записет нет. Судя по трендам данные поступают везде. Возник вопрос, почему так?

Late Data начинают прокачиваться через aahManStSvc (систему хранения старых данных или данных введённых вручную) с этими сообщениями в логе, когда времена значений вываливаются за пределы окна реального времени, которое может быть максимально сконфигурировано до 5-ти минут. Я бы рекомендовал выяснить, является ли это выпадение из окна реального времени ожидаемым для вашего технологического процесса, или просто источник данных не синхронизирован по времени с компьютером хисториана. Если выпадения из окна реального времени не происходит, то данные пришутся в текущий (и возможно предыдущий) блоки истории процессом aahStoreSvc - системой хранения данных реального времени, что намного предпочтительнее со всех точек зрения. В этом идеальном случае, сообщения о пакетной обработке в логе быть не должно, но свежие данные должны успешно показываться.

Тогда понятно почему на третьем сервере, где нет информации об импортировании latedata сыпятся ошибки "Values in the past did not fit within the realtime window; discarding data".
Данные в InSQL заливает ПО, в котором(подозреваю) реализован механизм доопроса данных с нижних по иерархии объектов при сбоях связи. По характеру данные: мгновенные ТИ, усредненные за 30 сек те же ТИ и данные из счетчиков электроэнергии (статистика - расход за сутки, расход за 30минут, расход за 5 минут). Вот данные со счётчиков фактически могут иметь метку времени вне окна реального времени если были доопрошены позже.

Теперь осталось понять где крутить чтобы и третий сервер принимал данные latedata.

upd: Нашел, в топиках в IDAS необходимо просто выбрать Enable Late Date...