Какой самый быстрый способ пересылки большого количества данных между двумя компьютерами? [закрыто]
Биоинформатика кажется забавной. Если вы открыты для решений, отличных от awk, легкая работа для miller :
mlr --itsv join -u -j chrom,pos --lp tr_ --rp untr_ -f treated.bam.tsv untreated.bam.tsv | # join data from treated and untreated files by fields chrom and pos
mlr put '$tr_pct=($tr_mismatches+$tr_deletions+$tr_insertions)/$tr_reads_all' | # calculate pct for treated data
mlr put '$untr_pct=($untr_mismatches+$untr_deletions+$untr_insertions)/$untr_reads_all' | # calculate pct for untreated data
mlr cut -o -f chrom,pos,tr_ref,tr_reads_all,tr_mismatches,tr_deletions,tr_insertions,tr_pct,untr_ref,untr_reads_all,untr_mismatches,untr_deletions,untr_insertions,untr_pct | # remove superfluous fields
mlr --otsv put '$pct_sub=$tr_pct-$untr_pct' # append pct subtraction field
chrom pos tr_ref tr_reads_all tr_mismatches tr_deletions tr_insertions tr_pct untr_ref untr_reads_all untr_mismatches untr_deletions untr_insertions untr_pct pct_sub
chrY 59363551 G 8 0 1 5 0.750000 G 2 0 0 1 0.500000 0.250000
chrY 59363552 G 7 0 0 0 0 G 1 0 0 0 0 0
chrY 59363553 T 7 0 0 0 0 T 1 0 0 0 0 0
chrY 59363554 G 7 0 0 0 0 G 1 0 0 0 0 0
chrY 59363555 T 7 0 0 0 0 T 1 0 0 0 0 0
Это выглядит страшнее, чем есть на самом деле. Действительно.
OK Я попытался ответить на этот вопрос для двух компьютеров с "очень большими каналами" (10Gbe ), которые "близко" расположены друг к другу.
Проблема, с которой вы здесь столкнетесь, заключается в том, что :большая часть сжатия будет узким местом в процессоре, поскольку каналы очень велики.
производительность для передачи файла размером 10 ГБ (сетевое соединение 6 ГБ [linode], несжимаемые данные):
$ time bbcp 10G root@$dest_ip:/dev/null
0m16.5s
iperf:
server: $ iperf3 -s -F /dev/null
client:
$ time iperf3 -c $dest_ip -F 10G -t 20 # -t needs to be greater than time to transfer complete file
0m13.44s
(30% cpu)
netcat (1.187 openbsd):
server: $ nc -l 1234 > /dev/null
client: $ time nc $dest_ip 1234 -q 0 < 10G
0m13.311s
(58% cpu)
scp:
$ time /usr/local/bin/scp 10G root@$dest_ip:/dev/null
1m31.616s
scp with hpn ssh patch (scp -- hpn patch on client only, so not a good test possibly):
1m32.707s
socat:
server:
$ socat -u TCP-LISTEN:9876,reuseaddr OPEN:/dev/null,creat,trunc
client:
$ time socat -u FILE:10G TCP:$dest_ip:9876
0m15.989s
И две коробки по 10 Gbe, чуть более старые версии netcat (CentOs 6.7 ), файл 10GB:
nc: 0m18.706s (100% cpu, v1.84, no -q option
iperf3: 0m10.013s (100% cpu, but can go up to at least 20Gbe with 100% cpu so not sure it matters)
socat: 0m10.293s (88% cpu, possibly maxed out)
Таким образом, в одном экземпляре netcat использовал меньше процессора, в другом — в socat, поэтому YMMV.
При использовании netcat, если у него нет параметра «-N -q 0», он может передавать усеченные файлы, будьте осторожны... другие параметры, такие как «-w 10», также могут привести к обрезанные файлы.
Почти во всех этих случаях происходит перегрузка процессора, а не сети. scpдостигает максимальной скорости около 230 МБ/с, привязывая одно ядро к 100%-ному использованию.
К сожалению, Iperf3 создает поврежденные файлы. Некоторые версии netcat не передают весь файл, что очень странно. Особенно старые его версии.
Различные заклинания «gzip как канал для netcat» или «mbuffer» также, казалось, максимально загружали процессор с помощью gzip или mbuffer, поэтому не приводили к более быстрой передаче с такими большими каналами. lz4 может помочь. Кроме того, некоторые попытки использования gzip pipe привели к повреждению передачи очень больших (> 4 ГБ )файлов, так что будьте осторожны:)
Еще одна вещь, которая может работать, особенно при больших задержках (? )для настройки параметров tcp. Вот руководство, в котором упоминаются рекомендуемые значения:
http://pcbunn.cithep.caltech.edu/bbcp/using_bbcp.htmиhttps://fasterdata.es.net/host-tuning/linux/(из другого ответа )возможно настройки IRQ:https://fasterdata.es.net/host-tuning/100g-tuning/
предложения от linode, добавить в /etc/sysctl.conf:
net.core.rmem_max = 268435456
net.core.wmem_max = 268435456
net.ipv4.tcp_rmem = 4096 87380 134217728
net.ipv4.tcp_wmem = 4096 65536 134217728
net.core.netdev_max_backlog = 250000
net.ipv4.tcp_no_metrics_save = 1
net.core.default_qdisc = fq
Кроме того, они хотели бы, чтобы вы бежали:
/sbin/ifconfig eth0 txqueuelen 10000
Стоит дважды проверить после настройки, чтобы убедиться, что изменения не причиняют вреда.
Также, возможно, стоит настроить размер окна:https://iperf.fr/iperf-doc.php#tuningtcp
Однако при медленных (или )соединениях сжатие определенно может помочь. Если у вас большие конвейеры, очень быстрое сжатие может помочь с легко сжимаемыми данными, но не пробовал.
Стандартным ответом на вопрос «синхронизация жестких дисков» является rsync файлов, который по возможности позволяет избежать передачи.
Другой вариант :использовать "параллельный scp" (так или иначе ), тогда он будет использовать больше ядер...