Как можно оптимизировать wb-mqtt-db?

Добрый день.
Сейчас у меня база wb-mqtt-db лежит на USB-флешке и имеет размер 1,1 Гб. Правка конфига и перезапуск приводит к тому, что минут 20-25 процесс wb-mqtt-db что-то делает (проверяет целостность базы?) - все это время история не сохраняется и CPU контроллера сильно загружен.

  1. Можно ли перенести wb-mqtt-db вместе с базой на другой хост? Рядом есть сервер на core i3 с SSD и там бы все это работало на порядок быстрее.
  2. Если нет, то как это все можно оптимизировать? Хотя бы, чтоб перезапуск процесса wb-mqtt-db не вызывал 25-минутный перерыв сохранения истории.

Добрый день.
А подскажите, какое количество записей сейчас в базе (реально столько нужно)?
Для того чтобы проанализировать количество записей можно сделать так:
Ставим sqlite3

apt install sqlite3 -y

потом выполняем, Для подсчета количества записей по контролам (по источникам):

echo "select count(CHANNEL), (select device from channels where channels.int_id=data.channel) as DEVICE, (select control from channels where channels.int_id=data.channel) as CHANNEL from data group by CHANNEL;" | sqlite3 /mnt/data/var/lib/wirenboard/db/data.db

Расположение файла базы можно поменять, “database” в /etc/wb-mqtt-db.conf. и перенести но на сетевую шару, например nfs.

Для начала, как писал выше - надо посмотреть, что в базе. И, при необходимости - убрать лишние топики.
по умолчанию все в одну группу “all” пишется. Те топики, которые не надо хранить долго - можно вынести в отдельную.

Контролов много, но в каких-то кол-во записей 30-70, в каких-то десятки тысяч. Например, мне точно не нужна подробная история о напряжении на каждом подключенном модуле, а записей очень много:
68214|dimmer01|supply_voltage
68213|relay02|supply_voltage
68212|relay03|supply_voltage

Вопрос в том, что это все настраивается очень негибко. Некоторые каналы мне нужно сохранять с высоким разрешением (раз в 5-10 сек). Иногда нужно ненадолго это включить, а через 1-2 часа вернуть стандартные настройки. Сейчас каждое такое действие останавливает запись истории на 25 минут, пока процесс wb-mqtt-db что-то перечитает.

Второе. Вижу в базе множество записей с тестовых и давно удаленных устройств. При удалении их из очереди, как я понимаю, из базы оно не удаляется. Как теперь это все почистить? Только руками командами sqlite? Было бы неплохо сделать какой-то скрипт или кнопку, которая бы очищала базу от неактуальных устройств.

А что это даст? Наборот, будет еще медленее по 100-Мбитному интерфейсу, чем с USB-флешки. Идея же в том, чтобы сам процесс wb-mqtt-db работал на другом более производительном хосте, а history в веб-интерфейсе просто обращался бы к этой базе по сети. Но я не нашел никаких настроек в плане указания хоста и даже в исходниках этого нет.

Сейчас у меня вот такой конфиг. Можете оценить, что здесь не оптимально и как лучше сделать?

    "database": "/mnt/usbflash/var/lib/wirenboard/db/data.db",
    "debug": false,
    "groups": [
        {
            "channels": [
                "energy01/ch09_active_power"
            ],
            "min_interval": 10,
            "min_unchanged_interval": 120,
            "name": "Energy Ch9",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "energy01/ch06_active_power"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "Energy Ch6",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "zb_climate01/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "zb_climate01_temperature",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "zb_climate02/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "zb_climate02_temperature",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "zb_climate03/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "zb_climate03_temperature",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "zb_climate04/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "zb_climate04_temperature",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "zb_climate05/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "zb_climate05_temperature",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "oregon_rx_1D20_15_1/temperature"
            ],
            "min_interval": 30,
            "min_unchanged_interval": 120,
            "name": "oregon_rx_1D20_15_1_temperature",
            "values": 100000,
            "values_total": 1000000
        },

        {
            "channels": [
                "zb_relay01/power"
            ],
            "min_interval": 10,
            "min_unchanged_interval": 60,
            "name": "zb_relay01_power",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "energy01/ch02_active_power"
            ],
            "min_interval": 10,
            "min_unchanged_interval": 120,
            "name": "Energy Ch2",
            "values": 100000,
            "values_total": 1000000
        },


        {
            "channels": [
                "temperature02/voltage"
            ],
            "min_interval": 10,
            "min_unchanged_interval": 60,
            "name": "temperature02_voltage",
            "values": 100000,
            "values_total": 1000000
        },
        {
            "channels": [
                "relay05/supply_voltage"
            ],
            "min_interval": 10,
            "min_unchanged_interval": 60,
            "name": "relay05_voltage",
            "values": 100000,
            "values_total": 1000000
        },



        {
            "channels": [
                "+/+"
            ],
            "min_interval": 60,
            "min_unchanged_interval": 1200,
            "name": "all",
            "values": 500000,
            "values_total": 5000000
        }
    ]
}

Да, автоматически не удаляется. Предполагалось что удалится “по устареванию”. Насчет скрипта - да, подумаю, сделать можно, вычитать из MQTT список существующих и создать запрос, который удалит не входящих в него.

Тут немного неверный подход, использовать контроллер для вращения большой базы - чересчур оптимистично. Как по мне более правильный - вынос данных наружу, в другую базу. Например

Но можно и zabbix использовать.
Кстати, займусь пожалуй написанием статьи по установке Grafana +influx

Тут надо самому проверить и в исходники глянуть - как будут обрабатываться топики, которые попадают одновременно в две группы.

Так а есть какие-то критерии, какая база уже “большая” для WB? В кол-ве values или устройствах, или объему на диске. Она в принципе может быть и небольшой - основная часть устройств обновляется редко, а таких, где нужно большое разрешение - немного. Но чтобы это корректно описать, получается, нужно каждый девайс описывать в конфиге wb-mqtt-db?

В целом, если бы не 25-минутная задержка при изменении конфига (почему нельзя конфиг подгружать “на лету”?), то текущая ситуация меня бы вполне устраивала - пусть там лежат хоть 5 Гбайт данных, глубоко из архива доставать нужно редко, а история за дней 10-15 отрисовывается достаточно быстро.

это все потому что запись в базу ужасно криво сделанна. Значение “1”, а записывается “0.3333333” и это нигде не настроить. Про стратигии хранения с прореживанием вообще молчу. База засирается и WB тупо виснет, задачи останавливаются. Потом конечно перезагружается по таймауту. Но сам факт того чтобаза вешает железо - это жесть.

А можете дать свою базу?
Как раз для оптимизации нужен такой вот “пример”.

Подскажите, пожалуйста, какой запрос в БД нужно отправить, чтобы корректно почистить какие-либо данные не испортив саму базу? Вот сделал сортировку по кол-ву записей, топ выглядит так:
477731|cpu_load|load
472392|energy01|ch06_total_power
101920|energy01|ch06_active_power
100805|temperature02|voltage
100782|energy01|ch09_active_power
100686|relay05|supply_voltage
98976|energy01|ch02_active_power
68516|wb-adc|Vin
68516|wb-adc|5Vout
68515|power_status|Vin
68515|wb-adc|A1
68515|wb-adc|A2
68515|wb-adc|A3

Например, 477731|cpu_load|load - это давно удаленное виртуальное устройство, и историю с него я бы тоже хотел полностью почистить.

472392|energy01|ch06_total_power - тут я бы хотел удалить старейшие 400 тыс записей, оставить последние.

Какими запросами в БД это можно сделать?

9 сообщений были перенесены в новую тему: Какая-то проблема с mosquitto

Это не так. В базу записываются средние, минимальные и максимальные значения за период, указанный в настройках. Обработка дискретных на графиках при выводе исправлена в свежих версиях интерфейса.

Я не нашел ни одного случая здесь или во внутреннем трекере, похожий на то, что вы описываете. Пожалуйста приложите ссылку или создайте тему с подробным описанием здесь, чтобы мы могли исправить.

Без этого могу сочувствовать, но помочь - не могу, к сожалению.