Linux тормоза при копировании файлов
Обновлено: 03.07.2024
Зачастую пользователи Linux разных дистрибутивов сталкиваются с проблемой копирования данных на USB флешку. Проблема заключается в том, что копирование больших файлов сначала происходит очень быстро, а потом на нескольких процентах до завершения копирования зависает на длительное время.
Самое интересное, что иногда копирование происходило за несколько секунд, файловый менеджер выдавал окошко об успешном выполнении задачи, но на флешки продолжал мигать светодиод, свидетельствующий о том, что процесс записи еще запущен. Отмонтировать ее тоже нельзя, давалось предупреждение, что файлы будут повреждены или USB flash drive выйдет из строя.
Проблема
Я тоже столкнулся с такой проблемой. Сначала я думал, что может быть проблема в драйверах? Проблема с моим компьютером, не все железо благоприятно восприняло Debian 9. Или материнская плата работает не во всю мощность, потому как копирование в ОС Windows 7, 10 происходило ровно нормально. Четко, быстро, с процентами. Данная проблема возникала совершенно на разных компьютерах с которыми я имел дело. Но все оказалось немного иначе.
Подчеркну, что описанная мной проблема возникает именно на 64-битных Linux с большим объемом ОЗУ.
Решение
Итак, для решения проблемы, в командной строке от администратора нужно выполнить следующее:
На все машины 64-bit я добавляю эти команды в файл автозапуска скриптов /etc/rc.local .
Данное решение возможно (скорее всего) снизит производительность (скорость записи) USB устройств - но это компромисс между задержкой и скоростью. Чтобы вернуться к настройкам по умолчанию, сделайте следующее:
. которые являются значениями по умолчанию, что означает, что поведение обратной записи будет контролироваться параметрами dirty_ratio и dirty_background_ratio.
Примечание для не очень опытных пользователей linux:
файлы в каталоге /proc являются псевдо-файлами - просто каналами связи между ядром и пользовательским пространством. Никогда не используйте редактор, чтобы изменить или посмотреть на них; вместо этого воспользуйтесь приглашением терминала от суперпользователя, например, sudo (Ubuntu) или su (Debian) и используйте echo и cat для внесения изменений.
Уже не помню, когда начились проблемы с производительностью при копировании файлов, но тогда я этому не придал большого значения так, как копировал файлы редко. Относительно недавно в моем распоряжении появилось высокоскоростное подключение к сети Интернет и теперь я часто копирую/качаю большие файлы и проблема падения производительности для меня стала очень актуальной.
Поверхностный гуглеж не дал результатов и я начал копать глубже, оказалось, что проблемы высокой нагрузки CPU есть у многих убунтоводов, если не у всех, а решение данной проблемы быстрым поиском не находится, поэтому я решил написать небольшой how-to по устранению высокой нагрузки на процессор при копировании файлов.
Проблема
При высокоскоростной закачке торрентов, многопоточном копировании с диска на диск, на флешки, загрузка процессора зашкаливает в 100%, быстро растет LA.
При этом на файловых операциях с небольшим числом потоков всё работает хорошо.
Немного теории
- Увеличение производительности за счет переупорядочения и слияния запросов
- Предотвращение зависаний и перетирания считываемых данных записью
- Честное распределение времени доступа к ресурсам разным процессам
Простейший планировщик, работающий по принципу 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]
В квадратных скобках указан текущий планировщик.
Смена планировщика на лету
Фиксация настройки планировщика
Далее, нам нужно заставить Ubuntu использовать выбранный нами планировщик и после перезагрузки. Для этого добавляем строку GRUB_CMDLINE_LINUX_DEFAULT="elevator=
$ 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. Соавтор (теория, оформление) — Ваш покорный слуга.
при копировании больших объемов данных с диска на диск (или с раздела на раздел одного диска);
при нехватке ОЗУ (и, соответственно, диком своппинге);
при копировании на USB-девайсы;
при использовании зашифрованных разделов;
Соответственно, фиксы тоже будут разные.
Сначала тест: восприимчива ли ваша система к 12309? введите в терминале:
dd if=/dev/zero of=/tmp/test bs=1M count=1M
и понаблюдайте за отзывчивостью системы. Если всё по-прежнему быстро - то читать статью можно разве что для профилактики и расширения кругозора.
Оптимистическое выделение памяти
То есть стратегии вытеснения страниц нужно делать переключаемыми, а это работы на много времени не столько реализации, сколько тестирования.
Пока что же можно сделать так, чтобы на явно дикие запросы malloc() отвечал решительным отказом, и чтобы зажратость программы определялась на этапе выделения памяти, а не тогда, когда программа радостно вывалит туда пару гигабайт данных.
Для этого нужно прописать в /etc/sysctl.conf
Максимум памяти, который можно будет выделить, будет равен в сумме
объему свопа + некоторому проценту физической памяти. Этот процент по
умолчанию равен 50, но можно его несколько увеличить. Во всяком случае, я
выставил его в 80 и пока что катастроф нет.
Так как ядро, вообще-то, достаточно умное, чтобы сначала при возможности сбросить в своп анонимные страницы спящих процессов, то своп лучше все же иметь. Чаще всего доставать этих страниц надо будет меньше (особенно в случае Xorg и его драйверов, не путать с драйверами ядра).
Уменьшение размеров дисковых буферов
Это работает вот как. У ядра есть буфер файловой системы. Мы пишем много данных. Этот буфер заполняется грязными страницами, а потом выполняется системный вызов sync() и буфер сбрасывается на носитель. Чем больше буфер, тем больше данных надо будет сбрасывать. Все бы ничего, да вот когда кому-то вдруг вздумается выделить себе памяти, в первую очередь будут сбрасываться все эти буферы, и если при этом вдруг надо будет закачать страницы с исполняемым кодом, им опять-таки придется ждать в очереди. Опять слайдшоу, с возможной цепной реакцией.
echo 2097152 >/proc/sys/vm/dirty_bytes
echo 2097152 >/proc/sys/vm/dirty_background_bytes
Для сохранения после перезагрузки, прописать в /etc/sysctl.conf
Стоит учесть, что кеши чтения файловой системы будут все так же занимать почти все свободное ОЗУ, но при этом запись будет осуществляться, как только блоков, помеченных на запись, наберется на 2 мегабайта.
Значение dirty_bytes должно делиться на 4096 нацело.
В результате, даже при переваривании больших объемов данных, система не заикается. Может затормозить сам процесс, который выделяет память, но отзывчивость системы не теряется.
Кеш файловых систем
Иногда бывает такая проблема: у вас относительно новое ядро, тесты с dd проходят на ура, а вот когда надо много маленьких файликов создавать/менять/убивать, например, командой dpkg, система встает колом и не может даже регистрами пошевелить.
По умолчанию оно почему-то 100, что просто безумно на десктопных нагрузках.
Установить параметр swappiness равным 10 или 5, чтобы подкачка задействовалась только при исчерпании 90 и 95% памяти соответственно:
sudo nano /etc/sysctl.conf
Добавить в конец vm.swappiness = 10
Сохранить и выполнить sudo sysctl -p
Сменить планировщик ввода-вывода. В такой ситуации рекомендуют использовать BFQ, но он не в основной ветке ядра, и его нужно добавлять в ядро
самому (в некоторых дистрибутивах, например Calculate Linux, BFQ по умолчанию). В остальных же случаях можно сменить планировщик на лету.
Перевесить системные прерывания на одно ядро (на многоядерном процессоре) скриптом:
for interruption in `grep usb /proc/interrupts | awk ''| sed 's/\://g'` ; do
При самостоятельной сборке ядра, задействовать 100Hz таймер ядра и опцию No Force Preemption (Server) mode.
Выставить приоритет ionice для ядра 1 (realtime) для пространства пользователя (userspace) - 3.
Установить ядро с патчами для реализации режима реального времени (linux-lowlatency, есть по умолчанию в репозиториях
Подводя итог, можно отметить: самого бага давно нет, но на некоторых конфигурациях могут возникнуть его симптомы, по совершенно
разным причинам, от нехватки памяти до аппаратных проблем с дисками. Пугаться этого не стоит, ибо например в Windows, эта проблема
ещё более серьёзна, а самое главное - никак не решаемая. Система может с лёгкостью встать колом при копировании больших объёмов данных,
и её придётся перезагружать кнопкой Reset. Неоднократно с этим сталкивался. А вот симптомы 12309 удалось увидеть лишь при копировании фильма с
NTFS-раздела на старую, потрёпанную жизнью, флешку. И то потом проблему так и не удалось воспроизвести, потому списал на случайность.
Здравствуйте!
У меня пока мало опыта в юникс-системах, и мне нужна помощь в решении одной серьёзной проблемы, которая меня дико выбешивает. Проблема эта связана, на самом деле, не конкретно с манжарой, а с любым линукс-дистрибутивом. Помимо манжары я пробовал Suse, Ubuntu, Kubuntu, Mint, пробовал разные DE(XFCE, KDE, Cinnamon, Gnome), больше всего мне запала манжара, которой я сейчас пользуюсь, но и здесь меня преследует проблема, которая преследовала меня во всех вышеперечисленных дистрибутивах — невыносимые тормоза при копировании относительно больших(более гигабайта) файлов. Если я попытаюсь, к примеру, скопировать фильм с одного раздела на другой, система просто впадает в кому — становится невозможным что-либо нажать, выделить, открыть\закрыть, даже курсор мыши иногда замирает. При этом неважно, копирую ли я на флешку, телефон, или раздел HDD, файловая система носителя также не имеет значения. Проблема проявляется как на стационарной машине, так и на ноуте, и только в юникс-системах.
Читал я многие забугорные и наши форумы — с проблемой сталкивались многие. Кто-то советует отключить Swap, кто-то — изменить 'vm.dirty_bytes' и 'vm.dirty_background_bytes' в 'sysctl.conf', кто-то предлагает сменить планировщик. Мне нихрена не помогает.
Буду премного благодарен за любую помощь в решении проблемы.
14 комментариев
те же яйца, я при копировании пользуюсь doublecmd в нем почти не заметно, когда копируешь.
Хмм… У меня проблема наблюдалась при работе с NTFS, но действительно, Double Commander копирует даже 50-70 gb без каких-либо тормозов.
Тоже поначалу грешил на то, что копирую с NTFS на EXT4, но при копировании с EXT4 на EXT4 ситуация ничуть не лучше.
Попробовал — копирует реально быстро, но система при этом, к сожалению, всё такая же некликабельная и мёртвая, в некоторых случаях только кнопка 'reset' спасает. При этом загрузка ЦП и памяти вполне себе обычная, своп не используется, а индикатор активности HDD на корпусе стабильно горит на полную.
Судя по тому что у вас этот косяк проявляется на многих дистрах линукса можно предположить что это проблема скорее совместимости вашего железа с unix системами!
Странно, таких проблем не замечал, ноуты не пользовал но стационарные на чипсэтах intel, AMD, nvidia под управлением Debian (ubuntu) и Manjaro никогда не тормозили при копировании даже образов системы (20-40 гб), более того заметил, что каталоги с кучей мелких файлов копируются намного быстрее чем винде (есть опыт), думаю что Kreon прав.
Всем привет, это снова я. Спасибо всем за ответы!
Хотел бы поделиться очень интересным наблюдением:
Только что загрузился с Live-образа манжары и скопировал фильм весом 53 Гб с NTFS на NTFS раздел. Весь процесс копирования занял менее 10-ти минут, при этом не было ни малейшего намёка на какие-либо тормоза, копирование проходило абсолютно незаметно. Можно было спокойно пользоваться браузером, ковырять рабочий стол, запускать приложения, даже копировать что-то ещё параллельно, — никаких, даже малейших фризов, не наблюдалось. Попробовал также пару других дистров в режиме Live-Iso — ситуация аналогичная, при копировании даже больших файлов система работает запредельно плавно.
Из этого следует, как не трудно догадаться, что проблема тормозов при копировании файлов возникает лишь в установленной системе и не появляется в системе, запущенной в Live-режиме.
Есть идеи, с чем это может быть связано? Может, конфиги какие поковырять?
Последний раз редактировалось 15 августа 2017, 16:32
Хммм
Координальное различие лайв режима и установленной системы это то что все файлы дистра в оперативе а не на венике.
Я бы посоветовал чекнуть раздел на котором устанвливаешь системы(root, home и тд) на целостность может куча битых секторов, а так же попробывал низкоуровневым форматированием пройтись по всем разделам кроме файлопомоек, ну и проверил что все они в ext4)))
Если вы пробовали, как писали раньше, на разных компьютерах, то битые или сектора с большой задержкой чтения жёсткого диска не может одновременно проявляться на разным машинах, но почему и в Suse, Ubuntu, Kubuntu, Mint (DE сдесь мало играет роль) тоже самое? Вопрос. А вот Live-режим, почему не создаёт проблем? Вот и в моём случае Manjaro в Live-режиме выходит в интернет, а в установленной системе — нет. Помоему здесь есть скорее связь, чем совпадение.
Не обратил внемание на разные компы, сорян. Но с другой стороны тогда это какая то магия, железо то разное)))
И в моем пониманиии тут какой то не фарт у ТСа, а раз мы расматриваем не фарт, то вариант с тем что у него на 2 компах лешли веники равносилен варианту что не освместимости железа(так что я бы все равно чекнул).
Если откинуть не фарт, то в сузом остатке вижу только то что надо постараться разобраться что одно и то же в этих установках на разныъ машинах в порядке бреда перечесляю:
1. Плохой образ/флешка с дистром
2. Не верная разметка винта и/или выбор файловых систем
3. ТС нам не скащал что ставит систему на внешний винт который для установки подключал к разным машинам
4. Какое то железо или софт юзаемый ТСом присутвиет на всех машинах и приводит к тормазам
5. ТС не корректо настроил что нить в биосе на всех машинах или проводит не правильную установку систем ждя своего типа биоса(читай не по туториалам)
5. рукикрюки )))))
з.ы.
Блин не уклаыдывается у мнея в голове разные дистры, разные машины/железо баг один
Объясните, пожалуйста, кто в курсе - почему при копировании больших объемов информации так тормозит вся система? Файловая система - ext3. Причем тормозит так, что ничего не возможно сделать параллельно, даже мышь подвисает иногда. Причем такая беда начиная с 8.04. Если дело в файловой системе, то можно ли как-то её поменять безболезненно?
А точно копирование происходит с etx3 на ext3? У мне такая история случается, когда имел дело с системой ntfs. И связанно это дело с сильной фрагментацией нтфс диска.
В том то и дело, что не только на ntfs, но и когда на ext3 копирую. То есть например когда торрент на всю катушку работает - тоже ничего параллельно не сделаешь. И так практически любое действие, связанное с обращением к жесткому диску - UbuntuOne например когда сканирует и т.д. Причем в винде нет такого.
Клик!
Клик!
В бубунте эта проблема по видимому не редкость
Да, почитал, но там тоже все только жалуются на похожие проблемы. А что это такое, как лечить - никто видимо не знает. Хотя большинство склоняется к тому, что это баг ядра :(
Попробуйте ядро обновить!))
Уже с 2007 года (а может быть и раньше), как я посмотрел, такая проблема. Не думаю, что люди с тех пор ни разу не обновляли ядро - тем не менее проблема актуальна до сих пор. И не только кстати на убунте - SuSe, например, тоже страдает этим.
Попробуйте другой дистрибутив, если будут такие-же проблемы то может чег с железом.
Пробовал Мандриву, Убунту, ASP-Linux - не очень понравились. А в Кубунту с первого раза взгляда влюбился :) И до сих пор все устраивает - кроме этого жуткого бага. Как прочитал на каком-то форуме - "при обращении к жесткому диску система становится однозадачной :)"
Debian ZenWalk MEPIS .
Попробуйте серьезные дисрибутивы. хватит с десктопными играться)
P.S. Прошу не обижаться других участников форума
есть предположение, что, возможно, какой-то специфический контроллер IDE или SATA на мамке. Попробуй поковырять сайт производителя на предмет линуховых дров. Иногда такое бывает.
Поковырял, но ничего не нашел, кроме JMicron JMB363 RAID Driver for Linux от ASUS (правда, последнее обновление оного в мае 2007), но, по-моему это не то.
Мамка ASUS P-5K, винт Seagate Barracuda 7200 ST3320620AS SATA.
включен ли режим DMA? если да то какой?
Вот вывод sudo hdparm -i /dev/sda
/dev/sda:
Model=ST3320620AS , FwRev=3.AAK , SerialNo= 6QF1XWQE
Config=< HardSect NotMFM HdSw>15uSec Fixed DTR>10Mbs RotSpdTol>.5% >
RawCHS=16383/16/63, TrkSize=0, SectSize=0, ECCbytes=4
BuffType=unknown, BuffSize=16384kB, MaxMultSect=16, MultSect=?16?
CurCHS=16383/16/63, CurSects=16514064, LBA=yes, LBAsects=625142448
IORDY=on/off, tPIO=, tDMA=
PIO modes: pio0 pio1 pio2 pio3 pio4
DMA modes: mdma0 mdma1 mdma2
UDMA modes: udma0 udma1 udma2 udma3 udma4 udma5 *udma6
AdvancedPM=no WriteCache=enabled
Drive conforms to: Unspecified: ATA/ATAPI-1,2,3,4,5,6,7
* signifies the current active mode
Я так понял - udma6
И что прописано в fstab
посмотри man hdparm
на каком разделе стоит Linux и какие разделы на винте
Ну дык в fstab же написано :)
/dev/sda3 - корневой раздел
/dev/sda1 - /home
/dev/sda4 - swap
/dev/sda2 - винда, нтфс
я просто отвлёкся. Ну и последний вопрос какой чипсет на матери
В BIOSе переставь винт в режим achi
но после этого скорее всего не запустится windows предётся переустанавливать т.к. к дрова при установке не сконфигурированы
Читайте также: