[ловите] Низкая отзывчивость системы при активном использовании I/O.

Да, у меня такое наблюдается, но скорее из-за плохого железа

Нет, это наблюдается почти у всех. Дело в ядре. Ещё пол года назад нашли баг, до сих пор правят...

Ах они, редиски!

Как бы теперь проверить действие строчек... поставлю хешироваться несколько файлов.

А падение производительности должно проявляться только на каких то определенных ядрах?
Произвел тест с dd описанный по ссылке, все хорошо система отзывчива.

---
athlon 64 3000+
ubuntu 9.04 amd64
фс - xfs

dd if=/dev/zero of=/bigfile
^C7976485+0 записей считано
7976485+0 записей написано
скопировано 4083960320 байт (4,1 GB), 87,099 c, 46,9 MB/c

http://lkml.org/lkml/2009/9/19/288

Тоже за этим обсуждением наблюдаю.

CFS уже (вроде бы?) пофиксили. Вот ещё дисковую подсистему пофиксят и линукс на десктопе станет реальностью =).

Многогиговый фал скопируй. Или /dev/null куда-нить :)

Как загрузка проца? Попробуй два потока и параллельно включит видео.

Тормозить должно на ядрах выше .16 и (сильнее) .21

При одновременном хешировании 4 файлов система легла, как обычно.

Или эти волшебные строчки работают только с BFQ?

Когда-то я просидел почти два года на .15. Сидел, видел два глюка, но был счастлив)

А теперь "Баги исправляются с той же скоростью, что и вносятся. Кода больше, но процент багов столь же низок." Только я постоянно наблюдаю за всё более и более странным поведением системы.

//Проще прощения, нужно спать.

Только с CFQ :)

Произвел тест с dd описанный по ссылке, все хорошо система отзывчива.

В одном из ответов был выложен тестовый скрипт, попробуй его.

Получилось 2 примерно двух гиговых файла.
Видео проигрывалось гладко, только плеер (Totem) воспроизводить его начал не сразу, а где то через 30 секунд.
Загрузка проца максимально была 25%, dd занимали примерно по 7-10%.

Конфигурацию железа в студию! )

Надо попробовать

amd athlon 64 3000+ am2
4 gb ram
mb: epox mf4-j3
2 винта: sata wd 250gb 7200rpm (bigfile), pata seagate 120gb 7200 rpm (film)

uname -a
Linux linux 2.6.28-13-generic #45-Ubuntu SMP Tue Jun 30 22:12:12 UTC 2009 x86_64 GNU/Linux

Что-то я не понял. А с BFQ тоже самое что ли?

спасибо, кажется получше стало
11 штук tar -c / > /dev/null &
вполне переносимо для системы, хотя на запись пока не пробовала


nvidia mcp73 , с дисковым io очень не дружит..

Запустил хеширование 4х больших файлов.
Cpu(s): 23.2%us, 13.6%sy, 0.0%ni, 0.0%id, 61.9%wa, 0.3%hi, 1.0%si, 0.0%st
Mem: 3989684k total, 3964556k used, 25128k free, 1602792k buffers
Swap: 2049636k total, 1448k used, 2048188k free, 1706032k cached

Все гладко и отзывчиво.

Ага

и у меня тоже

и дело не в железе... io и так у линуха было не лучшее, но щас хуже чем в винде

Попробуй ещё CFS подкрутить.

<offtop>
Вот чем меня не устраивает система, так это тормознутостью 3d графики и компиза с его неторопливым изменением размера окошек.
nv gf 6600 128mb
дрова 180.44
</offtop>

все куртить, крутить

почему из коробки в дистрибутивах не работает?

>Нет, это наблюдается почти у всех. Дело в ядре. Ещё пол года назад нашли баг, до сих пор правят...

Этому багу примерно года четыре... Только недавно соизволили серъезное внимание обратить, все началось с 2.6.18

слил большой файл в /dev/null. Параллельно спокойно открыл кино, развернул на полный экран. Все плавно, тормозов не ощущаю. Ведро 30е. А проблемы видимо с 31м ведром, не зря мейнтейнеры его даже в анстейбл не спускают за глючность.

Юзаем 2.4.x!

> Этому багу примерно года четыре... Только недавно соизволили серъезное внимание обратить, все началось с 2.6.18

Меня особо забавляют отмазки разработчиков: «а у меня на машинке о 16 ядрах, 32 Гб ОЗУ и 32-дисковом SAS RAID'е ничего такого не это самое вот...». Утрирую, конечно, но тренд иногда имеет место быть.

CFQ, noop+NCQ, все это на ядре из репозитария. Arch linux. Всё люто тормозит, "the following two things" ситуацию не поменяли. Мерял с помощью testo.sh.

Хм, было такое на генте, на арче система весьма отзывчива. Правда может жутко повиснуть если уйдёт в своп.

wyldrodney> Дело в ядре.

Не в ядре, а в ДНК Инго Молнара.

Запустил 7 процессов: 2 sha1sum файла с 1.4 Гб, 2 md5sum, 2 cat и 1 tac больших файлов (фильмов). Да, проги открываться стали медленнее, но запущенные программы не тормозят. Этот пост набран прямо из под загруженной машины.

Нет, мне нифига не помогло

Хотя нет, вроде стало чуть лучше. Но всё же эффект есть

Как его затормозило, когда я писал "эффект есть".

Копировал фильмы и запустил dd if=/dev/zero of=test

На 9.04 ужасно просто, при проверке хэшей файлов (торренты), все ужасно тормозит.

А там дело не в мощности системы, а в кривости планировщика.

почему из коробки в дистрибутивах не работает?

В 2.6.32 изменили искоробочные настройки CFS.

Можно поподробнее? Что они там сделали?

http://www.linux.org.ru/view-message.jsp?msgid=4042173

Ага. Спасибо.

Спасибо за хинт. Стало намного лучше. Archlinux 2.6.31

А может ещё и вот это наложилось, у некоторых, типа меня, которые по старинке на IDE а не на libata

http://lkml.org/lkml/2009/9/24/305

> Disabling "ATA/ATAPI/MFM/RLL" restored my performance completely, > with the newer kernels

> теперь я переквалифицируюсь на технический флуд.
Модераторы оценили!

svu, выгони бумбика, а? Я вас даже любить начну.

Главное не дожидайся ночей а-ля "БВИМ".

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

и в качестве последнего самого сложного уровня

svu vs svu

THREE... TWO... ONE... FIGHT!


;)

Это будет прекрасно!