Существует ли более быстрая альтернатива cp для копирования больших файлов (~ 20 ГБ)?

Я аспирант, и группа, в которой я работаю, поддерживает кластер Linux. Каждый узел кластера имеет свой собственный локальный диск, но эти локальные диски относительно малы и не имеют автоматического резервного копирования. Таким образом, группа владеет файловым сервером со многими ТБ дискового пространства. Я новичок в Linux, поэтому я не уверен, каковы характеристики файлового сервера с точки зрения скорости, сетевых возможностей и т. Д. Из опыта я знаю, что локальные диски значительно быстрее файлового сервера с точки зрения ввода-вывода , Около дюжины или около того людей используют файловый сервер.

Использование cpдля копирования файла размером ~ 20 ГБ с файлового сервера на один из локальных дисков в среднем занимает около 11,5 минут в реальном времени (согласно time). Я знаю, что эта cpоперация не очень эффективна, потому что (1) timeговорит мне, что системное время для такой копии составляет всего ~ 45 секунд; и потому (2), когда я проверяю topво время копирования, % CPU довольно низок (по осмотру, в среднем примерно 0-10% ).

Использование cpдля копирования одного и того же файла размером ~ 20 ГБ из одной папки на локальном диске в другую папку на том же локальном диске занимает меньше времени - около 9 минут в режиме реального времени (согласно системному времени ~ 51 секунда time). Таким образом, очевидно, что файловый сервер несколько медленнее, чем локальный диск, как и ожидалось, но, возможно, не значительно медленнее. Я удивлен, что копирование с локального на одно локальное происходит не быстрее, чем за 9 минут.

Мне нужно скопировать ~ 200 больших файлов - каждый ~ 20 ГБ - с файлового сервера на один из локальных дисков. Итак, мой вопрос: есть ли более быстрая альтернатива cpкопированию больших файлов в Linux? (Или есть какие-нибудь флаги, cpкоторые я мог бы использовать, которые бы ускорили копирование?) Даже если бы я мог как-то сэкономить минуту на этом времени копирования, это очень помогло бы.

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

% CPU должен быть низким во время копирования. Процессор сообщает контроллеру диска «захватить данные из секторов X – Y в буфер памяти в точке Z». Затем он идет и делает что-то еще (или спит, если больше ничего нет). Аппаратное обеспечение вызывает прерывание, когда данные находятся в памяти. Затем процессор должен скопировать его несколько раз и сообщить сетевой карте «передать пакеты в ячейки памяти A, B и C». Тогда это возвращается к занятию чем-то другим.

Вы нажимаете ~ 240 Мбит / с. В гигабитной локальной сети вы должны иметь возможность работать со скоростью не менее 800 Мбит / с, но:

1. Это используется всеми, кто использует файловый сервер (и, возможно, соединение между коммутаторами и т. Д.)
2. Это ограничено скоростью, с которой файловый сервер может обрабатывать запись, учитывая, что пропускная способность дискового ввода-вывода распределяется между всеми, кто его использует.
3. Вы не указали способ доступа к файловому серверу (NFS, CIFS (Samba), AFS и т. Д.). Возможно, вам придется настроить ваше сетевое монтирование, но в любом более позднем периоде настройки по умолчанию обычно довольно нормальные.

Для выявления узкого места iostat -kx 10будет полезна команда. Он покажет вам использование ваших локальных жестких дисков. Если вы можете запустить это на файловом сервере, он скажет вам, насколько занят файловый сервер.

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

• Если файлы сжимаемы, и у вас быстрый ЦП, минимальное сжатие на лету может быть быстрее. Что-то вроде lzopили, может быть gzip --fastest.
• Если вы меняете только несколько бит здесь и там, а затем отправляете файл обратно, только отправка дельт будет намного быстрее. К сожалению, здесь rsyncэто не поможет, так как нужно будет найти файл с обеих сторон, чтобы найти дельту. Вместо этого вам нужно что-то, что отслеживает дельту при изменении файла ... Большинство подходов здесь зависят от приложения. Но возможно, что вы могли бы что-то настроить, например, device-mapper (см. Совершенно новую цель dm-era ) или btrfs.
• Если вы копируете одни и те же данные на несколько машин, вы можете использовать что-то вроде udpcast, чтобы отправить их на все машины одновременно.

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

Возможно, это более быстрая альтернатива, и вы не будете засорять сеть в течение двух дней: возьмите один или два больших диска USB (USB 3, если он есть) или FireWire, подключите их к серверу и скопируйте файлы на диск. Перенеси диск на свой локальный компьютер. Скопируйте файлы на машину.

Ваше определение эффективной обратной. Более эффективная реализация тратит меньше времени на процессор. В локальной копии вы используете в среднем около 74 МБ / с пропускной способности (чтение + запись), что примерно так же, как и для одного жесткого диска.

Если у вас есть прямой доступ по SSH (или SFTP) (спросите своего системного администратора), вы можете использовать scpс компрессией ( -C):

scp -C you@server:/path/to/yourfile .

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

cpРеализация, скорее всего , не является узким местом. Попробуйте наблюдать за использованием ввода-вывода iotopкак на сервере, так и на узле кластера. Это даст вам представление о том, где вы можете улучшить производительность.

Другой совет - избегать копирования одних и тех же данных с одного хоста. Например, если у вас есть идентичный файл 20G для распространения с файлового сервера по сети на все узлы кластера, он будет работать намного быстрее, если вы копируете файлы одноранговым способом, а не как один сервер для всех клиентов. Это немного сложнее в реализации, но вы даже можете попробовать использовать некоторую командную строку p2p, такую ​​как хаб прямого подключения.

Если в этих файлах 20G какая-то часть является общей, а некоторые - специфичной для узла кластера, рассмотрите возможность разделения ее на общую и определенную части, а затем распределяйте общую часть способом p2p.

Характер / содержание этих файлов может иметь некоторое значение. Я понял, что вам нужно скопировать 200 файлов, ~ 20 ГБ каждый, с одного компьютера на другой, не так ли?

Если эти файлы сжимаются или имеют схожие / идентичные части, у вас есть два подхода:

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

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

редактировать

Вам нужно будет копировать эти файлы много раз? (например, копия -> использовать эти файлы -> изменить что-то в файлах на компьютере A -> снова скопировать файлы на компьютер B)

Если это так, rsync будет полезен, потому что он попытается определить, что является равным среди версий, и не копировать то, что не изменилось.

И третий способ: если вышеприведенное верно (изменения в файле, затем скопируйте все файлы снова на второй компьютер), вы можете попробовать некоторые binary diffпросто изменить на втором компьютере то, что было изменено на первом компьютере.

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

Если вы копируете между двумя системами, узким местом, конечно, является соединение между серверами.

Если вы копируете локально, посмотрите, как идет процесс, он однопоточный, поэтому стандартные утилиты Linux используют:

- for all blocks in a file
      read a block
      write a block

В этой операции НЕТ параллелизма.

Чтобы ускорить процесс, вы можете использовать что-то вроде этого:

  buffer -i infile -o outfile -m size-of-shared-memory-default-1MByte

Для получения дополнительной информации см. Справочную страницу buffer (1).

Команда buffer устанавливает два процесса для одновременного запуска процесса копирования: один для чтения, другой для записи, и использует буфер общей памяти для обмена данными между двумя процессами. Буфер разделяемой памяти - это ваш классический кольцевой буфер, который предотвращает перезапись неписанных данных и запись уже записанных данных. Я использовал эту программу, чтобы сократить около 10-20% времени копирования при переносе с диска на ленту.

Почему бы не попробовать алгоритм распространения P2P, если вам нужно обновить весь кластер одновременно?

https://github.com/lg/murder - это то, что использует твиттер

Есть BTSync, который вы тоже можете попробовать.

Если вы часто копируете одни и те же наборы файлов со своего локального компьютера на сервер с небольшими изменениями здесь и там. Вы можете ускорить передачу, используя rsync или DVCS (например, hg или git).

git или hg могут отслеживать и обнаруживать дельты и передавать только эти дельты. В случае использования git, поскольку обе стороны имеют полную историю хранилища, вычисление дельты очень дешево.

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

Возможно, вы захотите попробовать упаковать все файлы в один архив (не нужно сжимать). По моему опыту, копирование этого архива происходит быстрее, чем копирование большого количества отдельных файлов.

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

Убедитесь, что целевые файлы не существуют перед копированием.

Иногда удивительно, сколько времени уходит даже на копирование на один и тот же хост (без участия сети).

Смотрите мой ответ на другой вопрос cp здесь . Короче говоря, перезаписать существующий файл гораздо медленнее, чем его обрезать или сначала отсоединить, а затем копировать. Последний в 8 раз быстрее для файла объемом 1,2 ГБ.