При интенсивной работе HDD все тормозит (Вопрос о повышении отзывчивости Linux при записи/чтении больших файлов)

[*Sasha*]

Вышло 2.6.30, кто уже юзает, улучшения есть?

Это где вы такое увидели?

http://www.opennet.ru/opennews/art.shtml?num=22084

[Perlover]

Про iowait проблему - кажись дело сдвинулось с мертвой точки
см. bug http://bugzilla.kernel.org/show_bug.cgi?id=12309#c360 , пост 360
Там человек пишет, что сделал revert двух патчей 2007-го года (когда проблема впервые появилась), и после люди пишут, что производительность повысилась драматично ...
Плиз кто-нибудь попробуйте сделать это и отпишите сюда ;-)

2.6.30-rc8-git6 патч http://bugzilla.kernel.org/show_bug.cgi?id=12309#c366 - для меня никаких улучшений

А если попробовать сделать реверс патчей, про которые было написано в посте 360?
Я так понял, Томас приложил те патчи, и некоторые люди его после благодарили очень. То есть видимо у них были изменения
А пост 366 - там судя по текстам патча, во второй части другие изменения. То есть патч для реверса из поста 366 другой, нежели в 366

[Perlover]

Я взял патчи из #360 поста там, применил к сорцам 2.6.29, а *.rej руками поправил.
Теперь он здесь (376 пост)
http://bugzilla.kernel.org/show_bug.cgi?id=12309#c376
Сам не пробовал, но у меня скомпилировалось ядро (я просто пока не научился ядря устанавливать - нет у меня тачки, где можно такие эксперименты ставить, только рабочий сервак).
Кто пробовал патч из #366 - я просмотрел исходники, пришел к выводу, что там только половина патча совпадает, остальное чуть чуть добавил автор поста. Причем там нет важного кода с prev_cfqq переменной. Вообщем, кто поставил патч из #366, сделайте реверс и попробуйте этот.

[Hassium]

Я взял патчи из #360 поста там, применил к сорцам 2.6.29, а *.rej руками поправил.
Теперь он здесь (376 пост)
http://bugzilla.kernel.org/show_bug.cgi?id=12309#c376
Сам не пробовал, но у меня скомпилировалось ядро (я просто пока не научился ядря устанавливать - нет у меня тачки, где можно такие эксперименты ставить, только рабочий сервак).
Кто пробовал патч из #366 - я просмотрел исходники, пришел к выводу, что там только половина патча совпадает, остальное чуть чуть добавил автор поста. Причем там нет важного кода с prev_cfqq переменной. Вообщем, кто поставил патч из #366, сделайте реверс и попробуйте этот.

Патч из #366 актуален для ядра 2.6.30.

Вот функция из ядра 2.6.29.4 с твоим патчем

Код:

static int cfq_dispatch_requests(struct request_queue *q, int force) { struct cfq_data *cfqd = q->elevator->elevator_data; struct cfq_queue *cfqq, *prev_cfqq; int dispatched; if (!cfqd->busy_queues) return 0; if (unlikely(force)) return cfq_forced_dispatch(cfqd); dispatched = 0; prev_cfqq = NULL; while ((cfqq = cfq_select_queue(cfqd)) != NULL) { int max_dispatch; /* * Don't repeat dispatch from the previous queue. */ if (prev_cfqq == cfqq) break; /* * So we have dispatched before in this round, if the * next queue has idling enabled (must be sync), don't * allow it service until the previous have continued. */ if (cfqd->rq_in_driver && cfq_cfqq_idle_window(cfqq)) break; cfq_clear_cfqq_must_dispatch(cfqq); cfq_clear_cfqq_wait_request(cfqq); del_timer(&cfqd->idle_slice_timer); max_dispatch = cfqd->cfq_quantum; if (cfq_class_idle(cfqq)) max_dispatch = 1; dispatched += __cfq_dispatch_requests(cfqd, cfqq, max_dispatch); prev_cfqq = cfqq; } cfq_log(cfqd, "dispatched=%d", dispatched); return dispatched; }

Вот эта же функция из ядра 2.6.30 с патчем из #366

Код:

static int cfq_dispatch_requests(struct request_queue *q, int force) { struct cfq_data *cfqd = q->elevator->elevator_data; struct cfq_queue *cfqq; unsigned int max_dispatch; if (!cfqd->busy_queues) return 0; if (unlikely(force)) return cfq_forced_dispatch(cfqd); cfqq = cfq_select_queue(cfqd); if (!cfqq) return 0; if (cfqd->rq_in_driver && cfq_cfqq_idle_window(cfqq)) return 0; /* * If this is an async queue and we have sync IO in flight, let it wait */ if (cfqd->sync_flight && !cfq_cfqq_sync(cfqq)) return 0; max_dispatch = cfqd->cfq_quantum; if (cfq_class_idle(cfqq)) max_dispatch = 1; /* * Does this cfqq already have too much IO in flight? */ if (cfqq->dispatched >= max_dispatch) { /* * idle queue must always only have a single IO in flight */ if (cfq_class_idle(cfqq)) return 0; /* * We have other queues, don't allow more IO from this one */ if (cfqd->busy_queues > 1) return 0; /* * we are the only queue, allow up to 4 times of 'quantum' */ if (cfqq->dispatched >= 4 * max_dispatch) return 0; } /* * Dispatch a request from this cfqq */ cfq_dispatch_request(cfqd, cfqq); cfqq->slice_dispatch++; cfq_clear_cfqq_must_dispatch(cfqq); /* * expire an async queue immediately if it has used up its slice. idle * queue always expire after 1 dispatch round. */ if ((!cfq_cfqq_sync(cfqq) && cfqq->slice_dispatch >= cfq_prio_to_maxrq(cfqd, cfqq)) || cfq_class_idle(cfqq)) { cfqq->slice_end = jiffies + 1; cfq_slice_expired(cfqd, 0); } cfq_log(cfqd, "dispatched a request"); return 1; }

Тут просто уже нет цикла while ((cfqq = cfq_select_queue(cfqd)) != NULL) из которого был бы выход по условию if (prev_cfqq == cfqq) break;

[Perlover]

Спасибо, мне уже там же ответили также
Теперь я понял. Но блин, что делать с этой проблемой 'iowait' я уже не знаю
У меня серваки под FC6, там RAID10 из SCSI, но как только сервак активно юзает диск (либо много запросов, либо rsync запуск для резерва) - все, копец: несколько раз в час наступают моменты, когда сервак замораживается на 10-60 секунд, в эти моменты трудно что либо запустить, а 'wa' в 'vmstat 1' всегда выше 90%
Причем проверить это легко с помощью 'dd' и созданием какого нибудь файла большого.
Это я все снова написал, чтобы те, кто впервые здесь, поняли, о чем я
Проблема на самом деле очень стремная - с 2007-го года такое, серваки под нагрузкой начинают замораживаться временами при работе с HDD ...
А я ведь, блин, в свое время с FreeBSD переехал на Linux, так как она себя лучше показывала по производительности. Но это когда было ядро < 2.6

[rm_]

Я всю ветку и все багрепорты сейчас не проглядывал, но если патчи правят CFQ scheduler, возможно, временным и альтернативным решением проблемы будет переход на использование другого? Попробуйте выставить deadline, anticipatory, либо noop (в таком порядке).

[Perlover]

Ура! У меня кажись (тестирую 10-12 часов и пока полет нормальный) получилось побороть подвисания на секунды и минуты для жестко-нагруженного сервака с дисковой работой.
Решение я привел здесь

http://bugzilla.kernel.org/show_bug.cgi?id=12309#c385

Это "синтез" команд, которые я собрал по форумам, где народ пробовал что либо предлагать для решения и тестов.
'dd' я не пробовал. И не хочу, так как боюсь нарушать порядок работы рабочего сервака ;-)
Предлагаю всем, кто работает с жестко-нагруженными серваками поставить эти опции - там мы меняем шедулер, работу с кешированием inodes и очередью на сортировку шедулера. Вроде так, если я все опции правильно понял. Главное, что это у меня заработало.
Но это временное решение :-( Хотя работает ;-) Баг стопудов в ядре есть до сих пор.
Буду признателен за отзывы тех, кого достал этот баг. Мне очень интересно, сработает ли это у вас.

Маленькое уточнение! Я не думаю, что это тоже повлияло, но все же напишу здесь
Я вырубил у себя в сервисах irqbalance, отключил модуль cdrom (он собирал постоянно прерывания, хотя сидюк не работал - cat /proc/interrupts -> видно было прерывания -> modprobe -rv ide_cd), затем выставил маски для всех процессоров на прерывания (for a in /proc/irq/*; do echo -n "ffffffff" > $a/smp_affinity; done) - тогда у меня eth0 и scsi винты обрабатывались не один-двумя ядрами, как с irqbalance, а всеми ядрами. Но после этих правок я сутки тестировал - и проблема оставалась. Если решение, описанное в bugzilla не поможет, попробуйте еще сделать эти команды. Может быть повлияло и то и то, так как часто на форумах я читал, что смена шедулера и другие описанные там команды - не помогали. Но мы там не тока шедулер меняем в workaround ...

[altwazar]

Я это пробовал, когда первый раз столкнулся.
Вроде чуть лучше с такими настройками было, но видео смотреть при копировании все равно не получалось.
Сейчас с ext4 и kernel 2.6.29 уже не так чувствуется эта проблема.

[Yooo]

Ubuntu 9.04 (ядро 2.6.28-13-generic) - проблема имеется, при обычной работе почти никак себя не проявляет, но при хешировании шары в DC++ тормоза более чем чувствительны - звук в плеере иногда прерывается, мышка тормозит, ну и прочие "прелести"... проц при этом почти не нагружен, сам процесс хеширования довольно быстро проходит.

железо: m/b Gigabyte GA-M52S-S3P (nForce 430)/AMD 64 x2 6000+/RAM 2Gb/HDD Samsung HD103UJ (фс ext4)

[drBatty]

проц при этом почти не нагружен

это вам так кажется...

[Yooo]

проц при этом почти не нагружен

это вам так кажется...

да нет, не кажется... смотрю в Системном мониторе. Другое дело - можно ли ему верить =)

[altwazar]

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

[drBatty]

да нет, не кажется... смотрю в Системном мониторе. Другое дело - можно ли ему верить =)

нельзя

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

у меня всегда так
504мб

ЗЫЖ загрузку измеряю косвенно - по датчику температуры.
кстати, у меня это слышно, куллер начинает выть...

[altwazar]

у меня всегда так
504мб

ЗЫЖ загрузку измеряю косвенно - по датчику температуры.
кстати, у меня это слышно, куллер начинает выть...

У меня 4Гига, первую минуту все нормально.
И еще заметил одну вещь, тормоза проходят не сразу. Полностью они пропадают через несколько открытий|закрытий приложений или просмотра видео. Если ничего особо не трогать, то тормоза могут проявиться и минут через 10.
Уменьшал память до 1Гб, тормоза начинаются почти сразу.

[drBatty]

надоело мне это всё.

Shell

$ uname -r 2.6.27.7-smp

и всё нормально

[Full Null]

надоело мне это всё.

Shell

$ uname -r 2.6.27.7-smp

и всё нормально

И что вы хотите этим сказать? Что с этой версией ядра всё работает как надо?
Если да, то нужны ли какие-нибудь особые параметры конфига ядра?

[drBatty]

И что вы хотите этим сказать? Что с этой версией ядра всё работает как надо?

да

Если да, то нужны ли какие-нибудь особые параметры конфига ядра?

нет
памяти так и есть 504мб
при переносе файлов с раздела на раздел всё НОРМАЛЬНО РАБОТАЕТ.
процессор не греется, ничего не тормозит.
вот сейчас переношу с одного харда на другой 10 файлов по 300Мб...
нормально всё. CPU не греется, не тормозит.
Как справедливо выше подметили, все беды начались как только сменили /dev/hd* на /dev/sd*

$

drb@drbatty:/mnt/disk8/video$ time -p mv \ /mnt/hd/ftp/pub/video/serials/H2O.Prosto.dobav.vody.S01E1* ./ real 76.86 user 0.11 sys 4.90

раньше такая операция всё тормозила, и CPU нагревался.

[Hassium]

И что вы хотите этим сказать? Что с этой версией ядра всё работает как надо?

да

Если да, то нужны ли какие-нибудь особые параметры конфига ядра?

нет

Тормозит как и на всех остальных ядрах.

памяти так и есть 504мб
при переносе файлов с раздела на раздел всё НОРМАЛЬНО РАБОТАЕТ.
процессор не греется, ничего не тормозит.
вот сейчас переношу с одного харда на другой 10 файлов по 300Мб...
нормально всё. CPU не греется, не тормозит.
Как справедливо выше подметили, все беды начались как только сменили /dev/hd* на /dev/sd*

Мне облегчает жизнь отключение NCQ.

[drBatty]

Тормозит как и на всех остальных ядрах.

ну тогда я не знаю...
madriva тормозила, а slackware не тормозит.
железо такое же.

ЗЫЖ и загрузка такая-же...
странно...
вот сейчас копирую файл в 3г, в ту-же директорию - не ощутимо. только диск чуть трещит и лампочка почти постоянно светит.

[altwazar]

ну тогда я не знаю...
madriva тормозила, а slackware не тормозит.
железо такое же.

Скорее всего тут несколько проблем, с одинаковыми симптомами. А скорость копирования не упала? У меня эта проблема еще с 2.6.24 (а возможно и еще раньше).

[drBatty]

Скорее всего тут несколько проблем, с одинаковыми симптомами. А скорость копирования не упала? У меня эта проблема еще с 2.6.24 (а возможно и еще раньше).

скорее - увеличилась.
но это возможно связанно с меньшей фрагментацией (которая ИМХО - есть, просто не такая фатальная)

[n00kl]

Эта проблема для ati или nvidia чипсетов не актуальна?
Хочу заменить Сore 2 Duo + ICH9, на Phenon II + ATI или Nvidia чипсет, ибо надежны что поправят не осталось

[n1kt0]

у меня такая же вещь: p5n32-sli deluxe + core 6320 +2gb ram+29 ялро. При копировании больших обьемов информации система полностью в ауте. Пробовал все планировщики - реально ни один нормально не подходит. Думаю тут только поможет nice 19 и ionice. Как это только интегрировать в кде, чтобы постоянно в консоль не лезть ?

[alexdsp]

Как владелец "не интел" чипсета (у меня nvidia mcp51 + athlon64 x2 3800, Linux - Arch64 current) хочу заметить, что проблема всё равно есть. Не так выражена, может быть, но неприятно всё равно. Например, при хешировании шары в DC++ система, конечно же не "умирает" как некоторые пишут, но всё же ворочается оччень лениво...
Действительно, вспоминается Slackware где ничего подобного не было... но обратно на слаку я уже не хочу.

[n00kl]

Если в слаке проблем не было, а арче есть, то похоже это что-то другое. Эта проблема ярко выражена при простом копировании больших объемов информации (как только вся свободная память уходит под кеш)

[Jaguar77]

fedora 10 i686, Asus p5ql SE,ICH10, AHCI, 200 gb WD. 2gb оперативки одной планкой.

копирую файл 2 гига по фтп на другой комп.
Вначале скорость 8-10мб/сек, полностью нагружает 100Мб карту.(iowait до 5%)
далее спустя от 15 сек до 30 сек скорость уменьшается и
плавает от 1мб/сек до 3мб/сек(iowait 60-70%)

От рута делаю
echo 1 > /proc/sys/vm/drop_caches
как только кеш очишается(до 5 сек), скорость нормализуется и iowait стремится к нулю.

Вывод: проблемма в алгоритме выделения и очищения кеш памяти при работе с диском.

[Uzix]

Debian testing, ноут lenovo g410

Код: Выделить всё

% uname -a
Linux tellur 2.6.31-zen1 #2 ZEN SMP PREEMPT Fri Oct 9 17:37:16 MSD 2009 i686 GNU/Linux

Код: Выделить всё

% cat /sys/block/sda/queue/scheduler
noop fifo anticipatory deadline cfq vr [bfq]

Кажется, частично удалось смягчить проблему. Сегодня пересобрал ядро с bfs и bfq. Только что проверил - при хешировании в ДЦ теперь вполне возможно пользоваться системой, хотя, конечно, тормоза остались, но это несравнимо с тем, что было - отзывчивость намного лучше. IOwait при этом по-прежнему высокий.

[Jaguar77]

Я считаю что проблемма совсем не в планировщике процессов....
Проблемма в самом принципе кеширования....
Например, при обычной работе кешируются программы, библиотеки которые запускаются...файлы которые используют программы....
и это значительно ускоряет работу....но при копировании больших файлов, когда оперативная память заканчивается, менеджеру
кеша необходимо как то освободить память, и он 1)может скинуть старое в swap 2)вообще удалить из кеша раннее сохраненные файлы...В любом случае после окончания копирования, в кеше нет ранее сохраненных библиотек и программ, и система начинает
шуршать винтом и заного прогружать раннее кешированные файлы

[Jaguar77]

Читая http://bugzilla.kernel.org/show_bug.cgi?id=7372 возможно наткнулся на решение проблеммы....

Ok, wow...I just solved the problem here. Apparently write caching was
disabled. I'd never used sdparm before. Found a thread on Web Hosting Talk that
sounded like this issue and explained that fix.

sdparm -s WCE=1 /dev/sda

And everything's fine. If that helps others, I take no credit. If it doesn't,
I'm sorry for adding to the noise.

Прошу проверить и отписать о результатах.

[6hlodwig]

Читая http://bugzilla.kernel.org/show_bug.cgi?id=7372 возможно наткнулся на решение проблеммы....
Прошу проверить и отписать о результатах.

я не "про", вот что вижу

Код: Выделить всё

# sdparm -s WCE=1 /dev/sda
/dev/sda: ATA       WDC WD2500AAKS-0  01.0
change_mode_page: failed setting page: Caching (SBC)

год как пользуюсь gnu/linux, разные дистрибутивы смотрел. в основном использовал debian и arch. матплата gigabyte s-серии, intel core2 duo e4600, nvidia 8800 gts, 2 gb RAM DDR2, Western Digital HDD. на всех дистрибах вся "классика" - полный "мертвяк" системы при запущенной игре типа source и перемещении файла в несколько гигабайт. процессор и озу не заполнены, декодирование звука, запущенное ранее идет нормально.

очень расстроен...