У нас есть производственная система с 4 ядрами, которая выполняет множество cronjobs, имеет постоянную очередь процессов и обычную нагрузку ~ 1,5.
В ночное время мы выполняем некоторые операции с интенсивным вводом-выводом с помощью postgres. Мы генерируем график, показывающий использование нагрузки / памяти (rrd-updates.sh). Иногда это "дает сбой" в ситуациях с высокой нагрузкой ввода-вывода. Это происходит почти каждую ночь, но не во всех ситуациях с высоким уровнем ввода-вывода.
Моим "нормальным" решением было бы красиво и ионизирующе использовать postgres и повысить приоритет генерации графов. Однако это все еще не удается. Генерация графа полузащитная с flock. Я записываю время выполнения, и для генерации графика оно составляет до 5 минут при высокой нагрузке ввода-вывода, что, по-видимому, приводит к отсутствию графика до 4 минут.
Временные рамки точно соответствуют активности postgres (это иногда происходит и в течение дня, хотя и не так часто) Ионизация до prio в реальном времени (C1 N6 graph_cron vs C2 N3 postgres), намного выше postgres (-5 graph_cron vs 10 postgres) ) проблему не решило.
Предполагая, что данные не собираются, дополнительная проблема заключается в том, что ionice / nice почему-то все еще не работает.
Даже с 90% IOwait и загрузкой 100 я все еще мог использовать команду генерации данных без задержки более, чем, возможно, 5 секунд (по крайней мере, при тестировании).
К сожалению, я не смог точно воспроизвести это при тестировании (имея только виртуализированную систему разработки)
Версии:
Ядро 2.6.32-5-686-bigmem
Debian Squeeze rrdtool 1.4.3
Аппаратное обеспечение: жесткий диск SAS 15 000 об / мин с LVM в аппаратном RAID1
варианты крепления: ext3 с rw, errors = remount-ro
Планировщик: CFQ
crontab:
* * * * * root flock -n /var/lock/rrd-updates.sh nice -n-1 ionice -c1 -n7 /opt/bin/rrd-updates.sh
Кажется, есть некоторая возможно связанная ОШИБКА от г-на Oetiker на github для rrdcache:
https://github.com/oetiker/rrdtool-1.x/issues/326
На самом деле это может быть моей проблемой (одновременная запись), но это не объясняет, что cronjob не сработает. В предположении у меня на самом деле есть 2 одновременных записи flock -n
вернет код выхода 1 (на страницу руководства, подтвержденную при тестировании), так как я не получаю электронное письмо с выводом и наблюдение, что 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}')
Что я пропускаю или где я могу проверить дальше?
Помните: продуктивная система, поэтому никаких разработок, трассировки стека или аналогичного не доступно или не устанавливается.
Я предполагаю, что это не rrdtool, который не может обновить график, а, скорее, данные не могут быть измерены в этот момент. Кстати, ваш метод измерения статистики процессора и памяти просто неверен, потому что дает мгновенный результат. Загрузка процессора и памяти может резко меняться в течение 60 секунд, но вы возьмете только одно значение. Вам действительно стоит подумать о том, чтобы взять данные SNMP, которые дают средние данные за интервал. Кроме того, весь канал кажется более дорогим и медленным, чем вызов snmpget. Может быть основная причина пробелов.