>Это по твоему io?
это проявления геморов с ним
и кстати что по-твоему i/o?

вероятно, iowait там резко увеличивается за счёт «HDD wait» )

и вообще, /dev/null вроде безболезненно кормится ноликами. странно всё это.

>речь о I/O!!!!

при чём здесь винт?

/0

есть ввод-вывод
есть кучка хлама передаваемого по нему
и не суть важно откуда и куда что посылается!!!
а в случае с винтом

iowait там резко увеличивается за счёт «HDD wait» )

о_О
что сказать-то хотел?

> /0

суть в том, что почему именно винт?

> и не суть важно откуда и куда что посылается!!!

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

>суть в том, что почему именно винт?

Хорошо, тогда перефразирую свой вопрос - как повторить ту же ситуацию, не записывая ничего на hdd?

придумай как ограничить скорость с которой принимает /dev/null...

>о_О

что сказать-то хотел?

Запись на hdd - это сферический io в вакууме.

> как повторить ту же ситуацию, не записывая ничего на hdd?

придумай как ограничить скорость с которой принимает /dev/null...

При проведении чудо-теста загрузка возросла до предела и интерфейс стал тормозить.

>придумай как ограничить скорость с которой принимает /dev/null...

Лезть в ядро? Навыков нет..

>'dd if=/dev/zero of=./111 bs=1G'

все норм, только после записи 6Gb на меня стали материться, что места нет

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

dd if=/dev/zero of=./111 bs=1G count n (n - количество bs)

*count=n

Значит у меня баг есть и можно бежать собирать 2.6.24? (У меня 2.6.31)

Только вот запустится ли оно на моём нетбуке?

А кто мне прояснит такую ситуацию

bash-4.0$ time dd if=/dev/zero of=~/111 bs=500M
dd: запись `/home/ramon/111': На устройстве кончилось место
2+0 записей считано
1+0 записей написано
 скопировано 992407552 байта (992 MB), 55,7667 c, 17,8 MB/c
Command exited with non-zero status 1
0.00user 6.58system 0:55.94elapsed 11%CPU (0avgtext+0avgdata 0maxresident)k
33256inputs+1938296outputs (431major+149525minor)pagefaults 0swaps
bash-4.0$ time dd if=/dev/zero of=~/111 bs=100M
dd: запись `/home/ramon/111': На устройстве кончилось место
10+0 записей считано
9+0 записей написано
 скопировано 993800192 байта (994 MB), 24,071 c, 41,3 MB/c
Command exited with non-zero status 1
0.00user 5.82system 0:24.08elapsed 24%CPU (0avgtext+0avgdata 0maxresident)k
400inputs+1941016outputs (2major+25887minor)pagefaults 0swaps
bash-4.0$ time dd if=/dev/zero of=~/111 bs=1G
dd: запись `/home/ramon/111': На устройстве кончилось место
1+0 записей считано
0+0 записей написано
 скопировано 993832960 байт (994 MB), 231,086 c, 4,3 MB/c
Command exited with non-zero status 1
0.00user 14.51system 3:51.45elapsed 6%CPU (0avgtext+0avgdata 0maxresident)k
1979712inputs+1941080outputs (31122major+473210minor)pagefaults 0swaps

>'dd if=/dev/zero of=./111 bs=1G

Ахах бук умер в страшных муках. До сих пор тормозит гуй. А на десктопе все нормально, при этом еще и торренты отдает в полную силу.

А вот нефиг писать на хард. Там фрагментация, заумная ФС и прочая муть.

> у винтов отклик большой, поэтому на них нерациональное планирование I/O лучше всего заметно.

Кстати, а никто не пробовал создать виртуальное устройство с искусственно большим откликом, чтобы проверить на нем? Чтобы выяснить в чем дело - в hdd или планировщике?

> придумай как ограничить скорость с которой принимает /dev/null...

for (i=0; i< 100000000; i++) ;

Это шутка? Мне не особо смешно. В повседневности не наблюдаю, это хоть радует. Но и не насилую свой хдд.

Если баг где-то в районе 2.6.18, то можно поставить Debian Etch и проверить. И на нем же можно попробовать заюзать 2.6.17 и между ними, если что.

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

А то, что время настолько различается - это конечно печально.

12309 - не баг, а фича.
Если ее пофиксят, я месяц буду пить только Арсенал Мицне.

> for (i=0; i< 100000000; i++) ;

придумай ещё, когда это включать...

и да, есть человеческий sleep если чо

>12309 - не баг, а фича.

Если ее пофиксят, я месяц буду пить только Арсенал Мицне.

+1. Забуду про Крушовице и волью Арсенал.

>for (i=0; i< 100000000; i++) ;

За такое в ядре - оторвут голову.

Винда там 95 поди=)

С другим планировщиком I/O типа BFQ, эта проблема у многих уходит, либо менее заметна. Вообще, в новом ядре сейчас активно пилят планировщик CFQ, и судя по откликам помогает.

гугль: CFQ IOPS iosched

буквально нововведения из июльских патчей:

---------- slice_idle ----------

This specifies how long CFQ should idle for next request on certain cfq queues (for sequential workloads) and service trees (for random workloads) before queue is expired and CFQ selects next queue to dispatch from. By default slice_idle is a non zero value. That means by default we idle on queues/service trees. This can be very helpful on highly seeky media like single spindle SATA/SAS disks where we can cut down on overall number of seeks and see improved throughput.

Setting slice_idle to 0 will remove all the idling on queues/service tree level and one should see an overall improved throughput on faster storage devices like multiple SATA/SAS disks in hardware RAID configuration. The down side is that isolation provided from WRITES also goes down and notion of ioprio becomes weaker.

So depending on storage and workload, it might be a useful to set slice_idle=0.

In general I think for SATA/SAS disks and software RAID of SATA/SAS disks keeping slice_idle enabled should be useful. For any configurations where there are multiple spindles behind single LUN (Host based hardware RAID controller or for storage arrays), setting slice_idle=0 might end up in better throughput and acceptable latencies.

CFQ IOPS Mode for group scheduling

==================================

Basic CFQ design is to provide prio based time slices. Higher prio process gets bigger time slice and lower prio process gets smaller time slice.

Measuring time becomes harder if storage is fast and supports NCQ and it would be better to dispatch multiple requests from multiple cfq queues in request queue at a time. In such scenario, it is not possible to measure time consumed by single queue accurately.

What is possible though to measure number of requests dispatched from a single queue and also allow dispatch from multiple cfq at the same time. This effectively becomes the fairness in terms of IOPS (IO operations per second).

If one sets slice_idle=0 and if storage supports NCQ, CFQ internally switches to IOPS mode and starts providing fairness in terms of number of requests dispatched. Note that this mode switching takes effect only for group scheduling. For non cgroup users nothing should change. ...

Почти полностью повисшая система при проверке хэшей торрентов. Куда серьезнее?

Этот баг только на запись влияет, когда планировщик флашит грязные страницы одного процесса и забивает на всё остальное. С хэшами у тебя что-то другое.

Решается просто - монтирование NFS через WiFi.
Скорость передачи невысока - всего 2,6 Мбайт/сек.
Однако пока пара тестовых гигов не пролетит через интерфейс, система стоит колом.

> Когда делаешь 'dd if=/dev/zero of=./111 bs=1G' и всё зависает, то это оно и есть?

убунту 10.10, ядро 2.6.35, данная команда + transmission в раздаче + rhytmbox + компиляция в NetBeans - никаких тормозов, dd есть 5% процессорного времени, а нет - при наборе этого сообщения на середине слова «процессорного» была небольшая пауза( две буквы сразу напечатались ), но только один раз, т.е. эффект бага есть, но не некритичный

Этот баг только на запись влияет, когда планировщик флашит грязные страницы одного процесса и забивает на всё остальное. С хэшами у тебя что-то другое.

Это io_wait на сколько я знаю, ибо на bfq это пропадало. Ну а при записи творится просто полный ад

Аааа, я тебя ненавижу :) Решил проверить на нетбуке - система быстра ушла в своп, и уже 2-ю минуту не отвечает Оо

> а нет - при наборе этого сообщения на середине слова «процессорного» была небольшая пауза( две буквы сразу напечатались )

о чем ты говоришь вообще?
12309 это когда при этом dd наступают такие тормоза, минуты на 2-5 минимум, что проще прибить все иксы по SAK, чем ждать пока оно отдуплится на ctrl+c либо закончит тормозить

еле убил.

> о чем ты говоришь вообще?

12309 это когда при этом dd наступают такие тормоза, минуты на 2-5 минимум

о том что у меня этих тормозов нет ( это должен бы сказать К.О. - но я решил его не дожидаться )

при запуске этой же команды на десктопе внезапно стал подвисать Firefox. Всё остальное работало так же отзывчиво.

> dd if=/dev/zero of=./111 bs=1G

Попробовал - ничего не зависло.

На ^C программа копирования среагировала не сразу, а секунд через 13.

Оперативной памяти 4Гб и своп отключен - может в этом дело.

Хотя сегодня по какой-то причине получил эпические тормоза во flash-plugin. В чем причина так и не понял. Система как будто умирать собралась - хрустела винтом (и это при отсутствии свопа), между окнами не переключалась. Прибил флэш - ожила снова, хотя прибить его было совсем непросто.

Безопаснее делать что0то вроде

dd if=/dev/zero of=./111 bs=1G&(sleep 10&&killall dd)

> dd if=/dev/zero of=./111 bs=1G
^C2+0 records in
1+0 records out
1073741824 bytes transferred in 35.979377 secs (29843258 bytes/sec)

Во время работы dd начал подтормаживать/заикаться Exaile. Все остальные программы (Firefox, GNOME System Monitor) продолжали нормально работать. Скроллирование страниц в Firefox происходило всё также плавно, как всегда. На «^C» dd остановился не сразу, а через 5-7 секунд после нажатия комбинации клавиш, сама надпись комбинации появилась без задержки.

Это нормально?

> 29843258 bytes/sec

это нормально?

нет конечно, у меня 58Мб/сек итоговая скорость

нет конечно, у меня 58Мб/сек итоговая скорость

У меня с каждым новым запуском разгоняется:

> dd if=/dev/zero of=./111 bs=1G
^C2+0 records in
1+0 records out
1073741824 bytes transferred in 35.979377 secs (29843258 bytes/sec)
> dd if=/dev/zero of=./111 bs=1G
^C5+0 records in
4+0 records out
4294967296 bytes transferred in 74.140453 secs (57930146 bytes/sec)
> dd if=/dev/zero of=./111 bs=1G
^C12+0 records in
11+0 records out
11811160064 bytes transferred in 185.374401 secs (63715162 bytes/sec)

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

>когда нету свопа, ядро, если вся память закончилась, вроде, может создавать динамический файл со свопом на диске, перекидывая туда куски оперативы, из за чего всё начинает жуутко тормозить.
чтооо о_О?

тест с dd if=/dev/zero of=file bs=1048576

при выполнении операции с sync никаких тормозов нет. Стоит перемонтировать без sync - сразу тормоза.