Производительность scp в сети 1 Гбит/с
Сperl:
printf '%s' "$SUB_STRING" |
perl -l -0777 -ne '
BEGIN{$sub = <STDIN>}
@matches = m/\Q$sub\E/g;
print scalar @matches' <(printf '%s' "$STRING")
Только с bashвсегда можно сделать что-то вроде:
s=${STRING//"$SUB_STRING"}
echo "$(((${#STRING} - ${#s}) / ${#SUB_STRING}))"
То есть $sсодержит $STRINGсо всеми удаленными вхождениями $SUB_STRINGвнутри него. Мы находим количество $SUB_STRING, которые были удалены, вычисляя разницу в количестве символов между $STRINGи $sи деля на длину самого $SUB_STRING.
POSIXly вы могли бы сделать что-то вроде:
s=$STRING count=0
until
t=${s#*"$SUB_STRING"}
[ "$t" = "$s" ]
do
count=$((count + 1))
s=$t
done
echo "$count"
38 МБ/с соответствует 304 Мбит/с, что является довольно хорошей скоростью передачи данных по каналу 1 Гбит/с,
-Несколько факторов влияют на снижение скорости передачи:
1 -пропускная способность самого сервера.
2 -Производительность ввода/вывода на сервере [используйте #iostat -xm 1], чтобы проверить, используется ли какой-либо из дисков >90% при операциях чтения/записи.
3 -Промежуточное устройство L2 может вызвать такое замедление [попробуйте прямое соединение, чтобы избежать этого].
В дополнение к другим ответам:
- убедитесь, что все ваши проводные соединения являются полнодуплексными (от первой машины до конечной машины ),
- и убедитесь, что никто другой не использует канал 1gps, кроме :вашего scp, пакетов согласования и возврата (acks и т. д.)
- и что шифрование, которое вы используете для scp, не перегружает возможности ЦП .
- что у вас большие окна tcp (и все остальное, что могут обрабатывать ваши переходы ), чтобы разрешить больше пакетов данных и меньше служебных пакетов tcp
- вы можете попробовать выполнить сжатие на лету, если файл еще не сжат и, опять же, он не перегружает процессоры
Если все полностью в вашу пользу, вы должны приблизиться к 70 -80% от 1 Гбит/с (, т.е. 80% от 1024 мегабит в секунду, т.е. 0,8 *1024/8 мегабайт в секунду ), но это может быть в ущерб другим типам подключений (малые размеры пакетов или потребность в большей чувствительности и меньшей задержке)
Наконец, никогда не стоит недооценивать пропускную способность переноса USB-ключа (или проезда )по... (пешком, что также является бонусом к здоровью )
.What is a normal scp transfer speed on 1Gbit LANs?
112 МБ/с
Как и во всплывающем окне Microsoft Windows или scpв Linux, скорость копирования указывается в МБ (мегабайтах )в секунду. Не путайте это со скоростью сети , которая указывается в битах в секунду. С этого момента давайте стандартизируем, что о скорости копирования следует говорить в байтах в секунду (МБ/с ), а не в битах в секунду (Мбит/с)
Обоснование:
- 1 Гбит в секунду = 1000 мегабит (Мбит/с )в секунду; это заявленная скорость сети.
- 1000 Мбит/с / 8 = 125 МБ/с (байт в секунду ), что является ожидаемым теоретическим максимальным значением.
- Я наблюдаю твердые 112 МБ/с (и никогда не видел больше )в проводной сети со скоростью 1 Гбит/с; который рассчитывает эффективность 89,6% и кажется разумным.
- это для
scpв linux, от linux к системе linux - это также для общего ресурса samba из linux, который также получает твердые 112 МБ/с, о которых сообщает всплывающее окно копирования в Microsoft Windows
- Я наблюдал это в течение последних 10 лет с Windows 7 и более поздних версий, теперь используя RHEL/CentOS 7.x, в проводной сети 1 Гбит/с на работе (корпоративные коммутаторы cisco ), где, несомненно, есть другой трафик на сеть и компьютеры, на которые я делаю передачу. А также 4-портовый проводной коммутатор Tigerdirect за 10 долларов.
- это для
- Я не думаю, что SSH приводит к чрезмерным накладным расходам, потому что те же ~10% потери (со 125 МБ/с до 112 МБ/с )также наблюдаются при переходе из Windows в Linux через Samba. По моему скромному мнению, эти ~10%-ные потери (со 125 МБ/с до 112 МБ/с )являются накладными расходами TCP/IP.Я никогда не видел лучше, чем 112 МБ/сек.
- В начале передачи я иногда вижу скорость до 115 МБ/с, и она может немного колебаться между 110 -115, но почти всегда усредняется и устанавливается на 112 МБ/с.
- Эта устойчивая скорость передачи 112 МБ/с между Windows и Linux через Samba, а также
scpмежду Linux и Linux может происходить, даже если обе системы обрабатывают (, например, выполняя работу с реальными числами с верхним отображением 60 ядер на 100% на 64-ядерном сервере ). - примечание :до запуска rhel 7.x, когда я был специалистом по SLES 11.4, я постоянно наблюдал
scpиз ~80 МБ/с, и я так и не узнал, почему, однако мой SLES 11.4 для окон превысил Самба по-прежнему делала 112 МБ/сек.
Также не забывайте кэширование диска . Например, если ваш сервер имеет 128 ГБ ОЗУ, а ваш компьютер с Win10 имеет 32 ГБ ОЗУ, и вы только что 7 -заархивировали один файл размером 10 ГБ, этот один файл tar размером 10 ГБ может находиться в ОЗУ, а не (еще )на диске. Таким образом, скорость передачи копий в этом случае не будет сдерживаться дисковым вводом-выводом до тех пор, пока у вас не закончится оперативная память по сравнению с размером копируемого файла, и дисковое кэширование не будет поддерживаться, и в этот момент вы наблюдайте, как постоянная скорость копирования 112 МБ/с падает до некоторой более низкой скорости (, особенно при использовании вращающихся дисков по сравнению с твердотельными накопителями )из-за дискового ввода-вывода. А также некоторые другие вещи, независимые от проводной сети со скоростью 1 Гбит/с и связанного с ней сетевого оборудования, могут снизить скорость передачи данных до 112 МБ/с.
for comparison, the 112 MB/sec I am claiming is 896 Mb/sec.
Стоит отметить, :огромным убийцей скорости передачи, которая может снизить ее со 112 МБ/с до килобайт в секунду, является копирование папки с множеством подпапок и [небольших] файлов, поэтому никогда не делайте этого, если вам нужна скорость передачи. В таком случае лучше всего сначала tar или iso собрать все это в один файл, каким бы большим он ни был.и передать только это одно и извлечь его в место назначения.
