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

После 30 минут времени работы с помощью Ubuntu 14.04 с ext4 гибридным SSD я вижу, что много процессов блокируют IO, использующий 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, в конце концов?

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

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

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

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

• Отключенный КРОН, поскольку это, кажется, происходит после раунда 30 минуты.

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

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

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

Запишите, что кэширование включено на рассматриваемом диске, я также попытался отключить барьеры записи. УМНЫЕ данные по HD не указывают ни на какие проблемы с самим HD однако, у меня есть свои подозрения, это - HD, делающий что-то таинственное, поскольку это сохраняется после перезагрузок.