Linux медленно копирует файлы по сети
Обновлено: 02.07.2024
Linux-администратор должен уверенно владеть интерфейсом командной строки, так как на большинстве Linux-серверов не устанавливается графическая оболочка. SSH является наиболее популярным протоколом, который обеспечивает администратору возможность безопасного удаленного управления сервером. Для безопасного копирования файлов между серверами с использованием этого протокола используется команда scp (secure copy – безопасное копирование). В данном руководстве мы рассмотрим основы работы с командой scp и наиболее важные опции.
Базовый синтаксис
Команда scp выглядит следующим образом
Данная команда выполняет копирование указанного файла (имя_файла) в конкретную директорию (директория_назначения) на узле назначения (узел_назначения) с использованием учетной записи определенного пользователя (пользователь).
Подробная информация о процессе копирования
При запуске без параметров команда scp будет копировать файлы в фоновом режиме. Пользователь ничего не видит, пока процесс не будет завершен, или не возникнет какая-либо ошибка. Для вывода подробной информации о процессе копирования на экран можно воспользоваться параметром –v. Это может помочь в отладке проблем соединения, аутентификации и конфигурации.
Сохранение значений атрибутов
Для копирования файлов с сохранением времени доступа, модификации и прав доступа используется опция –p. На экране отобразятся примерное время выполнения и скорость соединения:
Сжатие файлов при передаче
Опция –C поможет ускорить передачу файлов за счет их сжатия. Преимущество такой передачи в том, что сжатие будет выполняться только для передачи по сети. При завершении копирования на сервере места назначения размер файла вернется к первоначальному, каким он был до сжатия.
Допустим, требуется скопировать файл размером 1 ГБ. Следующая команда выполнит это без сжатия:
Время копирования составило 20.3 секунды. Теперь выполним копирование с параметром –C:
Видно, что при использовании сжатия процесс передачи требует всего 3,4 секунды. Это более чем в 6 раз быстрее. Однако, важно отметить, что сжатие работает не для всех файлов. При копировании уже сжатых файлов никакого ускорения не будет, поэтому на архивы, изображения и файлы образов этот параметр не действует.
Выбор алгоритма шифрования
По умолчанию scp использует для шифрования файлов алгоритм AES-128. Если требуется другой алгоритм, его можно изменить при помощи опции -c:
В данном случае задан алгоритм 3DES. Обратите внимание, что данный параметр указывается маленькой буквой -с, а не большой -C.
Ограничение скорости передачи
Опция -l ограничивает скорость передачи, указывается в кбит/c. Она полезна для использования в скриптах для автоматического копирования большого количества файлов, чтобы процесс scp не занимал весь канал.
После параметра указывается значение ограничения скорости в килобитах в секунду, а при передаче скорость отображается в килобайтах в секунду. В данном случае мы указали 400 кбит/с, что эквивалентно 50 кбайт/с, так как в одном байте 8 бит (400/8 = 50).
Выбор порта для scp
Обычно scp по умолчанию использует порт 22, но в целях безопасности может потребоваться его изменить. Для этого применяется опция -P. Например, если мы используем порт 2249:
Убедитесь, что буква заглавная, так как строчная p используется для сохранения атрибутов.
Рекурсивное копирование каталогов
Если требуется копирование директории со всеми поддиректориями и файлами внутри, лучше сделать это одной командой. В scp для этого используется параметр -r:
scp -r /root/documents root@10.10.10.2:.
После завершения процесса копирования на сервере места назначения появится директория documents со всеми файлами, которая будет создана автоматически.
После ввода пароля не отображается никакой информации о работе команды. После завершения процесса копирования вы снова увидите командную строку.
Копирование файлов через прокси
В офисных сетях часто используются прокси-серверы. Изначально scp не настроена для работы через прокси, поэтому если вы используете прокси-сервер, нужно «сообщить» об этом команде. Для работы протокола SSH через прокси-сервер требуется туннелирование, которое осуществляется при помощи специальной программы Corkscrew. В вашей системе она может быть не установлена, в этом случае нужно воспользоваться стандартной процедурой установки:
Допустим, адрес вашего прокси-сервера 10.0.96.6, а порт 8080, и на сервере требуется аутентификация пользователя. Нужно создать файл
/.ssh/config и прописать там следующую команду:
Затем нужно создать файл
/.ssh/proxyauth, содержащий имя пользователя и пароль для аутентификации на прокси-сервере в следующем формате:
Теперь можно использовать scp в прозрачном режиме, как обычно. Необходимо исключить доступ посторонних лиц к файлу
/.ssh/proxyauth, потому что в нем открытым текстом указаны имя пользователя и пароль.
Выбор другого файла конфигурации
Мобильным пользователям, которые попеременно используют сеть компании и публичные сети, будет тяжело каждый раз менять настройки scp. Лучше всего создать для этого отдельный файл ssh_config и воспользоваться параметром -F.
По умолчанию файл ssh_config для пользователя находится в
/.ssh/config. Если создать отдельный файл proxy_ssh_config для использования прокси, это упростит переход между сетями.
Например, если в сети компании используется прокси-сервер, а в публичной сети – нет, а пользователь попеременно работает в разных сетях, можно использовать опцию -F с именем нужного файла конфигурации для сети компании, а в публичной сети ее не указывать:
Заключение
Мы рассмотрели наиболее распространенные примеры работы с командой scp. Более подробную информацию можно получить в соответствующих man-страницах.
Если вы нашли ошибку, пожалуйста, выделите фрагмент текста и нажмите Ctrl+Enter.
Уже не помню, когда начились проблемы с производительностью при копировании файлов, но тогда я этому не придал большого значения так, как копировал файлы редко. Относительно недавно в моем распоряжении появилось высокоскоростное подключение к сети Интернет и теперь я часто копирую/качаю большие файлы и проблема падения производительности для меня стала очень актуальной.
Поверхностный гуглеж не дал результатов и я начал копать глубже, оказалось, что проблемы высокой нагрузки 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. Соавтор (теория, оформление) — Ваш покорный слуга.
Ответ 1
Я бы рекомендовал tar. Когда структуры файлов похожи, rsync работает очень хорошо. Однако поскольку rsync выполняет несколько проходов анализа каждого файла, а затем копирует изменения, он намного медленнее tar для начального копирования. Эта команда, скорее всего, сделает то, что вы хотите. Она скопирует файлы между машинами, а также сохранит разрешения и права доступа пользователей/групп.
tar -c /path/to/dir | ssh remote_server 'tar -xvf - -C /absolute/path/to/remotedir'
Вот команда, которую вы будете использовать для rsync:
rsync -avW -e ssh /path/to/dir/ remote_server:/path/to/remotedir
Ответ 2
Ответ 3
Ответ 4
При копировании большого количества файлов я обнаружил, что такие инструменты, как tar и rsync, работают менее эффективн о , чем нужно, из-за накладных расходов на открытие и закрытие множества файлов. Я написал инструмент с открытым исходным кодом под названием fast-archiver, который быстрее tar для таких сценариев; он работает быстрее за счет выполнения нескольких одновременных операций с файлами.
Вот пример сравнения fast-archiver с tar на резервной копии более двух миллионов файлов; fast-archiver выполняет архивацию за 27 минут, а tar — за 1 час 23 минуты.
$ time fast-archiver -c -o /dev/null /db/data
пропуск символической ссылки /db/data/pg_xlog
1008.92user 663.00system 27:38.27elapsed 100%CPU (0avgtext+0avgdata 24352maxresident)k
0inputs+0outputs (0major+1732minor)pagefaults 0swaps
$ time tar -cf - /db/data | cat > /dev/null
tar: Удаление ведущих '/' из имен пользователей
tar: /db/data/base/16408/12445.2: файл изменился при чтении
tar: /db/data/base/16408/12464: файл изменен по мере чтения
32.68user 375.19system 1:23:23elapsed 8%CPU (0avgtext+0avgdata 81744maxresident)k
0inputs+0outputs (0major+5163minor)pagefaults 0swaps
Для передачи файлов между серверами вы можете использовать fast-archiver с помощью ssh, как показано ниже:
ssh postgres@10.32.32.32 "cd /db; fast-archive -c data --exclude=data/\*.pid" | fast-archiver -x
Ответ 5
Ответ 6
Я могу предложить следующее улучшение (если bash — ваша оболочка). Это добавит параллельное сжатие, индикатор выполнения и проверку целостности по сетевому каналу:
tar c file_list |
tee >(sha512sum >&2) |
pv -prab |
pigz -9 |
ssh [user@]remote_host '
gunzip |
tee >(sha512sum >&2) |
tar xC /directory/to/extract/to
'
pv — это хорошая программа просмотра прогресса для ваше го соединения, а pigz — параллельная программа gzip, которая использует столько потоков, сколько есть у вашего процессора по умолчанию (я думаю, до 8 максимум). Вы можете настроить уровень сжатия, чтобы лучше соответствовать соотношению процессора и пропускной способности сети, и поменять его местами с pxz -9e и pxz -d, если у вас намного больше процессоров, чем пропускной способности. Вам нужно только проверить, что две контрольные суммы совпадают после завершения.
Эта опция полезна для очень больших объемов данных, а также для сетей с высокой задержкой, но не очень полезна, если связь нестабильна и падает. В таких случаях лучшим выбором будет rsync, поскольку он может возобновить работу.
Пример вывода:
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e - ]
176MiB [9.36MiB/s] [9.36MiB/s] [ <=> ]
6c1fe5a75cc0280709a794bdfd23d7b8b655f0bbb4c320e59729c5cd952b4b1f84861b52d1eddb601259e78249d3e6618f8a1edbd20b281d6cd15f80c8593c3e -
Для блочных устройств:
dd if=/dev/src_device bs=1024k |
tee >(sha512sum >&2) |
pv -prab |
pigz -9 |
ssh [user@]remote_host '
gunzip |
tee >(sha512sum >&2) |
dd of=/dev/src_device bs=1024k
'
Также убедитесь, что они одинакового размера , или ограничьте их с помощью count=, skip=, seek= и т. д.
Когда я копирую файловые системы таким образом, я часто сначала делаю :
dd if=/dev/zero of=/thefs/zero.dat bs=64k && sync && rm /thefs/zero.dat && umount /thefs
чтобы обнулить большую часть неиспользуемого пространства, что ускоряет перенос.
Ответ 7
Вы не упомянули, находятся ли эти две машины в одной локальной сети, а также является ли канал безопасным, т. е. с использованием SSH, или другим инструментом, который вы можете использовать, например , netcat.
Я бы использовал следующее на принимающей машине:
cd <destdir>
netcat -l -p <port> | gunzip | cpio -i -d -m
Затем на передающей стороне:
cd <srcdir>
find . -type f | cpio -o | gzip -1 | netcat <desthost> <port>.
Это имеет следующие преимущества:
Отсутствие нагрузки на процессор при шифровании, которое есть в ssh.
gzip -1 обеспечивает легкое сжатие без загрузки процессора, так что это хороший компромисс, дающий небольшое сжатие при сохранении максимальной пропускной способности ( в озможно, это не так выгодно для данных MP3). Если вы можете разделить файлы на группы, вы можете запустить два или более каналов параллельно и действительно обеспечить насыщение пропускной способности сети.
Например,
find <dir1> <dir2> -type f | cpio -o | gzip -1 | netcat <desthost> <portone>
find <dir3> <dir4> -type f | cpio -o | gzip -1 | netcat <desthost> <porttwo>
Примечания:
Независимо от способа передачи, я бы, вероятно, запустил rsync или unison после этого, чтобы убедиться, что передача прошла успешно.
Вы можете использовать tar вместо cpio, если хотите.
Даже если вы используете ssh, я бы убедился, что он сам не использует сжатие, и вместо этого передавал бы через gzip -1 самостоятельно, чтобы избежать перегрузки процессора ( и ли, по крайней мере, установите CompressionLevel , равным 1).
Мы будем очень благодарны
если под понравившемся материалом Вы нажмёте одну из кнопок социальных сетей и поделитесь с друзьями.
25 апр 2017, 11:17
Здравствуйте, имею 2 сети, обе они соединены VPN туннелем Kerio, раньше была винда проблем не было) сейчас переходим на linux и появляется куча вопросов
поднял в первой сети linux mint 17 с vsftpd, на нем хранятся личные диски пользователей
во второй сети сидят пользователи тоже с linux mint 17 и у них примонтированы диски сетевые с vsftp servera
Проблема: медленно открытваются файлы, к примеру файл 8,8 мб открывается чуть более 50 секунд, если же к ЭТОМУ ЖЕ ФАЙЛУ на ЭТОМ ЖЕ СЕРВЕРЕ подключиться по smb то файл открывается за 16 секунд.
Кто то сталкивался с таким?
вот мой конфиг vsftpd
Не поверите сменил порт в vsftpd с 21 на 60000 и ура скорость супер по фтп на скачивание.медленная работа vsftpd
25 апр 2017, 11:55
медленная работа vsftpd
25 апр 2017, 15:43
на ftp папку заливаю со скоростью 1-1.5 мб\сека с ftp папки на свой комп со скоростью 200 кб\сек
медленная работа vsftpd
25 апр 2017, 19:26
Никогда не любил FTP, какой-то он никакойДля чисто линуксовой сетки - NFS (или в крайнем случае sftp/sshfs), для гетерогенной - самбу (или на волне прогресса какой-нибудь OwnCloud с webdav'ом)
Впрочем, NFS-клиенты есть и в венде, как гласит их technet .
aarus писал(а): если же к ЭТОМУ ЖЕ ФАЙЛУ на ЭТОМ ЖЕ СЕРВЕРЕ подключиться по smb
медленная работа vsftpd
26 апр 2017, 09:21
И то и другое потому что сеть гетеро, для линукса - ftp, для винды - smb
я бы с радостью пользовался бы тока smb но. по smb папка оч долго открывается у Клиента с Mint, и я не смог решить эту проблему(((
суть такая, 2 сетки, между ними VPN c помощью Kerio, раньше был файловый сервер windows 2008 потом поднял другую машину Mint - разница никакой:
Так вот когда Linux Mint цепляется к файлам сервера(пробовали через fstab и через ФМ NEMO - Файл-Подключиться к серверу - Общий ресурс Windows), папка открывается норм если там немного файлов с папками, а если больше + - 40 штук то открывается с задержкой, к примеру папка которая содержит 50 объектов(файлы + папки) открывается 10 секунд. Клиент Windows в таком же сценарии открывает папки мгновенно.
Если подключаю эту же папку через ftp : через файловый менеджер NEMO: файл-«подключение к серверу» - там выбираю ftp с атвторизацией то папки в ней открываются быстро, почти мгновенно, но скорость скачивания в 5 раз меньше.
Читайте также: