Замедление работы с файлами

Работа с файлами и базами данных
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Замедление работы с файлами

Сообщение Artem.spb »

Вот такая неприятная особенность.
Навороченная система, где на входе раз в 5 сек 3 tdms файла.
Они собираются в один tdms
Этот один снова читается, уже другим потоком. Там сигналы разбираются на части и после небольшой обработки они в очередной раз пишутся в файлы. На этот раз по каждому каналу свой бинарный файл.
Не надо спрашивать, зачем так странно, так надо :)
Итого:
- папка с tdms
- вторая папка с tdms
- третья папка с тремя сотнями фолдеров, в каждой из которых каждые 5 сек появляется новый файл (размер 40-60 кБ, зависит от частоты канала). Периодически из этих папок удаляются файлы старше суток.
Собственно, эти мелкие файлы - суточный буфер с возможностью удаления старых данных (если есть более элегантное решение, буду крайне благодарен).

И ещё до кучи есть SQLite БД в которую кидаются расчётные данные. И при запуске программа подгружает из этой базы данные за последние сутки (ну и в памяти есть копия этой суточной истории)

Так вот проблема.
Первый запуск - всё довольно быстро быстро считывается, файлы быстро пишутся-читаются-удаляются.
Потом происходит страшное, пользователь загружает суточную историю по одному каналу, да ещё и с расчётом FFT, и прочими ужасами.
И тут система начинает замедляться. Чем дольше программа работает, тем медленнее идёт обработка этих бинарных файлов. Т.е. один раз нарисовать FFT - секунд 10-20, потом всё больше и больше, хотя файлы практически одни и те же, может, +-1 новый.
Если перезапустить программу, уже и чтение из БД идёт очень медленно. Несколько минут вместо нескольких секунд, а уж файлы читаются вообще со скрипом.
Если перезапустить :labview: , начинает работать нормально, но постепенно опять замедляется.

Памяти до дури (1Тб), диск быстрее некуда, в диспетчере задач процессор и диск заняты на несколько %%, т.е. дело не в производительности системы.

Файлы держу закрытыми, в памяти храню только массив имён. Пробовал открывать все при запуске - система умирает (17000 файлов на канал за сутки * 250 каналов = 4М ссылок - "к этому жизнь меня не готовила").
Так что при каждом чтении файла открываю-закрываю его.

Вопрос: что делать? Если способ спасти систему от тормозов?

Переносить функции чтения в другие потоки исполнения пробовал (instrument I/O)
ujin1
assistant
assistant
Сообщения: 103
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 5 раз
Поблагодарили: 14 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение ujin1 »

Что сделал я для работы с данными

1. Cкачал последнюю версию NI Linux RT (сейчас 22 Q3), установил, создал флешку для восстановления, установил NI Linux RT на пром компьютер, сконфигурировал для текущей версии Labview.
Таким образом избавился от тормозов присущих обычных ОС. Хотя NI Linux RT ОС не "жесткого", но все же реального времени
2. Установил из репозитория NI Postgresql сервер (сейчас 13 версия, до 22 Q3 в репозитории 9.4 версия если не ошибаюсь).
3. Добавил сохранение данных непосредственно в сервер Postgresql с помощью libpq

Компьютер ICO300. Процессор Intel Atom 1.4 ГГц, память 4 GB
Пробовал записывать около 1200 real 32bit - с частотой 10 раз в секунду (12000 значений в секунду) в простую таблицу с 1200 столбцами и меткой времени.
С такой нагрузкой сервер справляется с запасом не менее 90%. Мне необходимо было максимум 800 параметров сохранять раз в секунду.
На протяжении нескольких месяцев непрерывной записи около 600 параметров раз в секунду и чтения нескольких десятков параметров тормозов не наблюдается.
В параметрах производительности postgres пишут под миллион транзакций в секунду и сотни пользователей.
В postgresql есть типы данных с битовыми строками
Предлагаю заменить весь набор папок\файлов на сервер postgresql.
Изображение
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2106
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 19 раз
Поблагодарили: 15 раз

Re: Замедление работы с файлами

Сообщение Borjomy_1 »

Что говорит профайлер? Какие конкретно VI вызывают тормоза?
ujin1
assistant
assistant
Сообщения: 103
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 5 раз
Поблагодарили: 14 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение ujin1 »

Artem.spb писал(а): 21 сен 2022, 23:43 17000 файлов на канал за сутки * 250 каналов
17000 файлов * 250 каналов * 60кб/(файл*канал) = 243 GB
Прочитать с диска и загрузить такой объем в оперативную память.
Я сейчас попробовал прочитать и загрузить в XY Graf 10 каналов * 259200 значений (72 часа) * 4 байта/канал = 9,88 МБайт. Это заняло 9 сек в локальной сети.
Видимо мой вариант Вам не подойдет.
Изображение
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

ujin1 писал(а): 22 сен 2022, 09:32 Пробовал записывать около 1200 real 32bit - с частотой 10 раз в секунду (12000 значений в секунду) в простую таблицу с 1200 столбцами и меткой времени.
Мало записать, надо ещё и прочитать потом, чтобы график за выбранный период построить
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

Borjomy_1 писал(а): 22 сен 2022, 12:46 Что говорит профайлер? Какие конкретно VI вызывают тормоза?
Те самые, что с файлами работают. И чтение из БД, и потом работа с этими буферами.
Но я нашёл другого потенциального виновника.
Там при чтении буфером строится большой массив. Очень большой. Но в силу неопределённости размера, я решил не выделять его сразу, а билдить по ходу чтения. Похоже, проблема именно в этом. Надо переделать как-то, чтобы память разом выделялась.
Но это проблема на первом запуске. Странно, что при перезапуске программы всё тормозить начинает. Такое впечатление, что поиздевавшись над памятью, программа сама потеряла способность оптимально работать с этой памятью, а ещё и с файлами до кучи.
Буду дальше копать.
Borjomy_1

Activity Professionalism Silver
doctor
doctor
Сообщения: 2106
Зарегистрирован: 28 июн 2012, 09:32
Награды: 3
Версия LabVIEW: 2009..2020
Откуда: город семи холмов
Благодарил (а): 19 раз
Поблагодарили: 15 раз

Re: Замедление работы с файлами

Сообщение Borjomy_1 »

Ну вы представляете, что такое на каждом шаге увеличивать мегабайтный массив на один-два килобайта? Это выделение памяти заново и копирование. Мало того, в куче после этого остаются дыры, которые ни туда, ни сюда.
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

Borjomy_1 писал(а): 22 сен 2022, 17:52 Ну вы представляете, что такое на каждом шаге увеличивать мегабайтный массив на один-два килобайта? Это выделение памяти заново и копирование. Мало того, в куче после этого остаются дыры, которые ни туда, ни сюда.
Это я прекрасно понимаю. Не понятно только, при чём тут работа с файлами :)
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5345
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 25 раз
Поблагодарили: 65 раз

Re: Замедление работы с файлами

Сообщение IvanLis »

Artem.spb писал(а): 22 сен 2022, 17:55 Это я прекрасно понимаю. Не понятно только, при чём тут работа с файлами :)
Перед отображением делать ресемплинг, нет смысла отображать несколько миллионов отсчетов на экране с шириной 2к.
GUI потребляет очень много ресурсов, особенно при обновлении. Но тут нужно смотреть, что отображать: среднее/минимальное/максимальное за период или еще как.

Ну и хранить данные попробовать в СУБД, той же PostgreSQL или mySQL, при правильной настройке чтение и запись быстрее должны быть, но не факт.
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

IvanLis писал(а): 22 сен 2022, 20:42 Перед отображением делать ресемплинг, нет смысла отображать несколько миллионов отсчетов на экране с шириной 2к.
GUI потребляет очень много ресурсов, особенно при обновлении. Но тут нужно смотреть, что отображать: среднее/минимальное/максимальное за период или еще как.
Как оказалось, не так много, как выделение памяти 17000 раз под постепенно растущий массив.
Ну и там ещё FFT считается, так что ресемплинг - баловство.
Ну и хранить данные попробовать в СУБД, той же PostgreSQL или mySQL, при правильной настройке чтение и запись быстрее должны быть, но не факт.
Я не верю (и вообще-то эксперименты это подтверждают) что считать бинарный, до невозможности примитивный, файл по времени будет дольше, чем выгрузить этот же объём данных из базы.
Я для того и извращаюсь с 250 папками (для каждого канала), чтобы читать файл одним махом, а не бегать по нему в поисках нужного смещения для получения очередного одного значения из 4 миллионов. Получается что когда пользователь запрашивает график "от 4 до 18 часов", я вычисляю, что мне надо прочитать все файлы от x до y и дальше их читаю в цикле.Осталось оптимизировать выделение памяти под прочитанный результат.

Вторая причина - удаление истории.
Была бы возможность в системе сдвигать не только конец, но и начало файла, всё было бы гораздо проще, а так получается, что или хранить много файлов и удалять по одному, или хранить один большой, но при каждом удалении истории заново копировать весь объём.
Аватара пользователя
IvanLis

Activity Professionalism Tutorials Gold Man of the year 2012
Автор
guru
guru
Сообщения: 5345
Зарегистрирован: 02 дек 2009, 17:44
Награды: 7
Версия LabVIEW: 2015, 2016
Откуда: СССР
Благодарил (а): 25 раз
Поблагодарили: 65 раз

Re: Замедление работы с файлами

Сообщение IvanLis »

Artem.spb писал(а): 22 сен 2022, 21:52 Как оказалось, не так много, как выделение памяти 17000 раз под постепенно растущий массив.
Ну и там ещё FFT считается, так что ресемплинг - баловство.
С бинарниками понятно, если есть возможность точно вычислить необходимые файлы, то по скорости это будет соизмеримо с СУБД.

Тогда нужно выделать максимальный объем памяти под массив, в который будет выполняться чтение данных и работать с ним, а не переиндексировать каждый раз при чтении.
ujin1
assistant
assistant
Сообщения: 103
Зарегистрирован: 06 ноя 2020, 15:37
Версия LabVIEW: 19
Благодарил (а): 5 раз
Поблагодарили: 14 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение ujin1 »

Artem.spb писал(а): 22 сен 2022, 21:52 Я не верю (и вообще-то эксперименты это подтверждают) что считать бинарный, до невозможности примитивный, файл по времени будет дольше, чем выгрузить этот же объём данных из базы.
Я для того и извращаюсь с 250 папками (для каждого канала), чтобы читать файл одним махом, а не бегать по нему в поисках нужного смещения для получения очередного одного значения из 4 миллионов. Получается что когда пользователь запрашивает график "от 4 до 18 часов", я вычисляю, что мне надо прочитать все файлы от x до y и дальше их читаю в цикле.Осталось оптимизировать выделение памяти под прочитанный результат.
Сервер баз данных как раз этой работой и занимается. Занимает место на диске, записывает данные, организовывает индексы, делает выборку данных по критериям используя индексы, удаляет ненужные данные (например старые), держит место на диске от удаленных данных, проверяет целостность, выполняет сжатие, высвобождает место на диске по требованию.
Если называть вещи своими именами Вы разрабатываете сервер баз данных.
NI пишет, что формат TDMS обеспечивает High-Speed Streaming лучше чем базы данных. Насколько лучше. Возможно с Вашими объемами справится и сервер баз данных. В этом случае будет гораздо меньше работы/проблем.
Artem.spb писал(а): 22 сен 2022, 21:52 Вторая причина - удаление истории.
Была бы возможность в системе сдвигать не только конец, но и начало файла, всё было бы гораздо проще, а так получается, что или хранить много файлов и удалять по одному, или хранить один большой, но при каждом удалении истории заново копировать весь объём.
Опять же сервер баз данных этим постоянно занимается добавляет, удаляет, обновляет. Базы по нескольку терабайт так же имеются.
Сервера есть разные и развиваются давно. Маловероятно, что у Вас с ходу получится сделать лучше. И есть смысл делать лучше тогда, когда существующее не подходит.
Мой подход по сохранению формирования кортежа из значений (250) + метка времени очевидно не подходит.
Можно формировать waveform. Записывать в поле типа битовые данные + добавлять дополнительно метку времени для индекса. Метка начала содержится в Waveform тем не менее еще раз записывать в отдельный столбец.
Также можно сделать 250 столбцов waveform типа битовые данные и одну метку времени. Либо 250 таблиц для каждого сигнала. Нужно смотреть по ограничениям на размер кортежа.
Для проверки создать буфер чтения. Например время заполнения буфера 10 сек. Обновлять его в течении суток из базы. Таким образом исключить тормоза в этом месте.
Далее можно поработать с оперативной памятью (кушать следующий кусок слона).
Изображение
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

Я в курсе, для сего СУБД нужны.
Но.
Сейчас я просто читаю 17000 файлов, где поиск индексов занял микросекунды. И всего-то нужно заранее зарезервировать память.

А если это БД:
- запрос "значения для T1 < X < T2"
- база шуршит индексами и находит все значения, которые удовлетворяют условию
- собирает всё в кучу (не знаю, как выделяет память, резервирует исходя из количества, или тоже не оптимально)
- передаёт всё это мне. И не одним массивом, а кучей элементов (те самые 17000 отрезков)
- дальше я это снова должен объединить в один массив.
Максимум, на чём может случиться ускорение - это СУБД предскажет, что мне нужно и эти данные будет в памяти держать, а не с диска подгружать.
но
- двойное выделение
- передача огромных кусков данных БД->драйвер->программа
не верю :/

По TDMS интересная мысль, забыл, что они позволяют и удалять часть данных, но пока не придумал, как с координатами разобраться. Метку времени как-то придётся туда запихать.
Ну и есть ещё аргумент в пользу "фрагментации" данных: Для одного из графиков нужен каждый 5-сек фрагмент отдельно, по каждому FFT вычисляется и потом 2D график рисуется (цветной). Так что всё равно придётся читать по частям.


Но обсуждение потекло не в ту сторону, вопрос остался открытым.
Получается, что если часто дёргать (неоптимально) память, то :labview: замедляется. Причём и при обращениях к диску. Это при том, что ~90% памяти пустует.
Аватара пользователя
Vasiliy Baev

Activity Gold Bronze
leader
leader
Сообщения: 535
Зарегистрирован: 31 окт 2011, 09:02
Награды: 4
Версия LabVIEW: 2019
Откуда: Санкт-Петербург
Благодарил (а): 3 раза
Поблагодарили: 5 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Vasiliy Baev »

Попробуйте выделять память при помощи New Data Value Reference Function.
Artem.spb

Activity Автор
doctor
doctor
Сообщения: 2946
Зарегистрирован: 31 июл 2011, 23:05
Награды: 2
Версия LabVIEW: 12-18
Благодарил (а): 27 раз
Поблагодарили: 120 раз
Контактная информация:

Re: Замедление работы с файлами

Сообщение Artem.spb »

Vasiliy Baev писал(а): 23 сен 2022, 23:50 Попробуйте выделять память при помощи New Data Value Reference Function.
Здесь я это не представляю как прикрутить.
Если только перенести файлы в память (на этой машине её хватит)
Ответить

Вернуться в «Сохранение данных»