...and high iowait times (тормоза при копировании на медленное устройство)

ходит мнение, что если сделать

vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152

Что конфликтуют, знаю.

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

Попробуй

https://wiki.archlinux.org/index.php/Maximizing_performance#USB_storage_devices

Не, не то. (Сразу понятно, что не то, но проверил — не помогло.)

http://lwn.net/Articles/467328/

Вроде касается всех slow drives. Но не NFS...

Вроде не то. Проблема в том, что дисковый кэш забивается грязными страницами, которые создаются быстрее, чем система их флашит.

Выше предложили хак на эту тему, но блин — раньше же работало(tm)!

а еще заметил что если ноут тормозит от 12309 можно отключить его от зарядки и на какое то время ему станет лучше.

раньше же работало(tm)!

Ну да, патч pf и BFQ - просто удивительно, что что-то сломалось.

с pf-kernel у меня постоянно были рандомно возникающие проблемы с IO, теперь только генту патчсет.

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 419430

помогает избавиться от тормозов с медленными устройствами.

Безусловно. Нет, я могу и руками понакладывать uksm/BFS/BFQ... :)

генту патчсет

Это который? Что в него входит?

vm.dirty{,_background}_bytes

Предлагали выше, но это костыль, выносящий нафиг всё кэширование записи.

Это как? От срабатывания pm-powersave что ли?

с pf-kernel у меня постоянно были рандомно возникающие проблемы с IO

+1. У меня тоже, поэтому и не прижилось.

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

Уменьшает влияние бага, но не устраняет его. Всё равно первые полгига «копируются» путём чтения в дисковый кэш, и подвисает уже только файловый менеджер.

Оу. Окей. Сейчас пересоберу (reiser4 всё равно накладывать нужно)...

Это не костыль. Количество грязных страниц всё равно нужно ограничивать, но не до смешных 2 МиБ, а до более разумного объёма. Сколько на машинке памяти? Для своих 16 ГиБ я убрал проблему, выставив ограничение в 200 МиБ.

4 GiB, x86_64.

Дефолт для этих двух параметров --

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

хз, копировал что то на флэшку и скорость была 23 кб/с и оставалось ждать еще где то 3 часа. Отключил кабель питания как скорость выросла до 8 мб/с и лаги отошли.

Блиц-вопрос: для SSD elevator=cfq или elevator=noop?

http://dev.gentoo.org/~mpagano/genpatches/releases-3.9.htm

noop, но это не должно ни на что влиять.

Там в последнем комменте костыль:

My workaround is «watch -n 5 sync» when I copy files. Makes the problem go away completely.

Пересобрал без -pf. Одно и то же.

Выставил оба контрола в 200 MiB, заодно пересобрав ядро без патчей (только reiser4). Не помогло; копирование файла размером в полгига на NFS-шару подвесило систему _целиком_ (сработал только Alt+SysRq+B).

Может дело в сетевушке/ейных драйверах?

копирование файла размером в полгига на NFS-шару подвесило систему _целиком_

полгига

По-моему, ты не там ищешь. К грязным страницам это не имеет никакого отношения.

См. исходный пост. Первые теперь-уже-200 мегабайт «копируются» со скоростью чтения из исходного файла. Очевидно, что копируются они в дисковый кэш, заполняя его, и это приводит к тому, что все процессы по очереди падают в D (как только хотят записать что-то сами).

См. исходный пост

В исходном посте речь шла о «первом гигабайте», а сейчас у тебя всего пол-гигабайта.

Очевидно, что копируются они в дисковый кэш, и это приводит к тому, что все процессы по очереди падают в D.

То есть пол-гигабайта кэша, принадлежащего медленному устройству, волшебным образом замедляют процессы, которые к этому устройству не обращаются? Окай.

По совету post-factum'а я поставил ограничение на объём грязных страниц в 200 MiB.

То есть пол-гигабайта кэша, принадлежащего медленному устройству, волшебным образом замедляют процессы, которые к этому устройству не обращаются? Окай.

Он для каждого блочного устройства свой? Или для каждого mount'а свой?

page cache общесистемный, но, естественно, у страниц есть указатели на файлы (иноды), которым они принадлежат. И нить сброса страниц у каждого устройства своя.

Похоже, это ядерный баг. http://lwn.net/Articles/572911/

Похоже, это ядерный баг. http://lwn.net/Articles/572911/

И похоже, что Линус несет какую-то фигню о его причинах.

Так уже пытались закрыть

https://lwn.net/Articles/475405/

There have been some significant changes made to the memory compaction code to avoid the lengthy stalls experienced by some users when writing data to slow devices (USB keys, for example).

Баг в том, что ratio неправильно считаются на x86-64 машинах. А проблема (которая тоже там упоминается, но она не баг) в том, что стратегия «writeback», т. е. кэшируем пока возможно, не всегда хорошо работает.

Большие страницы и compaction тут вообще ни при чём.

Баг в том, что ratio неправильно считаются на x86-64 машинах

Баг в том, что тормоза одного внешнего устройства вешают даже процессы, которые его не используют. И это серьезный баг (в ДНК, да), а неправильный подсчет ratio - это отмазка, которые Линус отлично умеет придумывать.

Точно знаешь, от чего именно у тебя тормоза, и упомянутое — не твой случай?

Я делал echo never > /sys/kernel/mm/transparent_hugepage/enabled. Проблема не исчезала.

...and high iowait times

Penis and high iowait times.

На всякий случай спрошу: 3.14 пробовал?

Флешки надо чтобы монтировались с флагом flush, тогда будет сразу на носитель писать, а не в оперативу

Неа. reiser4.

sync. По одному блоку, со скоростью полтора байта в час.

Нет, именно flush. Тоже с этим мучался, пока не вписал в автомаунтер

А, окей. Но это vfat-специфично, а у меня проблема с любыми блочными устройствами (даже если напрямую в /dev/sdX писать)...

В общем, пока что решил костылём с sysctl vm.dirty{,_background}_bytes=$((200*1048576)). Ждём, когда ядро разупорется.

Короче, я тут потестил немного. Рецепт править vm.dirty{,_background}_bytes правильный, вопрос только в том, какое значение ставить. Эмпирически я нашел, что наименьшие лаги возникают тогда, когда это значение близко или чуть меньше линейной скорости записи на диск. У меня с механикой это больше 64 Mb/s но меньше 128 Mb/s (лаптоп). Выяснилось, что при vm.dirty{,_background}_bytes=$((128*1048576)) лаги отвратительно долгие, а при vm.dirty{,_background}_bytes=$((64*1048576)) терпимые. Дополнительно, возможно, играет роль то, что 64 Mb — это типичный размер кэша жестких дисков на запись.

Так что я поставил последнее значение и наслаждаюсь весьма отзывчивой системой в то время как bonnie++ насилует мой диск. Посмотрим, какие будут результаты по производительности.

Производительность просела, но очень умеренно. Зато латентности выровнялись — сильно уменишилась *максимальная* латентность (на запись — с 6с(!) до чуть больше одной), немного увеличились минимальные. Короче, я доволен :)

Интересные результаты. Спасибо.

// Внимание, вопрос: есть SSD (150 MiB/s), флешки (10 MiB/s) и NFS-шара в соседнем городе (<1 MiB/s). И чо мне делать при таком разбросе? :)

Думаю, оптимизировать по системный носитель.