LINUX.ORG.RU
решено Форум — General  

Почему при высокой дисковой нагрузке (и 12309) случаются зависания?

 , , , ,


2

3

Собственно, сабж. Возьмем для примера 12309. Перекидываем что-нибудь жирное с ssd на допотопную USB 2.0 флешку. Естественно, данные считываются с ssd в память быстрее, чем пишутся на тормозную флешку. Если данных действительно много, они все не влезут в объем памяти, заданный параметром vm.dirty_ratio, который по-умолчанию равен 40% от объема памяти (предположим, у нас ее не больше 8 гигабайт). Возрастает iowait. Система зависает. При этом для работы памяти достаточно (запущены файловый менеджер и огнелис с парой вкладок плюс графическая оболчка). Так вот, почему стопорятся задачи, никак не связанные с записью на флешку (это даже не системный диск!)? Они не получают процессорного времени? А почему ядро не может вынести запись в отдельный поток? Почему ядро не отдает ресурсы процессора другим процессам? Ведь юникс изначально многозадачная система, и адаптация линукса к многоядерным процессорам произошла тогда, когда они стали массово доступными.

★☆

Последнее исправление: hateWin (всего исправлений: 1)

 ← 1 2 3 →
Ответ на: комментарий от hakavlad

Хм, запустил во время копирования tail /dev/zero — он, каналья, даже не завис :) И процесс, выжирающий память, был убит быстро. Вот только что! Потождал, когда buff/cache до 4 гигов вырастет. И он не завис. fornlr, darkenshvein, давайте эксперементировать. Попробуйте воспроизвести результат. Ядро 5.12.14.

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

Только что проверил с buff/cache 6.4 гигабайта. Не завис.

hateWin ★☆
() автор топика

Вообще, мне кажется, что тут может играть роль и отключение дискового свапа. Хотя раньше линукс вис от tail /dev/zero и без него. Или нет?

hateWin ★☆
() автор топика

Блин. Новые результаты были получены с тюнингованным /etc/sysctl.conf. Если провести опыт со значениями по-умолчанию ‐‐ система зависнет.

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

Ну да, память еще может быть выделена путем записи кэша - и киллер не приходит.

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

Если бы мне тогда кто нить задонатил несколько тысяч USD я б зафиксил. Я тогда отдебажил проблему, и нашел решение, но не хватило личных ресурсов чтобы закомитить решение.

Одна из наибольших проблем — кернел-сообщество разговаривает в терминах патчей а не алгоритмов. Когда я отписался в рассылку о ошибке в алгоритме на котором построен «block-device framework» меня не поняли и ответили что-то типа «patches welcome». Таким образом баг до сих пор никто и не зафиксил, но для некоторых моделей конкретного железа замержили WA.

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

ответили что-то типа «patches welcome»

Ну и в чем они неправы?

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

Я что-то подобное встречал, если речь о занулении носителя целиком. ИМХО, это никак не 12309, а какие-то блокировки в ядре при чтении таблицы разделов с устройства, на которое идёт запись. И, может сюда ещё добавляет сложность несовпадение таблиц GPT — в начале занулили, а в конце ещё осталась.

mky ★★★★★
()

Так вот, почему стопорятся задачи, никак не связанные с записью на флешку (это даже не системный диск!)? Они не получают процессорного времени?

Потому что они тоже пишут на диск. А dirty_ratio на всех одно. Когда условный браузер пишет в свою базу куки и делает fsync, он стопорится, пока процесс копирования на флешку не закончит абузить page cache.

Своего рода bufferbloat. Очень идейно похожая проблема и всем похер.

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