Так 12309 или нет?

гента как обычно тормознулась?

НЕТ ТЫ.
По теме - поймал раз 12309... Это не «дольше открывается». Тормоза как при адовом своппинге.

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

И интернет, интернет тоже ускорятся. Целиком.

Тормоза как при адовом своппинге

Тормоза не такие сильные как при своппинге, но есть что-то такое заметное

Хотя временами исчезает и появляется снова, и не могу понять как этот эффект снизить, никакие шаманства не помогают. Пишешь что-то на винт и замечаешь стала система медленно работать =\

Рекомендую попробовать BFQ шедулер i/o. Юзал его на эмбеддед - на тормозной spi flash тормоза при вызове скриптов или открытии файлов через веб-сервер отсутствовали (!), в то время как на cfq скрипт несколько десятых секунды стартовал, а страничка грузилась несколько секунд...

BFQ шедулер i/o.

плюсую, его кстати добавили в гентоо-патчсет.

CONFIG_IOSCHED_BFQ=y
CONFIG_CGROUP_BFQIO=y
CONFIG_DEFAULT_BFQ=y
CONFIG_DEFAULT_IOSCHED="bfq"

Ловлю постоянно в виртуалбоксе во время старта вирутальной машины. Причем только там и только на gentoo. LA поднимается до 14 и выше при практически не нагруженном процессоре в htop.

Нужно будет попробовать.

Не помогло. Ситуация такая:

1. echo <любой шедулер> > /sys/block/sda/queue/scheduler

2. dd if=/dev/zero of=12309_is_here bs=1M count=16384

3. Открываем файлменеджер и видим что он пуст, т.е. содержимое не отрисовалось.

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

Все это происходит при записи на тот же самый винт, на котором расположены и корень и хомяк.

Мне помог вот этот совет

Рекомендую попробовать BFQ шедулер i/o.

Зачем, если есть deadline?

throughput

throughput

Разница между оттвиканными deadline, bfq и cfq в пределах погрешности (емнип, btrfs любит cfq/bfq, но профит там на 128+ потоках). Но latency у первого ниже.

То есть только с 3.11 ?

Ну я как-то с этим багом раньше 3.10 особо не сталкивался (только при скидывании больших файлов на флешку, очень редко). Посему, да. У меня решилось только с 3.11rc

Это банально проблема в железе или криво собрал ядро или гента как обычно тормознулась?

В конфиге я всегда включаю CONFIG_IO_DELAY_NONE и выключаю по возможности все DEBUG-и.

Когда использую dd или копирую что-то, файловый менеджер дольше открывает каталоги, (без разницы на каком винте) это происходит дольше. Будто запись прет на всю катушку, выше чем позволяет дисковый контроллер.

В данном случае «дольше открывает» не проблема именно так и должно быть а вот если все вообще стоит раком то это именно 12309. Не путай одно с другим.

В конфиге я всегда включаю CONFIG_IO_DELAY_NONE

Ман DMA

Ман DMA

Если что я 12309 во всей его силе и не наблюдал никогда. А если терзать хард dd и параллельно еще фиг знает чем так тормоза неизбежны вопрос только в степени тормозистости этих тормозов.

Раком стоит только при сильном своппинге.

Раком стоит только при сильном своппинге.

Мне на десктопе своп вообще нужен только для хибернэйта. И да озу 3Гб если чо.

«Не верю» (с) Станиславский

Ловлю постоянно в виртуалбоксе во время старта вирутальной машины.

Своп случайно не отключен?

Своп включен, 2 GB. Памяти 8GB.

Если создать своп гигов на 10, это может помочь?

Если создать своп гигов на 10, это может помочь?

Нет, увеличивать не надо. Просто похожее ловлю периодически, но самый кошмар был вообще без свопа. Часто приходилось просто всё перегружать.

А с дисковой активностью что в это время? По HDD LED'y и какому-нибудь монитору на рабочем столе/панели задач, показывающему CPU iowait. Может еще по звуку HDD :)

В iotop: у kswapd0, VirtualBox загрузка под 99% IO

На слух определить не получается - есть второй более шумный винт, и на его фоне первый вообще не слышен :)

Меня, наверное, больше всего терзает вопрос - зачем своп начинает использоваться при 2+ GB свободной памяти.

Есть резон использовать его при отсутствии 12309?

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

надо будет еще с deadline поэкспериментировать.

Единственное решение отрубать своп во время работы (кроме гибернейта), и не нагружать дисковую подсистему несколькими потоками. Ну и оперативки побольше.

+ не использовать ntfs-3g по крайней мере для активной записи.

В iotop: у kswapd0, VirtualBox загрузка под 99% IO

Вот. У меня был просто ад некоторое время — какой-то кумулятивный эффект от аптайма, который при некоторых операциях (больше всего при запуске virtualbox) начинал насиловать hdd так, что в себя система часто уже не приходила. Появилось на ядрах 3.8.(2+?) и тянулось возможно до 3.9.

Но. При всем этом своп был отключен. Свободная память вроде еще была, но в основном как buffers/cache (~3.7GB total). Когда включил своп — резко полегчало. Причина вроде понятна, за исключением одного — почему перед началом проблем не выедалась вся свободная (буферы и кэш в ноль).

Меня, наверное, больше всего терзает вопрос - зачем своп начинает использоваться при 2+ GB свободной памяти.

У меня, получается, похожая ситуация. Что-то еще есть, но нужен своп, иначе адски тормозим.

swappiness крутить пробовал, бестолку. С vm_overcommit=2 современные Qt уже счастливо не работают (сегфолты), баг есть.