crower

В продолжение реабилитации кактуса попытался всё-таки подсунуть правильные счётчики.

Корковые по дескриптору, как и говорил, прицепились без проблем.

Процовый и мамковый однажды пытался по дексриптору опрашивать, но что-то не получилось. Вроде бы под руку попадались последние с одноимёнными дескрипторами.

Попробовал ещё раз, при этом внимательно разглядывая логи и экпериментально пытаясь понять где можно подкрутить чего.

И "о чудо!" - всё заработало.

Результат.

1. Так и не уловил откуда берутся дескрипторы. Перешерстил liblmsensors, snmp - пусто. Нигде не нашёл "CPU Temperature". Может в ядре? ;)
2. Если задать в кактусе Data Sources по имени, то он сам ресолвит номер сенсора и опрашивает счётчики по полученному номеру.
3. Поскольку в этот раз он по дескриптору выбрал первый (и правильный) счётчик, то лезть в исходники не понадобилось. Может потом как-нибудь, если заглючит.

Итого, пара вопросов остались не раскрыты. Но сейчас времени нет - ковыряю обновление реестра по приходу нового реестра. Давно была мысль такую штуку построить, когда нужно было вести актуальный реестр, закрывая устаревшие объекты, добавляя новые и апдейтя обновлённые. А тут попалась под руку национальный план нумерации и принялся кодировать эту задачу.
Наивняк. :)
Не то что бы это была супер сложная задача. Простая, в общем-то и нетрудная. Но требует очень высокой сосредоточенности при построении алгоритма. Одно дело обновлять объекты, которые суть точечные, а совсем другое - диапазоны, т.е. линейные объекты, которые нужно проверять на пересечения.
А правила при пересечении могут быть тоже разные. Может считаться что новый источник приоритетнее и просто закрывать перекрыващиеся. Но выцепить их не очень просто. Много критериев, которые нужно все держать в голове и поэтому легко что-нибудь упустить или запутаться. Сделал сначала пару индексируемых массивов, по которым и гулял. Всё бы хорошо, но где-то промахнулся и забыл сменить принцип закрытия (по уиду заменил на индекс) и в результате стал оживлять сплайснутые элементы массива. Пока искал где я из оживляю, и думать как избежать оного, пришла в голову мысль, а нахрена я использую индексный подход? Тут же в чистом виде получается стек. Собственно сам стек - это массив, который сортирую (из файла) или получаю (из базы) сразу сортированным. Но дальше индекс на элементы нафиг не нужет.
Сказано - сделано.
В итоге алгоритм существенно упростился, стал более наглядным и работает более эффективно. И кстати, без глюков.
На счёт того, что я учёл все состояния и правильно обрабатываю их - не уверен. В реальных данных этого может не оказаться. Поэтому придётся генерировать тестовые наборы и на них проверять корректность алгоритма.
В итоге прога работает довольно шустро, генерит офигительный sql-скрипт и скармливает в базу. И вот тут-то получаются сущие тормоза. Исходный реестр содержит чертверть миллиона записей, трамбующий алгоритм склеивает смежные однотипные записи ужимая реесть процентов на десяток, а трамбущий скрипт получается на 29 тысяч апдейтов (закрывающих обновлённые записи), и на 8.3 тысячи из длинног инсерта. Дольше всего выполняются апдейты. Их бы пооптимизировать надо. Чтобы сразу пачками... О, есть мысль... Пошёл делать...