LINUX.ORG.RU

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

 , ,


1

6

Существует такая проблема. Например, я копирую файл с локального диска (или делаю cat /dev/urandom) в расшаренную по NFS директорию, скорость обмена данными с которой — 1 MiB/s. Или на флешку, скорость записи на которую — 10 MiB/s.

Так вот, первый ~гигабайт данных записывается со скоростью, явно превышающей пропускную способность канала — около 100 MiB/s (у меня SSD). Дальше скорость падает до нуля, одно ядро оказывается 100% занято io-wait, все процессы поочерёдно падают в состояние D и системе приходит каюк примерно до момента окончания записи файла (если соединение не рвётся раньше).

Что делать, куда копать? Симптомы похожи на 12309, только хуже и это не оно.

  • 3.13.1-pf
  • BFQ
  • vm.dirty_ratio = 60
    vm.dirty_background_ratio = 10
    
★★★★★

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

vm.dirty_bytes = 2097152
vm.dirty_background_bytes = 2097152
лечатся такие затыки а, да, опции конфликты с процентными, так что те закомментить надо. Ну если решишь попробовать

ii343hbka ★★★ ()
Последнее исправление: ii343hbka (всего исправлений: 1)
Ответ на: комментарий от ii343hbka

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от greenman

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

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

intelfx ★★★★★ ()

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

snaf ★★★★★ ()

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

vm.dirty_background_bytes = 4194304
vm.dirty_bytes = 419430

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

wakuwaku ★★★★ ()
Ответ на: комментарий от tailgunner

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

intelfx ★★★★★ ()
Ответ на: комментарий от wakuwaku

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

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

vm.dirty{,_background}_bytes

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

intelfx ★★★★★ ()
Ответ на: комментарий от wakuwaku

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

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

sdio ★★★★★ ()
Ответ на: комментарий от wakuwaku
vm.dirty_background_ratio = 10
vm.dirty_ratio = 20

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

intelfx ★★★★★ ()
Ответ на: комментарий от sdio

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

post-factum ★★★★★ ()
Ответ на: комментарий от post-factum

4 GiB, x86_64.

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

vm.dirty_background_ratio = 10
vm.dirty_ratio = 20
Это нормальный дефолт или надо меньше?

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

snaf ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

greenman ★★★★★ ()
Ответ на: комментарий от post-factum

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

полгига

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Ответ на: комментарий от intelfx

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

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

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

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

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

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

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

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

tailgunner ★★★★★ ()
Последнее исправление: tailgunner (всего исправлений: 1)
Ответ на: комментарий от greenman

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

intelfx ★★★★★ ()

...and high iowait times

Penis and high iowait times.

anonymous ()

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

xorik ★★★★★ ()
Ответ на: комментарий от xorik

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

intelfx ★★★★★ ()

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

intelfx ★★★★★ ()
Ответ на: комментарий от intelfx

Короче, я тут потестил немного. Рецепт править 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++ насилует мой диск. Посмотрим, какие будут результаты по производительности.

unanimous ★★★★★ ()
Ответ на: комментарий от unanimous

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

unanimous ★★★★★ ()
Ответ на: комментарий от unanimous

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

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

intelfx ★★★★★ ()
Последнее исправление: intelfx (всего исправлений: 1)
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.