Система зависает / не отвечает / не работает при копировании большого файла на USB

52

Вчера я копировал один файл объемом 8 ГБ на USB с медленной скоростью записи 7 МБ / с, а объем оперативной памяти составляет 3 ГБ. Во время копирования система зависла до такой степени, что я даже не мог переместить курсор.

Мне удалось войти в текстовую консоль и запустить iotop, это показало, что названный процесс kswapd0занимает 99,99% ввода-вывода.

Существуют ли обходные пути, поэтому копирование большого файла не делает мою систему непригодной для использования?

sashoalm
источник
14
Эта ошибка настолько нелепа ...
king_julien
Да, это происходит не только с Ubuntu, но и с другими версиями Debian. Я также видел ту же проблему в Kali Linux и Parrot OS. Кали имеет худший сценарий, в то время как попугай делает это гладко, но даже при том, что зависает для очень больших размеров. Я думаю, что это проблема в ядре Linux и как она написана. Это и останется худшим кошмаром Linux за все время.
Mohith7548

Ответы:

34

В соответствии с этим сообщением об ошибке я решил, добавив следующие строки

vm.dirty_background_ratio = 5
vm.dirty_ratio = 10

в /etc/sysctl.conf

и работает

sudo sysctl -p
Филипп Гачу
источник
12
Хотите объяснить, что делают вышеприведенные строки?
nsane
3
@ nisargshah95 извините, но понятия не имею,
поищите
4
@ nisargshah95 Подробности проблемы объясняются в двух статьях LWN, ссылки на которые приведены
Rmano,
1
Спасибо, я только что обнаружил, что моя Ubuntu 16.04 не может записать два файла по 1,4 ГБ на USB без этих двух строк, я зависал на несколько часов, это решенная проблема, кому какое дело, иногда вы просто хотите скопировать файлы и переместить на.
Майк
1
У меня были значения 5 и 60. Они контролируют процент памяти, используемой для операций, dirty_background_bytesа также dirty_bytesиспользуют абсолютные байтовые значения. Я исправил эту проблему с помощью второго ответа, но чтобы сделать его постоянным, добавьте его sysctl.conf, посмотрите этот ответ . Поэтому при использовании процентных значений настраивайте их при обновлении памяти.
PeterM
20

Я столкнулся с аналогичной проблемой. Мой 64-битный Ubuntu 14.04. Поэтому после долгой борьбы я нашел ответ, который решает мою проблему. Для простоты использования я добавил нижеприведенные команды в ответе выше . Проверьте ответ для подробного объяснения.

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

После использования вышеуказанной команды система начала нормально работать при копировании файлов.

Спасибо @Rmano .

Махендран Саккарай
источник
2
Настройки отношения не помогли в моей системе 12.04 с медленным общим ресурсом NAS. Но после установки байтов напрямую, как предлагается здесь, моя система снова может использоваться при копировании в NAS.
MIVK
6
Этому вопросу уже 3 года, и он все еще необходим, чтобы избежать использования непригодной системы при копировании в pendrive. Немного информации: если pendrive отформатирован с использованием Linux fs вроде ext4, этого не произойдет. Когда я сказал «непригодная система», я действительно имел в виду это, указатель мыши перестает отвечать на запросы, и вам приходится настаивать, чтобы перемещать его по экрану, вы смотрите на системный монитор, и нет никакого ненормального использования ресурсов. Все ли пользователи ядра используют процессоры Intel 6-го поколения и SSD-накопители? Почему они не замечают этого во время тестирования.
Hatoru Hansou
3
@HatoruHansou Я чувствую то же самое, я только что установил свежий Debian Stretch, и эта ошибка также присутствует здесь. Я знаю, что это зависит не от дистрибутива, а от исходников ядра, но мужчин, почему же это все еще не исправлено?
Марецкий
1
@Marecky После некоторого прочтения кажется, что dirty_bytes - это не только USB. Они влияют на все операции ввода-вывода, поэтому после выполнения эха вы меняете их глобально, а не только для pendrive. Только для текущей сессии, я думаю. Похоже, что текущие значения ядра подстроены под новые устройства хранения. Медленные pendrives страдают как побочный эффект. Извините, нет ссылки, но это должно быть легко найти путем поиска в Google.
Hatoru Hansou
3
Смотрите этот ответ, чтобы сделать его постоянным
PeterM
5

У меня возникла похожая проблема с зависанием системы при копировании на флешку. Я отправил отчет об ошибке по этому адресу : https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1267648.

В качестве обходного пути я обнаружил, что отключение свопа полностью устраняет проблему.

Владимир Руцкий
источник
1
К сожалению, это не сработало для меня в Ubuntu 16.04.
Программист
У меня не работало и на Ubuntu 16.04.3 LTS - на ноутбуке Alienware 17 R2.
AnthonyK
4

Да, есть настройки ядра, которые вы можете настроить, указав, сколько данных нужно пометить как записанные, прежде чем они действительно будут записаны на диск. Посмотрите здесь для довольно полного их описания. В частности, вы захотите найти значение dirty_ratio, которое хорошо вам подходит (по умолчанию оно слишком велико для настольных компьютеров / ноутбуков, но не существует единого магического числа, подходящего для всех).

Bandrami
источник
2
Эй, не могли бы вы предложить мне, какие цифры мне нужно установить на основе характеристик моего ноутбука? см askubuntu.com/questions/713723/...
3

У меня была точно такая же проблема (в 2019 году), на Ubuntu 19.10, при копировании большого количества файлов с USB-диска на SATA-диск. Обе файловые системы являются ext4. Когда я выключил своп, проблема исчезла. Это похоже на некоторую ошибку в распределении памяти для дисковых буферов - очевидно, ядро ​​пытается выделить как можно больше памяти для дисковых буферов в такой ситуации, что не имеет смысла (создание дисковых буферов в swap ...), или он просто неправильно вычисляет объем памяти, который может быть использован для кэширования ...

Чакер
источник
Работало ли какое-либо из решений здесь для вас? Я тоже начал страдать от этой проблемы после обновления до 19.10 и в процессе обновления ядра тоже. В моем случае это происходит, когда я копирую большой файл из раздела A в B того же SSD. Отключение SWAP "исправляет" проблему.
Pileofrocks
1

У меня были похожие проблемы при копировании файлов на exfatдиск. У меня было меньше проблем с использованием ext4файловой системы на жестком диске USB.

булава
источник
1
Был ли этот вопрос на ext4 тоже
PeterM
Копирование Fedora 27 (ядро 4.17.5-100) с вращающейся ржавчины с USB-подключением на флешку с USB-подключением. Похоже, это заходит так далеко, как замораживание блокировщика экрана в середине затухания. :-( ~~~
Дэвид Тонхофер