Linux тормозит при копировании

Зависание в процессе копирования на USB

Видимо после недавних обновлений, система преподнесла интересный баг. В процессе копирования файла выше среднего размера (>300MB) через USB наблюдается задержка

2мин. Т.е. если смотреть по размеру, то файл уже передан, но процесс копирования лочится и висит ждет непонятно чего. Проблема возникает как при передаче файла через FM, так и в консоли.
Вот описание бага и временное решение: http://unix.stackexchange.com/questions/107703/why-is-my-pc-freezing-while-im. Проверено, помогает.
Но тут возникает дилемма — или ты копируешь с нормальной скоростью и потом ждешь рандомное время пока разлочится процесс, или ты копируешь с низкой скоростью 6-8mbps.
Если у кого то была похожая проблема, подскажите. пожалуйста, в какой версии ядра ее пофиксили
Ubuntu 14.04 LTS

На 3.12 и выше замечал что-то такое, сейчас на 3.16 уже нет.

Проапгрейдился на 3.16. Баг остался.

возникает дилемма — или ты копируешь с нормальной скоростью и потом ждешь рандомное время пока разлочится процесс, или ты копируешь с низкой скоростью 6-8mbps

нет никакой дилеммы — файл копируется с той скоростью, с какой флешка его может записать, просто файлы копируются через кеш OS и прогресс в FM показывает скорость записи в оперативку

это не баг, в офтопике тоже самое

там тупо кеш уменьшили, лучше уж эту древнюю флешку выкинуть, чем всю систему из-за неё портить)

Источник

Интересно, почему линукс тормозит при копировании с HDD на HDD, хотя система на SSD

• / — Linux 4.4.0 на mSATA SSD
• /mnt/HDD1 — SATAIII HGST Travelstar 5K1000; работает на 6.0 Gb/s
• /mnt/HDD2 — SATAIII Seagate Samsung SpinPoint M8; работает на 3.0 Gb/s, потому что через ultra-bay

Система на SSD, копирую много гигов с HDD2 (HFS+) —> HDD1 (exFAT).

Вопрос не про скорость копирования, плевать в общем-то на неё, копирует да пусть копирует себе.

Вопрос в том, почему 12309? Почему у меня притормаживает линукс-то, даже без иксов? Потому, что HFS+ не Ext*, а exFAT работает через FUSE? И это всё в 2016-то году?

Он что, кеширует через mSATA на которой система? Процесор i7 4/8. Рамы 16GB, если что.

Интересно, почему линукс тормозит при копировании с HDD на HDD, хотя система на SSD

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

а линукс-то здесь при чем? Пусть себе копирует с hdd на hdd, чего система-то страдать должна, объясни?

Потому что он копирует. 12309 заключаетс в пониженной отзывчивости во время тяжелого дискового IO. Система при этом может хоть в tmpfs лежать, хоть в Гонолулу, лишь бы был IO.

Вроде объясняют это говёным взаимодействием подсистем vm и io, те ядро пытается прикинуть что можно закэшировать а что высваписть, вместо того чтобы выполнять само io.

А пробовал I/O polling ?

Поддержка поллинга ввода/вывода для блочных устройств (I/O polling). Поллинг позволяет уменьшить нагрузку на систему при использовании высокопроизводительных устройств за счёт периодического опроса состояния вместо генерации прерываний. Как следствие, в определённых ситуациях включение поллинга позволяет существенно повысить пропускную способность и сократить задержки ввода/вывода. Включение производится через запись 1 в /sys/block/DEV/queue/io_poll. В настоящее время поддерживается только режим O_DIRECT, а реализация помечена как экспериментальная и предназначенная для тестирования;

как раз в 4.4 появилось.

в венде вирусы, в линуксах 12309, у каждой системы свои косяки

А линукс тут может быть и не при чем. Я и на виндах такое видел: при интенсивном дисковом IO все тормозит и лагает, даже RDP-сессия к удаленному компьютеру.

Не пробовал, можно затеститровать, но на данных массивах пока-что неохота испортить fs/данные, если оно предназначено для тестирования. Чуть позже потестю, когда будет свободное место.

Источник

Фикс падения производительности при копировании/закачке файлов в Ubuntu

Уже не помню, когда начились проблемы с производительностью при копировании файлов, но тогда я этому не придал большого значения так, как копировал файлы редко. Относительно недавно в моем распоряжении появилось высокоскоростное подключение к сети Интернет и теперь я часто копирую/качаю большие файлы и проблема падения производительности для меня стала очень актуальной.

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

Проблема

При высокоскоростной закачке торрентов, многопоточном копировании с диска на диск, на флешки, загрузка процессора зашкаливает в 100%, быстро растет LA.

При этом на файловых операциях с небольшим числом потоков всё работает хорошо.

Немного теории

Есть такие штуки в операционной системе, называются планировщики ввода-вывода (IO schedulers), которыe являются прослойкой между блочными устройствами и драйверами низкого уровня. Задача планировщика — оптимальным образом обеспечить доступ процесса к запрашиваемому дисковому устройству. В случае жесткого диска — это означает минимизацию перемещений считывающей головки.
Деятельность планировщиков сводится к следующим аспектам:

• Увеличение производительности за счет переупорядочения и слияния запросов
• Предотвращение зависаний и перетирания считываемых данных записью
• Честное распределение времени доступа к ресурсам разным процессам

Планировщиков есть много и, как выяснилось, именно с ними была связана проблема, решаемая этим постом.
Рассмотрим вкратце наиболее распространенные.

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

Deadline

Планировщик, который ставит больший приоритет запросам на чтение, нежели запросам на запись. Запросы переупорядочиваются, но при этом время обработки запроса не должно превышать заданные пределы(по умолчанию, 0.5 с для чтения, 5 с для записи)

Для реализации используются 4 очереди: 2 очереди sorted-by-start-sector (для чтения и для записи) и 2 очереди FIFO(тоже для чтения и для записи). Обычно, запросы берутся из сортированных очередей, но если поджимает deadline(таймаут) первого запроса из очереди FIFO, то обработка запросов продолжается по сортированным очередям с этого элемента.

Лучше всего подходит для организации баз данных.

CFQ — Completely Fair Queuing

Цель этого планировщика — честное распределения времени доступа к ресурсу всех инициаторов запросов. CFQ может быть настроен для уравнивания процессов, групп процессов, пользователей.

По реализации, CFQ подразумевает по одной FIFO-очереди на инициатора запросов и переключается между очередями по алгоритму Round-robin.

Не знаю, кому нужна такая честность, но переупорядочения запросов для минимизации перемещения считывающей головки жесткого диска в этом планировщике нет.

Anticipatory

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

Планировщик Anticipatory базируется на Deadline. Подходит для десктопов, т.к. сохраняется отзывчивость подсистемы ввода вывода. Не подходит для RAID, TCQ. Плохо подходит в ситуациях, когда синхронные запросы посылаются разными процессами.

Решение

Планировщик по умолчанию в Ubuntu 10.10 — CFQ, но как показывает практика именно этот планировщик и вызывает высокую нагрузку на CPU при многопоточном копировании. Изменяем планировщик на другой, например, на Deadline и вуаля — больше нету загрузки CPU под 100%.

Для SSD дисков и Flash памяти вообще, как отмечено выше, рекомендуется использовать Noop.

Немного практики

Узнать активный планировщик

Чтобы посмотреть все доступные планировщики в системе и узнать, какой из них активен выполняем:
$ cat /sys/block//queue/scheduler
Здесь — имя блочного устройства, например sda .
Например, если диск sda , то нужно выполнить:
$ cat /sys/block/sda/queue/scheduler
На выходе получаем строку вроде этой:
noop anticipatory deadline [cfq]
В квадратных скобках указан текущий планировщик.

Смена планировщика на лету

Чтобы поменять планировщик в реальном времени без перезагрузки выполняем:
$ sudo -i
# echo > /sys/block//queue/scheduler

Здесь — один из присутствующих в системе планировщиков, у меня это: noop anticipatory deadline cfq . Например, чтобы поставить планировщик deadline , выполяем
$ sudo -i
# echo deadline > /sys/block/sda/queue/scheduler

Фиксация настройки планировщика

Далее, нам нужно заставить Ubuntu использовать выбранный нами планировщик и после перезагрузки. Для этого добавляем строку GRUB_CMDLINE_LINUX_DEFAULT=»elevator=» в конфиг GRUB 2.
$ sudo nano /etc/default/grub

UPD: После внесения изменений нужно обновить конфигурацию grub:
$ sudo update-grub

Если у вас grub, а не grub2, то добавляем строку elevator= в /boot/grub/grub.conf .

Помощь в выборе планировщика

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

Полезные ссылки

Рассказав о данном твике друзьям, удивился, что никто об этом не знал, решил запостить на Хабре, вдруг кому-то пригодится.

UPD:
Данная статья рассказала лишь об одном, по сути самом простом, способе решения проблемы, связанной, c т.н. багом 12309. Есть еще советы по решению данной проблемы:
— не менять планировщик CFQ, но отконфигурировать
— поставить zen ядро
— настроить аггресивность Swap
— купить жесткий диск с аппаратным планировщиком и много оперативки(чтоб в Swap не уходить)

Данный текст распространяется на условиях лицензии CC BY-SA
Оригинальный автор (проблема, решение) — g3n1uss. Соавтор (теория, оформление) — Ваш покорный слуга.

Источник

Когда починят «ускоренное» копирование файлов в Linux?

Итак, дано: Ubuntu 16.04.4, Fedora 27.

И там и там есть один баг, которому уже много лет, я даже честно не знаю сколько.

Суть бага: прогресс показывает сначала очень высокую скорость копирования, доходит до отметки примерно в 60% и врубает тормоза. У меня бывало так, что на Ubuntu 2-3 гигабайта копировались на флешку за пару секунд, а потом удовольствие растягивалось еще на 20 минут, при этом объем передаваемых данных равен 8 гб, понятное дело, что это баг, но ему уже сколько лет! Когда починят то? Забавно, но cp при этом показывает равномерную скорость копирования и в серверной Ubuntu я спокойно копирую данные в 500 гигабайт между ЖД без проблем.

Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.

Это баг разве? Я думал, так и задумано.

Да не знаю, но у меня уже прикипело видеть: 4.3 из 4.4 ГБ — осталось 14 секунд. И так 4 минуты уже.

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

Ну, мне тоже не особо нравится такое поведение. Я полагаю, он сначала кэширует данные в память, а потом начинает реальную запись. Можно попробовать понизить значение vm.dirty_ratio/vm.dirty_background_ratio, по идее, они должны как-то на это влиять.

Я знаю одно место, куда файлы можно копировать без задержки, /dev/null называется.

Проблема может быть в железе. Погляди smart. Я тут прикупил 10 ТБ винт и у него тоже такая проблема была — как выяснилось это он так плохие сектора передислоцировал. В общем проверки badblocks он уже не пережил. Придёт теперь сдавать диск по гарантии.

На 4х HDD дисках, двух флешках и одном SSD такая проблема.

Значит ровно столько влезает в оперативку, а потом грустно и долго идёт запись. Чудес не бывает или /dev/null.

В любом случае глянь smart.

Да не, со смартом 146% все ок. А оперативки, ну вот не знаю, есть ноутбук, на нем стоит Windows 10. Там два гигабайта оперативной памяти, все работает окей, кроме хрома, что понятно. С копированием в 18м году проблем также нет.

Стоит Ubuntu 16.04, Intel I5-4670, 16 гигабайт памяти, и епрст, система не может нормально скопировать файлы, тут вряд ли проблема в ОЗУ. Через cp -av все копируется гладенько, как и должно.

Я теперь тяжелые каталоги через cp и перемещаю. В десктопной убунте. Смешно.

1. Ты же правда в один поток копируешь? флешки фактически не умеют даже в два потока.

2. Почитай что такое «отложенная запись» цифры от cp при записи на flash направляй в /dev/null.

никаких багов нет, есть простое незнание «как оно работает».

При чем здесь CP? Оно идеально работает. Я говорю про то, что десктопная Ubuntu не может «равномерно» показывать прогресс копирования файла и постоянно врет.

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

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

Кстати да, я с ссд копировал.

Всё правильно. На винде такое же поведение. man кеш.

На Windows все четко.

windows nt в 1997 году на 3х дюймовые дискеты файлы копировала точно также. Это фича, но ты можешь уменьшить размер кеша на запись и копирование на флешку перестанет возмущать твоё чувство прекрасного 🙂

Я говорю про то, что десктопная Ubuntu не может «равномерно» показывать прогресс копирования файла и постоянно врет.

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

cp на самом тоже врёт при отложенной записи. все врут.

Монтируй флешку с опцией sync

windows nt в 1997 году на 3х дюймовые дискеты файлы копировала точно также.

Вот тут ты врешь

Сам видел. 2х процессорный пентиум про 200МГц как сейчас помню. У меня самого тогда пень 166 ММХ был с 95й виндой.

Эти крутилки нужны для каждого блочного устройства. И желательно, в секундах, а не в байтах.

Плюсую. А конкретно для решения заявленной ТС-ом проблемы достаточно подкрутить vm.dirty_background (bytes или ratio) на что-то более-менее соизмеримое с пропускной способностью USB.

iostat -d 1 что показывает до начала тормозов и после?

Никогда не видел как в винде шкальник копирования доходил до 100% и там зависал на сутки?

Не рассказывай мне байки из склепа,не было такого никогда

У тебя неправильный шиндоуз; помню, на спермёрке охреневал от прогрессбара в эксплорере: сразу добегает почти до конца, а потом ползёт по чуть-чуть. И насколько я понял, это тупо свистелка такая для тупых хомячков — напоминает J2ME-трояны с прогрессбаром, в которых надо тыкать Fire для «ускорения» прогрессбара (на деле он вообще без этого не движется) — чтобы доверчивая жертва по инерции подтвердила пермишшон на отправку SMS. В десятке, насколько помню, в этом ничего не поменялось; зато добавили в диалогах копирования красивый и подробный график, тут лялипсу ещё долго ползти, эге. Установщик с восьмёрки в том же репертуаре: почти час пишет что-то в духе «подождите ещё немного», «осталось совсем чуть-чуть», «ну вот буквально через пару мгновений», «я ещё недолго, мамай клэнус!».

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

Я как-то поднимал эту тему с GNU / Linux Debian. Мне вроде намекали, что я идиот и железо у меня кривое.

Когда починят «ускоренное» копирование файлов в Linux?

Попробуй поставить по крону с интервалом в 1 сек — /bin/sync.

Не рассказывай мне байки из склепа,не было такого никогда

Если ты такого в своем склепе не видел, то возможно это связанно с тем, что у упомянутого 200мгц-го п про были невероятные по тем временам 128М ОЗУ и винда легко могла закешировать на запись жалкие 1.44М дискеты.

В те времена ходили анекдоты типа «пап, покажи многозадачность виндовз 95. Сейчас сынок, дискетку доформатирую». А тут такое чудо — копируешь 1М файл на дискету мнгновенно, а он перез пару секунд после окончания записи включает светодиод и начинает жужжать. И не тормозит при этом.

Но у меня Linux на десктопе и черт побери, он в 2018 еще не готов для массового пользования, когда такие детские баги вылезают.

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

Источник