Custom Query (656 matches)

Мотивация была описана #654

В плате SW-01 организован отдельный "журнал аварий", в который наносятся возникающие аварии, а также фиксируется время из завершения. Журнал организован в виде базы данных sqlite. Иногда при эксплуатации аппаратуры возникают ситуации, когда идет постоянный поток событий - периодическое возникновение и пропадание аварий (например из-за регулярного пропадания и восстановления входного сигнала на портах оборудования). В такой ситуации события могут поступать быстрее, чем они записываются в базу данных. Такая ситуация приводит к повышенной загрузке системы и возможным потерям записываемой в журнал аварий информации.

Был проведен ряд тестов, которые показали, что при возникновении аварий новые записи в БД (INSERT) записываются за константное время, в то время как запросы завершения аварий (UPDATE) выполняются за линейное время, и-з за чего при большом размере БД (100000 записей) производительность падает до единиц запросов в секунду.

Предлагается оптимизировать запись в БД завершений аварий следующим образом:

• При добавлении новой записи об аварии в БД сохранять ROWID в памяти в специальном хэше. В качестве ключа использовать комбинацию номера слота и oid аварии. Максимальный размер кэша ограничить достаточно большим разумным числом (например 1000), чтобы туда помещалось подавляющее большинство активных аварий в блоке (в идеале - все).
• При завершении аварии искать соответствующий ROWID в кэше по ключу slot-oid, и если он найден, обновлять запись по условию WHERE ROWID=N. Если ROWID в кэше не найден (из-за переполнения кэша), выполняется fallback на старый вариант запроса WHERE slot=S AND oid='xxxxx' AND end IS NULL.

Как показали эксперименты, запрос записи завершения аварии по ROWID выполняется за константное время. Таким образом, общая производительность записи в БД составляет около 230 запросов в секунду при использовании UBIFS и около 60 запросов в секунду при использовании JFFS2 независимо от размера БД.

Наши пользователи иногда используют одну из плат SW-01 в сети в качестве сервера времени(ну нет у них других серверов времени). Это бывает удобно для синхронизации времени на удалённых блоках в сети, а также Sip-телефонах и прочем оборудовании от центрального блока на узле связи, на котором время периодически контролируется/подводится вручную. Однако внутренний источник времени платы SW-01 (Сервер 127.127.1.0) по умолчанию имеет стратум 14 и, а значит для клиентов такой сервер SW-01 будет иметь стратум 15. Насколько я понял, от источника с таким низким уровнем иерархии многие устройства "не хотят" синхронизировать время (либо потому что 15 - это самый нижний уровень иерархии, либо потому что их внутренний источник имеет стратум выше). Предлагаю добавить настройку стратума для сервера 127.127.1.0, чтобы пользователь мог на центральном блоке - источнике синхронизации времени установить меньшее значение стратума.