Провалы в скорости по NFS

Автор kanyck, 11 июля 2011, 12:15:55

« назад - далее »

0 Пользователи и 2 гостей просматривают эту тему.

kanyck

Господа линуксисты, помогите советом. Странности какие-то у меня с NFS.
Дома стоит сервер на debian squeeze, ядро .38 из бекпорта - роутер + файлопомойка - отдаёт кино по NFS на дюну. При просмотре высокобитрейтных фильмов в произвольных местах подёргивается и пропадает звук примерно раз в 5-10 минут (кино не при чём - при повторе будут провалы в другом месте) Дюновская инфо при этом показывает сначала провал битрейта примерно на полсекунды-секунду, затем скачок до 60-80, потом всё опять штатно. Взгромоздил ntop, он показал то же самое - провал, затем пик. Средняя производительность при этом вполне соответствует ожиданиям - по 100Мбит сети стабильно выкачивает 12МБ/с - и в пару раз перекрывает необходимую для кино пропускную способность. Стал разбираться.
Проверил скорость чтения с диска. dd на /dev/null - большие файлы со свистом. 30МБ/с и выше (в среднем за файл, мерял командой time, моментальную скорость не знаю, как померять). То есть система раз в в Х минут как бы подзависает на секунду со вводом-выводом, а потом нагоняет. При этом в сети пакеты не теряются, ошибок никто никаких не рапортует. Стоит transmission 2.03, раздаёт торренты, на скорости в среднем 1МБ/с - не соизмеримо со 100МБ сетью. Пакеты (TX) иногда теряет pptp, но это вряд ли может влиять на раздачу NFS по локальной сети. top показывает никакую загрузку процессора, но были замечены пики в ожидании в/в - до 88%wa периодически показывает. Такое ощущение, что неправильно что-то настроено, или в дисковой подсистеме где-то логический баг. Возможно, какой-нибудь generic драйвер халтурит или нескладуха какая с DMA или прерывание теряется? Никто не сталкивался с таким?? Странно как-то - не с чего ему подвисать. Бэдблоков на диске нет, плановый fsck по количеству монтирований только что был.
При этом система практически работает примерно на одной шестой оперативной памяти:
970.34 MB total, 175.70 MB used, а до свопинга дело вообще ни разу не доходило. Можно будет потом смело отключить, когда руки дойдут. Может, можно принудительно ей буфера увеличить - вдруг поможет? Подскажите, в чём может быть дело. Где копать, уже не понимаю...

Udachnik

https://bugzilla.kernel.org/show_bug.cgi?id=12309
И с юмором
http://lurkmore.ru/12309

Вылечить теоретически можно сменой ядра (попробуй стандартное 32-е) или попробовать собрать ядро самостоятельно. Но положительный результат не гарантируется.

kanyck

#2
О! Я что-то в этом роде и предполагал (и надеялся, что ошибаюсь)... Мдя...  ???
.32 тоже не вариант - там баг с ACPI - система зависает при останове, и не ловит половину событий от мамы...
я не от любви к экспериментам бэкпортовское ядро водрузил.
Ладно, вылечить больного пока нельзя, может как-нибудь можно облегчить его страдания, скажем, раздуванием буферов или настройкой приоритетов? Памяти свободной дофига, всё равно зря пропадает...
Подскажите, что можно попробовать (и как. А то я в ядре последний раз ковырялся лет 20 назад - подзабыл слегка, да  и ядра поменялись с тех пор)
Не хочется на фрю уходить. Только всё настроил...

kanyck

Вывод ntop выглядит очень интригующе