Сбой генерации rrdgraph при высокой нагрузке ввода-вывода

У нас есть производственная система с 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
кронтаб:

* * * * *               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, нет трассировки стека или подобного или доступного для установки.