crower: (Crower)
Заглянул в кактус - упс… А на одном из компов кактус пыжится рисовать температуру винта, который давненько уже удалил. Во первых, неудачный был сигейт - куча битого высыпалось, а во-вторых, новая (относительно) ВД-шка вполне устраивает и по объёму 2Тб хватает. Раньше думал, наблюдая за тенденцией, что и этого фиг хватит, а теперь объём позволяет думать о "вечном" и время от времени обнулять ненужное. Тем более особо крупные файлы, как правило - видео, которое при большом желании (в чём, вообще-то, сомневаюсь) вытащить заново. Теперь времени фатально нет на то, чтобы хотя бы почитать что забукмарчил в очередь. И это при том, что во время занятых глаз и свободных ушей я это дело слушаю (что, конечно, заметно медленнее).

Итак. Перекидываю комп на график с меньшим количеством сенсоров. Пялюсь, на неправильные подписи к датчику, до которых руки не дошли. После минут десяти, неверной догадки, косячения и исправления, получаю красивую подпись. Говорю "Ага!" и правлю шаблоны на соседнем шаблоне для другого сервака. Типа заработало. Догадываюсь, что надо бы лучше поправить шаблон дата-соурса, а не графика, но уже ленюсь.
Внимательно разглядываю показания.
Блин. Снова слетели на одном ядре. Вроде уже и тестировал, и получал положительный результат, но за год его раз десять мотало. Вот как так может быть?
crower: (Crower)
В продолжение реабилитации кактуса попытался всё-таки подсунуть правильные счётчики.

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

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

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

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

Результат.

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

Итого, пара вопросов остались не раскрыты. Но сейчас времени нет - ковыряю обновление реестра по приходу нового реестра. Давно была мысль такую штуку построить, когда нужно было вести актуальный реестр, закрывая устаревшие объекты, добавляя новые и апдейтя обновлённые. А тут попалась под руку национальный план нумерации и принялся кодировать эту задачу.
Наивняк. :)
Не то что бы это была супер сложная задача. Простая, в общем-то и нетрудная. Но требует очень высокой сосредоточенности при построении алгоритма. Одно дело обновлять объекты, которые суть точечные, а совсем другое - диапазоны, т.е. линейные объекты, которые нужно проверять на пересечения.
А правила при пересечении могут быть тоже разные. Может считаться что новый источник приоритетнее и просто закрывать перекрыващиеся. Но выцепить их не очень просто. Много критериев, которые нужно все держать в голове и поэтому легко что-нибудь упустить или запутаться. Сделал сначала пару индексируемых массивов, по которым и гулял. Всё бы хорошо, но где-то промахнулся и забыл сменить принцип закрытия (по уиду заменил на индекс) и в результате стал оживлять сплайснутые элементы массива. Пока искал где я из оживляю, и думать как избежать оного, пришла в голову мысль, а нахрена я использую индексный подход? Тут же в чистом виде получается стек. Собственно сам стек - это массив, который сортирую (из файла) или получаю (из базы) сразу сортированным. Но дальше индекс на элементы нафиг не нужет.
Сказано - сделано.
В итоге алгоритм существенно упростился, стал более наглядным и работает более эффективно. И кстати, без глюков.
На счёт того, что я учёл все состояния и правильно обрабатываю их - не уверен. В реальных данных этого может не оказаться. Поэтому придётся генерировать тестовые наборы и на них проверять корректность алгоритма.
В итоге прога работает довольно шустро, генерит офигительный sql-скрипт и скармливает в базу. И вот тут-то получаются сущие тормоза. Исходный реестр содержит чертверть миллиона записей, трамбующий алгоритм склеивает смежные однотипные записи ужимая реесть процентов на десяток, а трамбущий скрипт получается на 29 тысяч апдейтов (закрывающих обновлённые записи), и на 8.3 тысячи из длинног инсерта. Дольше всего выполняются апдейты. Их бы пооптимизировать надо. Чтобы сразу пачками... О, есть мысль... Пошёл делать...
crower: (Crower)
Описанная ранее проблема повторилась. Но на этот раз я был готов и теперь готов предъявить улики. Перед сегодняшним рестартом (после обновления) было:
iso.3.6.1.4.1.2021.13.16.2.1.2.1 = STRING: "Core0 Temp"
iso.3.6.1.4.1.2021.13.16.2.1.2.2 = STRING: "Core1 Temp"
iso.3.6.1.4.1.2021.13.16.2.1.2.3 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.4 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.5 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.6 = STRING: "MB Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.7 = STRING: "MB Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.8 = STRING: "MB Temperature"

А стало:
iso.3.6.1.4.1.2021.13.16.2.1.2.1 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.2 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.3 = STRING: "CPU Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.4 = STRING: "MB Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.5 = STRING: "MB Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.6 = STRING: "MB Temperature"
iso.3.6.1.4.1.2021.13.16.2.1.2.7 = STRING: "Core0 Temp"
iso.3.6.1.4.1.2021.13.16.2.1.2.8 = STRING: "Core1 Temp"


Таким образом кактус не виноват. Как я уже писал, из-за одинаковости дескрипторов счётчиков невозможно гарантировать правильность выдёргивания нужных. Кстати, ставил эксперимент: в кактусе оказывался последний счётчик, что в случае с "CPU Temperature" и "MB Temperature" бессмысленно. Вот c "Core0 Temp" и "Core0 Temp" это сработает, а процовая и мамкина температура будут постоянно уползать.
Теперь нужно либо найти где определяется порядок счётчиков и обеспечить их фиксированную позицию, или сделать уникальные дескрипторы и отлавливать счётчики по ним.

Profile

crower: (Default)
crower

September 2017

S M T W T F S
     12
3456789
10111213141516
17 181920212223
24252627282930

Syndicate

RSS Atom

Style Credit

Expand Cut Tags

No cut tags
Page generated Sep. 21st, 2017 05:04 am
Powered by Dreamwidth Studios