Низкая производительность при копировании файлов на USB-устройства и с них

Когда я копирую файлы на USB-устройства и обратно (камера, жесткий диск, карта памяти), моя система работает очень медленно. Например, если я хочу закрыть окно, я перемещаю мышь, но это занимает около 2 секунд или более, прежде чем курсор мыши перемещается. Когда я наконец наведу курсор на x и щелкну по нему, ничего не случится в течение 10+ секунд. Я пробовал это с отключенными всеми эффектами рабочего стола, но проблема остается.

Программное обеспечение: Linux Mint 9 KDE

• Материнская плата Asus SLI
• NVidia 6600 GPU
• 2 ГБ оперативной памяти
• 2 ГБ своп
• AMD Athlox X2 @ 3800+

Для меня это оборудование не должно иметь никаких проблем с запуском этого программного обеспечения, и это не так, пока я не скопирую файлы, используя USB. Где я должен начать искать, чтобы понять это? Я вроде думаю, что графический драйвер может быть частью проблемы, но я точно не знаю.

Кажется, есть проблема с огромными страницами в управлении памятью Linux . Это происходит редко, но звучит так, как будто вы это заметили.

причина

Это мой чрезвычайно упрощенный отчет о том, что, согласно статье, происходит.

Если не повезло, процесс застревает в тот момент, когда он выдает доступ к памяти. Это связано с тем, что при включении прозрачных больших страниц доступ к памяти может инициировать синхронное сжатие (дефрагментацию основной памяти), то есть синхронный доступ к памяти не заканчивается до того, как выполняется сжатие. Это само по себе неплохо. Но если происходит одновременная запись (например, буферизованных данных на USB), сжатие, в свою очередь, может остановиться, ожидая завершения обратной записи.

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

излечение

Обновление основной памяти, как это сделал OP, может помочь отсрочить проблему. Но для тех, кто не считает этот вариант, есть два очевидных обходных пути. Оба включают перекомпиляцию ядра:

• отключение функции прозрачных огромных страниц
• применяя патч Мела, как упомянуто в статье

Это звучит похоже на мой вопрос здесь (где ответ указал мне на этот вопрос):

/programming/10105203/how-can-i-limit-the-cache-used-by-copying-so-there-is-still-memory-available-for

Но теория совершенно иная, и решение, которое я использовал, не имеет отношения к вашему, но работает отлично.

Я использовал rsync, поэтому все, что мне нужно было сделать, это использовать параметр --drop-cache. (что делает копию немного медленнее как побочный эффект)

Единственный трюк, который я нашел, который действительно работает: Gnome, копирование файлов nautilus на USB останавливается на 100% или почти

Если вы хотите попробовать некоторые хитрости для опытных пользователей, вы можете уменьшить размер буфера, который использует Linux, установив / proc / sys / vm / dirty_bytes примерно на 15728640 (15 МБ). Это означает, что приложение не может получить больше чем 15 МБ перед его фактическим прогрессом.

Побочным эффектом является то, что ваш компьютер может иметь более низкую пропускную способность записи данных с этим параметром, но в целом я считаю полезным видеть, что программа работает долго, в то время как она записывает много данных, по сравнению с путаницей наличия Похоже, что программа выполнена со своей работой, но система сильно отстает, поскольку ядро ​​выполняет реальную работу. Установка достаточно малого значения dirty_bytes также может помочь предотвратить перезапуск вашей системы, если у вас мало свободной памяти и запуск программы, которая внезапно записывает большое количество данных.

Но не устанавливайте это слишком маленьким! Я использую 15 МБ для приблизительной оценки того, что ядро ​​может сбросить буфер на обычный жесткий диск за 1/4 секунды или меньше. Это удерживает мою систему от ощущения "отставания".