Очень медленный на USB ввод / вывод

386
tmsg

(Отказ от ответственности: Linux noob переключается с Windows 7 на Linux.) У меня есть компьютер с двойной загрузкой с процессором Core i5 третьего поколения (4 реальных ядра), 12 ГБ ОЗУ и 240 ГБ SSD Samsung EVO850. Эта система не самая быстрая под солнцем, но она также не дрянится и все нормально, все гладко, плавно и хорошо себя ведет, как в Windows 7/64, так и в разновидности Debian Stretch, которую я использую.

Однако я только что скопировал (с помощью rsync -aW) довольно большой каталог файлов .jpg (~ 50 ГБ) с SSD на флешку USB3.0. Флешка распознается как USB3, я проверил это с помощью lsusb, и, хотя номинальная скорость записи была ~ 90 МБ / с, казалось, что копия была не намного быстрее, чем 25 МБ / с. Оба раздела имеют формат NTFS, без сжатия.

Однако настоящая проблема заключается в том, что во время процесса копирования ПК стал практически непригодным для использования. Почти любая активность браузера (Palemoon), такая как загрузка новой страницы или даже просто добавление закладки, приводили к 30, 40, 50 секундам полной остановки (я сначала думал, что браузер был мертв, но он был почти полностью без связи с внешним миром в течение почти минуты). Я проверил в окне терминала htop, ни одно из 4 ядер не имело нагрузки более 5% за любой 10-секундный период, использование памяти было значительно ниже 1 ГБ. В том же терминале команда df выполнялась более 40 секунд, а иногда и командная строка тоже не работала в течение 5 или 10 секунд.

Это выглядит как очень плохой случай серьезного узкого места ввода-вывода где-то ... поэтому я повторил тот же сценарий и дал процессу rsync режим ионизации на холостом ходу и перезапустил его, чтобы он был как можно лучше. В некоторой степени это помогло, но ПК все еще далек от использования.

Я выполнил и до сих пор выполняю те же или очень похожие работы с тем же оборудованием под Windows 7/64, и хотя система явно не такая бодрая, как при нулевой нагрузке, она определенно остается на полезной стороне.

Я надеюсь, что есть лучший способ скопировать $ BIG_DATA на USB-накопитель, чем этот ... потому что мне лучше было бы загрузиться в Windows, скопировать туда и потом перезагрузить в Debian.

Кто-нибудь получил хорошие идеи о том, как я могу сделать вещи более плавными? (Меня не волнует, займет ли копия пару минут дольше, пока она работает в фоновом режиме, и я могу работать более или менее нормально на переднем плане.)

4

1 ответ на вопрос

5
harrymc

Rsync выдвигает диски на максимальные скорости, и вы не должны ожидать, что что-то еще будет отзывчивым. Загрузка программ будет бороться за доступ с дисков, и даже обмен будет медленным.

Решения могут быть:

  • Используйте --drop-cacheопцию в rsync (доступно не во всех версиях)
  • Используйте nocache, уже доступный как пакет в некоторых дистрибутивах
  • Огромные страницы все еще могут быть проблемой в Linux, но их легко решить, запустив watch -n 5 syncили с помощью более продвинутых радикальных решений, которые не для новичка
  • Монтирование файловых систем с помощью noatimein /etc/fstabсокращает время записи, если у вас огромное количество маленьких файлов
  • Некоторые другие методы, которые также требуют хороших знаний, понимания (и резервного копирования):

    # hopefully better multitasking I/O performance echo 20 > /proc/sys/vm/dirty_ratio  # Try to keep at least 100MB of free RAM at all times echo 100000 > /proc/sys/vm/min_free_kbytes  # Default 100 - try more aggressively to reclaim inodes, etc from cache echo 160 > /proc/sys/vm/vfs_cache_pressure 
«Rsync толкает диски на максимальные скорости ...» Так что, возможно, rsync - неподходящий инструмент для такой работы? И спасибо за другие советы, я посмотрю. tmsg 5 лет назад 0
Мой локальный rsync не включает в себя патч --drop-cache, но nocache, похоже, значительно помогает, хотя машина все еще выглядит менее "плавной", чем под Windows. Трудно сказать, имеет ли какой-либо из других вариантов заметный эффект ... Спасибо за ваш ответ, проголосовал. tmsg 5 лет назад 0
Системы ввода / вывода Windows и Linux радикально отличаются, поэтому будут различия. В большинстве случаев Linux выигрывает по скорости, но не у всех. harrymc 5 лет назад 0
I take your word for it:-/ I've also added transparent_hugepage=never to my kernel options... I will monitor the behaviour for a while to see whether this has an adverse effect. From what I've read this might be a good idea anyway for a non-server PC. tmsg 5 лет назад 0