У нас есть производственная система с 4-ядерным процессором, которая выполняет много задач, с постоянной очередью процессов и обычной загрузкой ~ 1,5.
В ночное время мы делаем интенсивные IO вещи с postgres. Мы генерируем график, показывающий загрузку / использование памяти (rrd-updates.sh). Это иногда дает сбой в ситуациях с высокой нагрузкой ввода-вывода. Это происходит почти каждую ночь, но не в каждой ситуации высокого IO.
Мое "нормальное" решение было бы заключаться в том, чтобы создать хороший и полезный материал для postgres и увеличить первоочередность генерации графа. Однако это все еще не удается. Генерация графа является полупроходным с флоком. Я регистрирую время выполнения и для генерации графика это до 5 минут при высокой нагрузке ввода-вывода, что, по-видимому, приводит к отсутствию графика на срок до 4 минут.
Таймфрейм точно совпадает с активностью postgres (это иногда случается и в течение дня, но не так часто). Ионизация до реального времени (C1 N6 graph_cron против C2 N3 postgres), значительно выше postgres (-5 graph_cron против 10 postgres ) не решил проблему.
Предполагая, что данные не собраны, дополнительная проблема заключается в том, что ionice / nice все еще не работает.
Даже с 90% IOwait и нагрузкой 100 я все еще мог использовать команду генерации данных бесплатно без задержки более чем на 5 секунд (по крайней мере, при тестировании).
К сожалению, я не смог воспроизвести это точно в тестировании (имея только виртуальную систему разработки)
Версии:
Ядро 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3
Оборудование: жесткий диск SAS 15K RPM с LVM в оборудовании Параметры
монтирования RAID1 : ext3 с rw, ошибки = remount-ro
Планировщик: CFQ
crontab:
* * * * * root flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh
Похоже, есть что-то похожее на BUG от Mr Oetiker на github для rrdcache:
https://github.com/oetiker/rrdtool-1.x/issues/326
Это на самом деле может быть моей проблемой (одновременные записи), но это не объясняет cronjob, чтобы не потерпеть неудачу. В предположении, что на самом деле у меня есть 2 одновременных записи, flock -nбудет возвращен код выхода 1 (для man-страницы, подтверждено в тестировании). Поскольку я также не получаю письмо с выводом и замечанием, что cronjob действительно работает нормально все остальное время, пока я нахожусь как-то потерян.
Пример вывода:
Основываясь на комментарии, я добавил важный источник скрипта обновления.
rrdtool update /var/rrd/cpu.rrd $(vmstat 5 2 | tail -n 1 | awk '{print "N:"$14":"$13}')
rrdtool update /var/rrd/mem.rrd $(free | grep Mem: | awk '{print "N:"$2":"$3":"$4}')
rrdtool update /var/rrd/mem_bfcach.rrd $(free | grep buffers/cache: | awk '{print "N:"$3+$4":"$3":"$4}')
Что мне не хватает или где я могу проверить дальше?
Помните: продуктивная система, так что нет dev, нет трассировки стека или подобного или доступного для установки.
cronзахват STDERR где-нибудь? На FreeBSD я обычно запускаю их,periodic every5и у меня есть,/var/log/periodic.every5что обычно фиксирует любые ошибки. Я также пошатнулся бы о трех сценариях и, возможно, повернул бы порядок, чтобы увидеть, висит ли один из них. Большая часть моего опыта работы с RRDTool была сcricketсобственной регистрацией. Вcricketжурналах были превосходны для поиска проблем. Вы действительно собираете каждую минуту? (* * * * * вместо * / 5 * * * *) Какова гранулярность графика? RRD по умолчанию с 5-минутными интервалами.Ответы:
Я думаю, что не rrdtool не может обновить график, а данные не могут быть измерены в этой точке. Кстати, ваш метод измерения статистики процессора и памяти просто неверен, потому что он дает вам мгновенный результат. Загрузка процессора и памяти может резко изменяться в течение 60-секундного интервала, но вы примете только одно значение. Вы действительно должны рассмотреть возможность получения данных SNMP, которые дают средние данные за интервал. Плюс, вся труба кажется более дорогой и медленной, чем вызов snmpget. Может быть основной причиной пробелов.
источник