Нам часто требуется передавать огромные файлы (более 50 ГБ) между двумя хостами, и скорость передачи, кажется, никогда не достигает ожидаемой пропускной способности для сети. Есть несколько моментов, которые могут быть узким местом, но каждый их теоретический верхний предел путь над фактической скоростью передачи. Вот типичная установка:
Ноутбук -> 802.11n -> AP -> Кабель CAT 6 -> Маршрутизатор 10/100 Мбит -> Рабочий стол
В этой связи очевидно, что узким местом является маршрутизатор, который ограничит скорость передачи на уровне 100 Мбит / с. Даже тогда я редко вижу скорость передачи (с scp), превышающую 9,5 МБ / с, что составляет 76 Мбит / с, или только 76% от теоретического максимального предела.
Неужели на точке доступа может быть 24% накладных расходов или еще что-то ограничивает скорость? Это может быть дисковый ввод-вывод (хотя SATA рассчитан на 1,5 Гбит / с) или что-нибудь на материнской плате между диском и сетевой картой (как я могу это измерить?).
Есть ли способ точно узнать (*), где находится узкое место? Если я не могу получить более 76 Мбит / с от маршрутизатора на 100 Мбит / с, будет ли при обновлении сети до гигабита пропускная способность увеличиваться или я все равно получу 76 Мбит / с, потому что узкое место где-то еще?
(*) или, по крайней мере, достаточно убедительно, чтобы начальник согласился инвестировать в модернизацию этой части сети.
ваша проблема в том, что вы тестируете слишком много вещей одновременно:
Поскольку вы упомянули SSH, я предполагаю, что это система unix ...
Вы можете исключить проблемы со скоростью чтения с диска простым
dd if=yourfile of=/dev/null #or
pv yourfile > /dev/null
на принимающей стороне вы можете сделать простой тест записи на диск
dd if=/dev/zero of=testfile bs=1M count=2000 # or
dd if=/dev/zero bs=1M count=2000 | pv > testfile
dd на самом деле не является "тестом", но поскольку scp использует последовательный ввод-вывод, он достаточно близок
вы также можете протестировать SSH, выполнив что-то вроде
dd if=/dev/zero bs=1M count=100 | ssh server dd of=/dev/null # or
dd if=/dev/zero bs=1M count=100 | pv | ssh server dd of=/dev/null
наконец, чтобы исключить SSH как узкое место, вы можете использовать nc для проверки производительности сети.
server$ nc -l 1234 > /dev/null
client$ dd if=/dev/zero bs=1M count=100 | pv | nc server 1234 # or
client$ dd if=/dev/zero bs=1M count=100 | nc server 1234
если вы действительно хотите правильно протестировать сеть, установите и используйте что-нибудь вроде iperf, но nc - хорошее начало.
Я бы начал с теста NC, так как он исключит большинство вещей. Вы также должны обязательно запустить тесты, не используя беспроводную связь. 802.11n может легко увеличить порт 100 Мбит / с, но только если он правильно настроен.
(Ubuntu> = 12.04 по умолчанию netcat-openbsd. nc -l -p 1234 > /dev/null может быть тем, что вам нужно, если вы используете традиционный netcat).
Подумайте об этом так;
У вас есть медленный (диски портативных компьютеров медленные) диск SATA с той или иной файловой системой, которая затем превращается в протокол обмена файлами на основе IP, такой как SMB. Затем это превращается в формат Wi-Fi, который затем попадает в AP, который затем переходит через проводной Ethernet (который требует некоторого переформатирования) к довольно медленному коммутатору. Маршрутизатор затем на, вероятно, довольно медленный рабочий стол, разбивает ваш файл системный формат по выбору и, наконец, на диск. Все это происходит для каждого пакета, большинство из которых, если не все, требуют отправки пакета подтверждения, прежде чем он отправит следующий пакет.
Я удивлен, что ты видишь такую скорость!
Вот подсказка: подключите ноутбук к коммутатору / маршрутизатору 100 Мбит / с, когда вам нужно передать файлы - серьезно, это будет намного, намного быстрее. Также подумайте о более быстрых дисках на каждом конце и убедитесь, что вы также используете эффективный механизм передачи файлов.
Надеюсь это поможет.
Как намекает Chopper3, также попробуйте использовать rsync-over-ssh для файлов такого размера, так как есть большая вероятность, что что-то может пойти не так; ничто не отстой, как получить 45 ГБ через передачу 50 ГБ и потерпеть неудачу. Возможно, это также уменьшит ваши накладные расходы, но я лично не тестировал это с такими большими размерами файлов.
При передаче тысяч небольших файлов rsync также может существенно снизить накладные расходы - тест размером 75 КБ файлов / 1500 директорий / 5,6 КБ среднего размера файла, который я запускал однажды, занял 12 минут с FTP и SFTP, 10 минут с SCP, но только 1 минуту 50 секунд с rsync-over-ssh из-за уменьшения накладных расходов на установку / демонтаж. Rsync без SSH был всего на 20 секунд быстрее при 1 минуте 33 секунде.
Вы можете использовать эту команду для измерения скорости чтения ваших дисков:
hdparm -tT /dev/sdX
(замените X буквой диска)
1,5 / 3/6 Гбит / с - это технически скорость передачи данных по sata, но большинство дисков способны только на непрерывное чтение 50-60 Мбит / с.