Способы оптимизации производительности в трубопроводах по сети (RSH и SSH)

Рассмотрим передачу данных по сети конвейера в унаследованных системах с удаленной оболочкой (RSH), например:

rsh host -l user tar -cf - /home/dir \| compress | uncompress | tar -xvf - 

и это в «современных» системах:

  • Почему этот пароль терпит неудачу в правилах AIX и Solaris
  • Попытка локальных ключей SSH перед агентом
  • Поиск разрешений для файлов, кроме 755
  • HTTP-туннелирование SSH
  • Проблемы с find, xargs и egrep
  • количество сеансов HTTP = количество сеансов TCP?
  •  ssh user@host tar -cf - /home/dir \| gzip | ungzip | tar -xvf - 

    ПРОБЛЕМЫ С ПРОИЗВОДИТЕЛЬНОСТЬЮ:

    Я испытал очень плохую производительность при передаче от AIX 4.3 до AIX 5.3 с использованием RSH. Даже имея незанятые карты (10/100), соединяющие их через переключатель бездействия, я получил производительность около 350 Кбит / с, передавая 5,4 ГБ.

    При запуске этой передачи между AIX 5.3 и Linux, но теперь с использованием SSH и gzip, производительность намного лучше, но никогда не достигает пропускной способности сети (в 1 гигабитной локальной сети я получил в среднем около 400 Мбит / с).

    Существуют ли способы оптимизации производительности сетевого конвейера, возможно, настройка буферов каналов или сетевых блоков / буферов или что?

  • выполнить команду над соединением ssh
  • Использование локальной оболочки на удаленной машине
  • Запустить команду входа ssh без изменения удаленного .bashrc
  • Как я могу заставить KornShell отображать дату и время в подсказке?
  • Группы отличаются от локальных при входе в систему удаленно
  • Флаг -X (пересылка X11) не работает в Windows
  • 2 Solutions collect form web for “Способы оптимизации производительности в трубопроводах по сети (RSH и SSH)”

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

    Я получаю около 45-50 МБ / с с scp (ssh cp) между двумя другими бездействующими серверами, поскольку шифрование / дешифрование на серверах является ограничивающим фактором. Добавьте gzip / ungzip, и вы можете упасть дальше в зависимости от количества доступных ядер.

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

    Проводили ли вы базовый тест скорости, чтобы исключить сжатие и дисковый ввод-вывод?

    Это довольно легко сделать, подключиться с одного из зараженных хостов к другому через ftp и запустить
    put "|dd if=/dev/zero bs=1M count=1000″ /dev/null
    который будет считывать 1GB с / dev / zero с одной стороны и записывать его в / dev / null с другой стороны, что проверяет чистую пропускную способность сети. Это описано более подробно, например, на
    Блог AIXChange: два способа измерения производительности сети

    Для передачи через scp вы можете попытаться уменьшить шифрование с помощью менее требовательного потокового шифрования (RC4) через -o Cipher=arcfour ... в качестве опции для scp.

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

    Linux и Unix - лучшая ОС в мире.