LINUX.ORG.RU

Тормоза при обращении к жёстким дискам


0

1

При синхронизации папки весом в несколько десятков/сотен гигабайт посредством rsync или даже при простом копировании наблюдаются тормоза, прокрутка в браузере подтормаживает, вбитый текст появляется через несколько секунд, спонтанные замирания всего экрана вплоть до курсора мыши. Диски — SATA II, поставленные в RAID 1, с них происходит чтение, так что по идее, у меня не самые страшные тормоза, которые могут быть, но и они работать мешают. Провёл несколько тестов с hdparm

Своп откючён, торренты отключены, rsync остановлен

hdparm -T

 Timing cached reads:   3208 MB in  2.00 seconds = 1604.27 MB/sec
 Timing cached reads:   3316 MB in  2.00 seconds = 1657.90 MB/sec
 Timing cached reads:   3154 MB in  2.00 seconds = 1576.83 MB/sec
 Timing cached reads:   3170 MB in  2.00 seconds = 1584.24 MB/sec
 Timing cached reads:   3126 MB in  2.00 seconds = 1563.06 MB/sec

Здесь и далее вывод hdparm -t

 Timing buffered disk reads: 250 MB in  3.05 seconds =  81.96 MB/sec
 Timing buffered disk reads: 244 MB in  3.02 seconds =  80.92 MB/sec
 Timing buffered disk reads: 246 MB in  3.00 seconds =  81.96 MB/sec
 Timing buffered disk reads: 250 MB in  3.01 seconds =  83.03 MB/sec
 Timing buffered disk reads: 244 MB in  3.00 seconds =  81.25 MB/sec

Включаем торренты

 Timing buffered disk reads: 230 MB in  3.01 seconds =  76.35 MB/sec
 Timing buffered disk reads: 232 MB in  3.00 seconds =  77.24 MB/sec
 Timing buffered disk reads: 208 MB in  3.06 seconds =  67.92 MB/sec
 Timing buffered disk reads: 196 MB in  3.09 seconds =  63.51 MB/sec
 Timing buffered disk reads: 220 MB in  3.06 seconds =  71.98 MB/sec

Включаем rsynс (с SATA II RAID1 на USB HDD)¹

 Timing buffered disk reads: 180 MB in  3.04 seconds =  59.30 MB/sec
 Timing buffered disk reads: 186 MB in  3.02 seconds =  61.63 MB/sec
 Timing buffered disk reads: 188 MB in  3.02 seconds =  62.29 MB/sec
 Timing buffered disk reads: 134 MB in  3.02 seconds =  44.34 MB/sec²
 Timing buffered disk reads: 176 MB in  3.00 seconds =  58.65 MB/sec

¹ — хоть результаты отстают несильно, завершения каждой процедуры приходилось ждать по две минуты.
² — здесь отдача торрентов подскочила с 800 KiB/sec до 1 MiB/sec.

Последний тест показал, что проблема скорее всего не в дисковой подсистеме, а в процессорном времени и планировщике. Настройки конфига ядра на этот счёт выставлены по умолчанию

SCHED_AUTOGROUP [=y] 
SLUB [=y]
DEFAULT_CFQ [=y]
SCHED_SMT [=y]
SCHED_MC [=y]
SATA_AHCI [=y]
SCSI_DMA [=y]

В /etc/make.conf вроде ничего криминального

# uname -a
Linux 3.0.6-gentoo #1 SMP Wed Oct 12 01:05:26 MSD 2011 x86_64 Intel(R) Core(TM)2 Duo CPU E7400 @ 2.80GHz GenuineIntel GNU/Linux
# grep CFLAGS /etc/make.conf
CFLAGS="-march=core2 -O2 -pipe -fomit-frame-pointer --param l1-cache-size=32 --param l1-cache-line-size=64 --param l2-cache-size=3072 -msse4.1"

Deleted
Ответ на: комментарий от Deleted

Собственно, новые результаты: специально поставил и торренты, и rsync, и ритмбокс обновлять библиотеку заставил, и в тунаре лазил, и браузером шуршал — всё чудесно, никаких замираний, а падение в скорости как раз показывает, что шедулер работает.

 Timing buffered disk reads: 202 MB in  3.02 seconds =  66.95 MB/sec
 Timing buffered disk reads:  60 MB in  3.22 seconds =  18.65 MB/sec
 Timing buffered disk reads: 148 MB in  3.01 seconds =  49.14 MB/sec
 Timing buffered disk reads:  66 MB in  3.03 seconds =  21.79 MB/sec
 Timing buffered disk reads:  92 MB in  3.10 seconds =  29.68 MB/sec

Deleted
()
Ответ на: комментарий от Deleted

Отличный патч, он как рукой снимает тормоза при работе с диском

SergMarkov
()
Ответ на: комментарий от SergMarkov

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

gaga
()
Ответ на: комментарий от gaga

Кто его знает, Линус точно также годами динамит патчи от коливаса, которые тоже для десктопа, и вместо них сует «знаменитый патч» cgroups, никому не нужный, кроме него самого с его компиляцией на стопицтот терминалах одновременно

SergMarkov
()
Ответ на: комментарий от gaga

>> почему нельзя запилить все эти шедулеры в ядро, чтобы можно было переключать их при загрузке параметром?

Там четыре шедулера, которые можно переключать онлайн, а также параметром ядра при загрузке. Отсутствие среди них BFQ — это уже другой вопрос.

GotF ★★★★★
()
Ответ на: комментарий от GotF

Вот уж век живи - век учись, а я все время думал, что для смены шедулера надо ядро пересобирать. Но все равно странно, что линус не принимает патчи коливаса, которые реально помогают на десктопе.

gaga
()
Ответ на: комментарий от gaga

У патчей Коливаса есть неприятная особенность: они хорошо подходят ТОЛЬКО для десктопа, что для корпораций не есть хорошо. Было бы неплохо BFQ попробовать. Никто не знает, есть реп в OBS для суси, или нужно по старинке вручную собирать?

Rakot ★★
()
Ответ на: комментарий от Rakot

Ну и что ? Никто ведь не заставляет его по умолчанию включать

SergMarkov
()
Ответ на: комментарий от SergMarkov

Если внимательно посмотреть на ссылку, будет заметно, что она почти та же самая.

Deleted
()
Ответ на: комментарий от GotF

Каких четыре? У меня по умолчанию были только Deadline, CFQ и No-op, который пробка, а не шедулер. И как их переключать онлайн?

Deleted
()
Ответ на: комментарий от SergMarkov

Что кстати странно, учитывая, что красношапка является автором половины Gnome DE.

Deleted
()
Ответ на: комментарий от Deleted

О, забыл насчёт переключать. Так:

# echo noop > /sys/block/sda/queue/scheduler

No-op, который пробка, а не шедулер

Правильно, шедулер должен быть железным, то есть NCQ.

GotF ★★★★★
()
Ответ на: комментарий от GotF

>шедулер должен быть железным, то есть NCQ

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

gaga
()
Ответ на: комментарий от gaga

>> Плюс, реально хорошо работает он мало где.

У меня работает хорошо :)

железный шедулер не учитывает приоритеты io для каждого процесса

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

GotF ★★★★★
()
Ответ на: комментарий от GotF

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

Могу только порадоваться за тебя. У меня регулярно наблюдается 12309 или что-то очень похожее на него, когда свободной памяти остается процентов 15-20 (своп отключен). Поэтому раз в три-четыре дня меня спасает ресет, ибо домашний комп используется исключительно как браузер и разбираться-конпелировать-менять там что-то лень. И после каждого такого ресета я проклинаю гребаный шедулер, 12309 и все, что с этим связано. (я настолько ленив, что, купив два месяца назад новый комп для избавления от этих страданий, до сих пор его даже не распаковал)

gaga
()
Ответ на: комментарий от GotF

Ага, выпилили. Кстати, NCQ же по идее хардварная вещь, ей драйвер должен только очереди на чтение и запись подавать. Почему тогда везде и всюду в пару к NCQ ставят именно No-op, а не тот же дефолтный CFQ? Какая NCQ разница, кто и как сортировал очередь до него? Или всё равно накопит и отсортирует оп-своему, так что лучше было и не сортировать?

У меня работает хорошо :)

Можешь померить? :3

Алсо, мне, кажется, тесты с NCQ не светят
# dmesg | grep NCQ
#

Deleted
()
Ответ на: комментарий от Deleted

>> Почему тогда везде и всюду в пару к NCQ ставят именно No-op, а не тот же дефолтный CFQ?

Я не разбираюсь в этих тонкостях, но везде говорят, что другие планировщики будут создавать лишние помехи. У себя не замечал каких-то дурных эффектов от CFQ, но всё же использую No-op.

Можешь померить?

А чего там мерить? Не тормозит — значит, всё работает как надо.

GotF ★★★★★
()
Ответ на: комментарий от GotF

А, что ещё забыл-то!
У меня /sys/block/dm-{0,1,2,3,5,6,7,8}/queue/scheduler содержат none, хотя по вышеупомянутым результатам видно, что отголоски 12309 отступили за белый круг, обведённый вокруг ведра.
По естественным причинам (работает — не трогай) желания делать туда echo у меня не было. Неплохо бы позвать кого-нибудь, чтобы посмотреть, выкинули ли эту фичу для 3.0 или это спешл фор ми.

Deleted
()
Ответ на: комментарий от GotF
# cat /sys/block/sd*/queue/scheduler 
noop deadline [cfq] bfq 
noop deadline [cfq] bfq 
noop deadline [cfq] bfq 

Кхм, а чем тогда объяснить падение производительности ещё на 20-40 MB/sec и её общую неравномерность?

Deleted
()
Ответ на: комментарий от Deleted

А я почём знаю? Кстати, у меня в 32-ом для dm-* шедулер указан, и после смены оного для sd* не меняется. Попробуй записать туда то же, что и для sd*., мало ли что.

GotF ★★★★★
()
Ответ на: комментарий от Deleted

>> Но зачем? Всё же и так работает.

чем тогда объяснить падение производительности ещё на 20-40 MB/sec и её общую неравномерность?


Видимо, я чего-то не понял :) Ладно, проехали.

GotF ★★★★★
()
Ответ на: комментарий от GotF

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

Deleted
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.