LINUX.ORG.RU

Тормоза и фризы при работе с usb-флешкой

 , , ,


0

1

Предыстория такая: я заменил raspbery pi 1B на Rpi 3. 10-и кратный прирост производительности не слишком далёк от правды. Даже тактовая производительность ядра выросла раза в 2. Этого будет вполне достаточно для большинства моих повседневных задач, так что надо делать! И всё было бы легко и просто, но хорошую SD-каротчку заменили на microSD, а я ещё не встречал microSD, которые быстро и отзывчиво работают в случае одновременного чтения и записи в несколько потоков.

Тормоза, подвисания всего до 10 секунд меня не удивили. Вынес корень системы на отдельную флешку (usb2, 8Gb, kingston, больше про неё ничего не известно), ФС ext4 с отключенным журналом, убил управление памятью через cgrops (косяк systemd), вынес своп на hdd и настроил swappines. Переключил i/o шедулер на noop. Полёт нормальный, примерно то, чего можно ожидать от старичков вроде пеньтиум М+ 512М оперативки.

Но флешка маленькая, поэтому купил дешёвый transced 32Gb, usb2, и поставил корнем. Настройки полностью аналогично предыдущему варианту. В случае одновременной записи и чтения на неё вся система начинает виснуть. Проявляется как полое отсутствие реакции на мышь, клавиатуру и остановку обновления интерфейса (все приложения), в Х-сервере, в консоли и в сессиях ssh. Если воспроизводится звук, то обычно продолжает играть, до исчерпания кеша. Пинг и транзитный трафик проходит. После завершения дисковой операции работа возобновляется, события ввода обрабатываются. Среднее время подвисания 3-5сек, в самом тяжёлом случае система не отвечала ни на что в течении 1,5 часа.

Я предположил, что дело в том, что дешёвая флешка работает корнем и какие то жутко важные, низкоуровневые операции ввода-вывода стопорят всю систему. Решил собрать тест для флешек чтобы найти и купить нормальную, быструю. Собственно тест: флешка формаируется в ext4, с неё воспроизводится видео битрайта 20 Мбайт/с, на неё копируется папка музыки и на ней располагается своп-файл гимпа, который в это время совершает преобразование полотна на 0,4 Гпикселя. Тестирование провожу на ноутбуке (gentoo, самосборное ядро, openRC вместо systemd, однозначно достаточное питание на портах).

Результат немного неожиданный: имею примерно такие же фризы всего кроме сети и звука, разве что 0-2 сек, но возникают часто или очень часто. И такая дисковая активность обычно заканчивается каким то сбоем ФС, кучей сообщений dmesg по поводу невозможности прочитать или записать блок и автоматическим перемонтированием в ro. Особенно странно, что ни одна программа, работающая с флешкой, не должна ставить раком весь рабочий стол, Х-сервер и чёрт ещё знает что.

P.S. Тот же тест, но над 64Gb SD на шине usb фризов не даёт, ошибок fs пока не замечено. Как и винда на «плохой» флешке - работает отзывчиво.

★★★★★

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

Нормальность флешки следует из цены? Внешнего вида, конструкции? Из чего же? У usb2 в любом случае низкая пропускная способность и высокие накладные расходы, никогда не сравнится с внешним sata/tb ssd например. Может только выезжать за счёт изменения параметров кешей до неразумных значений. Поправьте кто больше разбирается в вопросе.

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

В данном конкретном случае «нормальность» определяется тем, что флешка не вызывает фризов. А поставить на Rpi что то кроме usb-накопителя просто нереально.

Да, очевидно это баг 12309. Разве что он вроде как от ядра зависит, а не от модели флешки.

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

И такая дисковая активность обычно заканчивается каким то сбоем ФС, кучей сообщений dmesg по поводу невозможности прочитать или записать блок и автоматическим перемонтированием в ro.

Да, очевидно это баг 12309.

А не думаешь, что это никуда не годный ssd?

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

Это новая флешка. Куплена неделю назад. Перед тем, как залить туда распбиан, прогнал 4 цикла запись-чтение на бэдблоке, всё ок. Мне кажется крайне маловероятным что она сыпется. И фризы явно появляются до ошибок чтения. Т.е. это скорее фс наворачивается из за фризов, а не наоборот.

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

Нет, это совершенно другое. Но где можно почитать про все эти опции, указанные в /sysctl.d/12309.conf ?

kirill_rrr ★★★★★
() автор топика

Это не ты там анону втирал, как у тебя всё на дешёвой флешке летает? Бгг...

anonymous
()
Ответ на: комментарий от backbone

Пробовал покрутить настройки кеша. На ноуте dirty_background_ratio заставил ядро работать отзывчиво, но скорость записи упала до 0,5 М/сек. А пишка продолжает тормозить, при dirty_bytes 1МиБ вообще не хочет загружаться.

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

Мне ratio, емнип, не помогал. Проблемы были такие: 1) неверно отображался прогрессбар в mc; 2) при сборке emerge в несколько нитей и процессов, а также при длительном копировании (неважно, с USB или ещё откуда) остальные процессы «заикались». С указанными по ссылке значениями проблем не наблюдаю, копирую по гигабитке на диск ноутбука (50-60mb/s) и в tmpfs (100-110mb/s - scp со сжатием), даже намёка нет на «заикания» музыки, браузера и проч..

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

Ну, *_bytes и *_ratio если верить документации это 2 взаимоисключающих способа задать одно и тоже. А Rpi3 это видимо особо тяжёлый случай и «заикается» она по 10 секунд.

kirill_rrr ★★★★★
() автор топика

Полностью адекватного решения не нашёл. Минимальное количество зависаний если корень размещён на usb-hdd, но в этом случае он вообще не паркуется. Почти так же удволетворительно система работает, если разместить корень на microSD повышеной скорости (пометки HS и класс U если ничего не путаю) и выкрутить dirty_{,background_}bytes в 1-2 МиБ. Это тише но медленно (0,5-1,5 М/сек запись), из за медленного обмена данными намного чаще возникают тормоза.

kirill_rrr ★★★★★
() автор топика
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.