Вызов sync / fsync замедляет ввод-вывод после 30 минут безотказной работы

После 30 минут безотказной работы при использовании Ubuntu 14.04 с ext4 гибридный SSD Я вижу, как многие процессы блокируют ввод-вывод с помощью iotop.

Основная причина этого замедления восходит к системному вызову Unix. sync.

Бег sync от терминала повторное использование может занять порядка 1-2 секунд, но ТОЛЬКО после 30 минут безотказной работы.

Чтобы доказать это, я сделал скрипт, который выводит время безотказной работы в секундах относительно времени, затраченного на выполнение синхронизации, и запускал его каждую секунду:

while true;
do
cat /proc/uptime | awk '{printf "%f ",$1}'; /usr/bin/time -f '%e' sync;
sleep 1;
done;

Я запустил приведенный выше сценарий, подождал около часа (система оставалась бездействующей) и построил график результатов в gnuplot (y = время в секундах для выполнения синхронизации, x = время безотказной работы в секундах):

Момент времени, когда график растет, составляет около 1780 (1780/60 = примерно 30 минут).

Ничего не должно записываться на диск в это время, кроме сценария, поэтому в кеше страницы не должно быть почти ничего после первой синхронизации, каждая последующая синхронизация будет записывать именно то, что записывается в сценарий, который будет примерно 100 байтов или так.

Когда я проверяю cat /proc/meminfo грязная строка (данные в кэше страниц, которые необходимо сохранить на диск?) и строка обратной записи (дисковый буфер HD?) равны нулю. Моя мысль была этим призванием sync сбрасывает эти дисковые кеши, но он все равно зависает, даже когда в этих кешах ничего нет, делает ли он что-то еще?

Эта проблема сохраняется после перезагрузки; например - если я жду 30 минут для замедления, а затем перезагружаюсь, замедление все равно будет. Если я отключаюсь, а затем перезагружаюсь, проблема исчезает через 30 минут.

Еще одно любопытство заключается в том, что когда я изучил приведенный выше график и увеличил масштаб области, где происходит замедление, я получил следующее:

Пики и впадины повторяются - это происходит с интервалом в 10 секунд от впадины к впадине.

Я также провел тесты hdparm (hdparm -t /dev/sda и hdparm -T /dev/sda) до замедления:

/dev/sda:
Timing cached reads:   23778 MB in  2.00 seconds = 11900.64 MB/sec
/dev/sda:
Timing buffered disk reads: 318 MB in  3.01 seconds = 105.63 MB/sec

и во время замедления:

/dev/sda:
 Timing cached reads:     2 MB in  2.24 seconds = 915.50 kB/sec
/dev/sda:
Timing buffered disk reads: 300 MB in  3.01 seconds =  99.54 MB/sec

Показывая, что фактическое чтение с диска не выполняется, но выполняется чтение из кэша, может ли это означать, что это связано с системной шиной, а не с HD?

Вот решения, которые я пробовал:

• Измените настройки вращения HD (возможно, HD переходил в режим энергосбережения?):

  hdparm /dev/sda -S252 #(set it to 5 hours before spindown)
  

• Измените тип журналирования файловой системы на обратную запись, а не на заказ, чтобы мы получили улучшения производительности - это не решает проблему, хотя и не объясняет 30-минутное время безотказной работы без замедления, когда я пробовал это, изменений не было.

• Отключен CRON, как кажется, через 30 минут раунда.

• Использование ЦП в порядке и полностью простаивает, поэтому нельзя винить ни один процесс, однако я пытался закрыть все службы, включая диспетчер сеансов (lightdm), это ничего не делает, поскольку я считаю, что проблема на более низком уровне.

• Анализ любых новых процессов, происходящих через 30 минут, показывает, что изменений нет - я сравнил результаты PS до и после, и нет никакой разницы.

Это только начало происходить около 2 недель назад, ничего не было установлено и никаких обновлений в это время не производилось. Я думаю, что эта проблема гораздо более низкого уровня, поэтому был бы очень признателен за некоторую помощь здесь, поскольку я невежественный, даже указание мне в правильном направлении было бы полезно.

Кэширование записи включено на рассматриваемом диске, я также пробовал отключить барьеры записи. Данные SMART на HD указывают на отсутствие проблем с самим HD, однако я подозреваю, что HD делает что-то загадочное, поскольку сохраняется после перезагрузки.