Система тормозит при копировании с nvme ssd на hdd

Поздравляю, ты нашёл 12309.

💯😆

Баг 12309 решен окончательно!

с разморозкой!
точно также происходит при копировании с HDD на USB.

добро пожаловать в дивный мир grep . /proc/sys/vm/dirty*

https://wiki.archlinux.org/title/Improving_performance

Но окончательно проблемы с производительностью не устранились.

как сказали выше известный линупсовый баг, поменяй планировщик i/o, и в правила 60-ssd-scheduler.rules допиши, если нет - создай, пример с работающего:

ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="0",ATTR{queue/scheduler}="noop"
ACTION=="add|change", KERNEL=="sd[a-z]", ATTR{queue/rotational}=="1",ATTR{queue/scheduler}="cfq"

Смена шедулера на hdd не помогла.

точно также происходит при копировании с HDD на USB.

Знаю не по наслышке.

Попробуй на https://xanmod.org/ ядре.

Предлагаю забить и покушать печенек, пока оно копируется.

«cfq»

Его из ядра выкинули давно. Дефолтный mq-deadline достаточно хорош.

Так она и не должна помогать. Решением является ограничение vm.dirty_bytes.

Добавь в sysctl.conf

vm.dirty_bytes=64000000

Прочие меры не помешают. Например swap на zram.

Добавь в sysctl.conf

vm.dirty_bytes=64000000

Пока вроде помогло. Спасибо!

Смена шедулера на hdd не помогла

а как ты проверял что у тебя выбран нужный? какие ставил?

Установи ядро 5.16, возможно что-то поменяется.

В системе (Debian 11) есть выбор между

[mq-deadline] none

Первый по умолчанию для HDD, другой для SSD.

Пока что помогло другое: Система тормозит при копировании с nvme ssd на hdd (комментарий)

покушать печенек, пока оно копируется

Или почитать FreeBSD Handbook :)

Его из ядра выкинули давно.

можно доустановить и грузить модулем

Дефолтный mq-deadline достаточно хорош.

не тестировал

Предлагаю забить и покушать печенек, пока оно копируется.

А если сытой, то пойти делать обратный процесс.

Вот она жизнь линуксоида.

🌰

Пока что помогло другое:

ок

Ничего не меняется, лол)

Помню, был у меня на одной из старых работ новый ПК (на то время): Intel Core i5-2400/8 Gb DDR3, система на SSD, в компе еще пару винтов. ОС - Debian stable с LXDE.

Втыкаю я SD карту в ридер и с винта скидываю 10+ Гб файлов разнобойных (Навител какой-то).

Все - DE стало колом, можно идти не просто пить чай с печеньками, а замешивать тесто на печеньки и собирать чайные листья с кустов. А когда этот уже готовый чай и печеньки будут сожраны, тогда как раз копирование закончится и DE проснется.

Ничего не меняется, лол)

А что должно меняться и зачем? Кому надо - донастраивают.

А что должно меняться и зачем?

Настройки по умолчанию. Чтобы таких глупых проблем не было.

Настройки по умолчанию. Чтобы таких глупых проблем не было.

Лорчую.

hakavlad собственно, мой ответ такой же.

Высокий vm.dirty_ratio может увеличивать производительность операций записи и снижать износ диска. Поэтому и не решают проблему.

Высокий vm.dirty_ratio может увеличивать производительность операций записи и снижать износ диска. Поэтому и не решают проблему.

Нет. Это самая обычная глупость, на которую никто не обращает внимание.

Вот интересное чтиво на эту тему: https://lwn.net/Articles/572933/

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

Угадал автора по заголовку.

<зануда>Изначально это был анекдот про Windows.</зануда>

это не глупость, это legacy
резервировать 20% под «грязь» вполне себе решение, если у тебя 256/512мб оперативки
резервировать 20% под «грязь» на 4Гб оперативки уже как-то некрасиво смотрится (у меня так, это 800М под кэш получается)
на современных компах обычно 8-32Гб озу - тут уже 20% выглядят глупо, как ты говоришь
решение тут простое - граммотно зарепортить это дело (похожий пример legacy, который был положительно разрешён - это net.core.somaxconn ещё год назад был 128 и тоже смотрелся глупо)

метапрог купил себе ssd? поздравляю.

слушай, вся эта эпопея с генерацией сишки. я тут посмотрел на Ch который Си интерпретатор. там прям на сайте история успеха с LabVIEW – компонента написана на Ch которая запускается из LabVIEW и рисует графики.

думается мне, эдак можно и саму сишку генерировать.

то есть: если бы ты взял для раскрутки тот же самый Ch который платный, ну или примерный его аналог бесплатный : язык Pike, Cint из ROOT, ещё была пара реализаций, будешь смеяться, на питоне (то есть: интерпретатор Си включая парсер написан на питоне).

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

да, вот ещё, во славу Одина: – язык Odin

компилируется через LLVM, есть SDL в пакетах, интеграция с сишкой.

ну чёго же ещё надо, а? возми себе нечто подобное да допиши же уже наконец свой проект – невозбранно, достигнув желаемого. во славу Одина.

см. выше

граммотно зарепортить это дело

На уровне ядра обсуждали сто раз. Позиция Линуса - ставьте себе сами 48МБ для грязи.

Limiting the amount of dirty memory to 100MB/200MB (for "start
background writing" and "wait synchronously" respectively) even if you
happen to have 16GB of memory sounds like a good idea. Sure, it might
make some benchmarks a bit slower, but it will at least avoid the
"wait forever" symptom. And if you really have a very studly IO
subsystem, the fact that it starts writing out earlier won't really be
a problem.

https://lwn.net/Articles/572933/

Если проблема не решается в ядре винильном, то могла бы решаться на уровне десктоп-ориентированных дистрибутивов. По-видимому, нужно репортить дистроделам, а не в ядро.

Если проблему не решают дистроделы, значит проблемы нет. В противном случае покажите мне ссылку на этот баг в багтрекере Федоры.

На уровне ядра обсуждали сто раз. Позиция Линуса - ставьте себе сами 48МБ для грязи.

Вот:

Yeah, I think we default to a 10% "dirty background memory" (and
allows up to 20% dirty), so on your 16GB machine, we allow up to 1.6GB
of dirty memory for writeout before we even start writing, and twice
that before we start *waiting* for it.

On 32-bit x86, we only count the memory in the low 1GB (really
actually up to about 890MB), so "10% dirty" really means just about
90MB of buffering (and a "hard limit" of ~180MB of dirty).

And that "up to 3.2GB of dirty memory" is just crazy. Our defaults
come from the old days of less memory (and perhaps servers that don't
much care), and the fact that x86-32 ends up having much lower limits
even if you end up having more memory.

You can easily tune it:

    echo $((16*1024*1024)) > /proc/sys/vm/dirty_background_bytes
    echo $((48*1024*1024)) > /proc/sys/vm/dirty_bytes

or similar. But you're right, we need to make the defaults much saner.

https://lore.kernel.org/linux-mm/CA+55aFxj81TRhe1+FJWqER7VVH_z_Sk0+hwtHvniA0ATsF_eKw@mail.gmail.com/

Но дефолты much saner так и не стали.

на современных компах обычно 8-32Гб озу - тут уже 20% выглядят глупо, как ты говоришь

Это не выглядит глупо, это и есть глупо. Решить проблему можно было хотя бы на уровне поставляемого sysctl.conf дистрибутивом. Поразительно, что косяк известен и имеет простое решение, но из года в год приносит тонну проблем пользователям.

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

Репортил ли баг в трекер своего дистра?

Лол. На моей памяти, этой проблемой заваливали форумы и багтрекеры дистрибутивов лет 15.

Нужно не оставлять попытки. Вот у федоры были тормоза при нехватке памяти - сосредоточились и практически решили проблему: https://pagure.io/fedora-workstation/issue/98 - добавили earlyoom, uresourced, своп перевели на zram.

Может таки стоит снова попробовать в 2022 решить проблему 12309?

багтрекеры дистрибутивов лет 15

Тогда и проблема имела другой масштаб, проблема тогда действительно была другой и получила решение в ядре 4.10:

Интегрированы патчи с улучшенной реализацией механизма фонового сброса данных на накопитель, решающие проблемы с подвисаниями во время копирования данных на медленный USB-накопитель. На системах с большим объёмом ОЗУ и медленными устройствами ввода/вывода переносимые на накопитель данные буферизируются в кэше обратной записи и копирование завершается в фоне. Ранее, операции сброса кэша обратной записи приводили к существенному снижению отзывчивости интерфейса приложений, подобных Firefox, вплоть до невозможности нормальной работы в течение нескольких минут. Например, выполнение "dd if=/dev/zero of=foo bs=1M count=10k" или копирование большого файла на USB-накопитель не давало запустить браузер или любое крупное приложение пока оставался не сброшен кэш обратной записи. 

https://www.opennet.ru/opennews/art.shtml?num=46035

После этого 12309 обрел другую, более мягкую форму.

После этого 12309 обрел другую, более мягкую форму.

Вместо полностью зависшей системы теперь просто заикается видео и всё тормозит. Dirty_ratio по прежнему 10%, у пользователей по прежнему бомбит при попытке записать что-нибудь на флешку. Еще не было такого года, чтобы на эту проблему кто-нибудь не пожаловался. Когда можно было просто добавить вменяемые значения в конфиг минта/манжары.

Dirty_ratio по прежнему 10%

вообще-то 20%

Да, ratio - 20, background_ratio - 10.

BTW, сколько у вас памяти? Сколько памяти было не занято при начале копирования? Есть ли своп, какова его конфигурация и объем? своп на том же SSD или на ZRAM?

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

и да, в этом треде хотелось бы услышать оправдания 12309-диссидентов, таких как intelfx и post-factum

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

Не ТС, но проблема знакомая.

Из последнего что помню: ядро 5.4 или 5.11. Памяти 32 Гб, во время фризов гигабайт 16 свободно. По ощущениям, чем больше памяти на машине, тем жестче проявляется проблема.

Может таки стоит снова попробовать в 2022 решить проблему 12309?

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

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

Это только один из возможных сценариев. Куда как более популярен другой:

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

Легко воспроизводится на хроме, который при старте вычитывает тонны устаревших кэшей и прочего говна из профиля пользователя. Запускаем чтение в /dev/null какого-нибудь ремуска блюрея в цикле и пытаемся запустить хром «на холодную». Наслаждаемся, идём заваривать чаёк. «На горячую» повеселее, но всё равно хреново.

Свободной памяти можно иметь хоть петабайты.

Запускаем чтение в /dev/null какого-нибудь ремуска блюрея в цикле и пытаемся запустить хром «на холодную».

Это совсем не то. Просто притормаживания при интенсивном чтении с системного диска - это почти ок и не проявляется на ссд и тем более те имеет отношения к 12309. Это даже не вешает гуй.

Из последнего что помню: ядро 5.4 или 5.11. Памяти 32 Гб, во время фризов гигабайт 16 свободно. По ощущениям, чем больше памяти на машине, тем жестче проявляется проблема.

Сейчас сможете это воспроизвести?

Просто притормаживания Это даже не вешает гуй.

Экран приложения не реагирует на события ввода и не обновляется. Иногда до секунд. Если это - «не вешает гуй», то у нас разные понимания завешенного гуя.