Если вам нужно улучшить скорость для соединений sshfs, попробуйте следующие варианты:

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

команда будет:

sshfs remote:/path/to/folder local -oauto_cache,reconnect,defer_permissions

Помимо уже предложенных решений по использованию Samba / NFS, которые являются абсолютно действительными, вы также можете добиться некоторого повышения скорости, придерживаясь sshfs с использованием более быстрого шифрования (аутентификация будет как обычно безопасной, но сами передаваемые данные будет легче расшифровать), предоставляя -o Ciphers=arcfour возможность sshfs , Это особенно полезно, если ваша машина имеет слабый процессор.

У меня нет никаких альтернатив, чтобы рекомендовать, но я могу дать предложения о том, как ускорить sshfs:

sshfs -o cache_timeout=115200 -o attr_timeout=115200 ...

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

sshfs имитирует удаление и изменения локально, поэтому новые изменения, сделанные на локальном компьютере, должны появиться немедленно, несмотря на большие тайм-ауты, поскольку кэшированные данные автоматически удаляются.

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

Вот еще несколько вариантов, с которыми я экспериментировал, хотя я не уверен, что какой-то из них имел значение:

sshfs_opts="-o auto_cache -o cache_timeout=115200 -o attr_timeout=115200   \
-o entry_timeout=1200 -o max_readahead=90000 -o large_read -o big_writes   \
-o no_remote_lock"

Вам также следует проверить варианты, рекомендованные Митаем в его ответе.

Рекурсия

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

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

Предварительное кэширование

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

Мы можем заставить sshfs выполнять некоторое кэширование с опережением чтения, выполнив это до того, как вы начнете выполнять свою задачу, или даже в фоновом режиме, когда ваша задача уже выполняется:

find project/folder/on/mounted/fs > /dev/null &

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

Но это find займет много времени. Как и другие приложения, он ожидает результатов из одной папки, а затем запрашивает следующую.

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

find project/folder/on/mounted/fs/A > /dev/null &
find project/folder/on/mounted/fs/B > /dev/null &
find project/folder/on/mounted/fs/C > /dev/null &

Если вы также хотите предварительно кэшировать содержимое файла, вы можете попробовать это:

tar c project/folder/on/mounted/fs > /dev/null &

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

Я обнаружил, что отключение моей темы zsh, которая проверяет состояние файла git, очень помогло - просто вход в каталог занимал более 10 минут. Аналогично отключение контроллеров состояния git в Vim.

После поиска и проб. Я только что нашел добавить -o Compression=no Скорость это много. Задержка может быть вызвана процессом сжатия и распаковки. Кроме того, использование 'Ciphers = aes128-ctr' кажется более быстрым, чем другие, в то время как некоторые посты провели некоторые эксперименты на этом. Тогда моя команда как-то так:

sshfs -o allow_other, transform_symlinks, follow_symlinks, IdentityFile = / Users / maple / .ssh / id_rsa -o auto_cache, переподключиться, defer_permissions -o Ciphers = aes128-ctr -o Сжатие = нет maple@123.123.123.123: / home / maple ~ / mntpoint

SSHFS действительно медленный, потому что он передает содержимое файла, даже если это не требуется (при выполнении cp). Я сообщил об этом в апстрим и в Debian, но не получил ответа:/

Я тестировал различные инструменты MacOS 12.1 на Mac M1 и хотел поделиться некоторыми, возможно, полезными результатами.

Краткая версия: попробуйте использовать mount вместо sshfs. Это позволило мне получить полную гигабитную скорость как вверх, так и вниз.

Еще немного о моем опыте и тестировании:

Настройка: M1 Mac подключен через гигабитный Ethernet к серверу под управлением Rocky 8 с большой высокоскоростной файловой системой RAID. Нижеуказанные скорости будут указаны в МБ/с, поэтому скорость проводного соединения составит около 125 МБ/с (1 Гбит/с).

В моем случае настройки sshfs по умолчанию дали мне ~30 МБ/с с сервера и полные 120 МБ/с. Использование опции -o Ciphers=aes128-ctrувеличил скорость примерно до 50 МБ/с (arcfour больше не поддерживается при открытом SSH, поэтому не работало).

Используя rclonerclone mount, я смог получить полные 120+ МБ/с как вверх, так и вниз, и в остальном монтирование также работало отлично.

Большинство других инструментов, не связанных с монтированием, которые я пробовал, давали мне примерно полную скорость провода вверх и вниз (Forklift, sftp командной строки, filezilla, rclone copy, rsync).

Cyberduck дал мне очень низкую производительность вверх и вниз, ~15 МБ/с, подозреваю из-за сжатия, которое я так и не смог придумать, как отключить.

NFS должен быть быстрее. Насколько удалена файловая система? Если это через WAN, вам лучше синхронизировать файлы туда-сюда, а не прямой удаленный доступ.

Новая опция: max_conns

Начиная с версии 3.7.0 sshfs включает опцию под названиемmax_conns.

Эта опция может значительно улучшить вашу производительность.

Проверьте версию sshfs с помощью следующей команды:

      sshfs -V

Если ваша версия >= 3.7.0, рассмотрите возможность добавления следующих параметров:

      -o max_conns=4

Где 4 — количество ядер на вашем компьютере (вы можете проверить это с помощью команды ниже):

      # To retrieve the number of cores:
grep -c ^processor /proc/cpuinfo

ПРИМЕЧАНИЕ

Это может повлиять на загрузку ЦП, используемую ssh/sshfs. Если вы не хотите перегружать процессор при доступе к диску, рассмотрите возможность использования меньшего количества подключений.

Либо NFS, либо Samba, если у вас большие файлы. Использование NFS с чем-то вроде 720p фильмов и дерьма действительно PITA. Samba будет работать лучше, хотя Samba мне не нравится по ряду других причин, и я обычно не рекомендую ее.

Для небольших файлов хорошо подойдет NFS.

Ответ @meetai.com был для меня настоящим волшебством...

Я сейчас использую Linux mint cinnamon 20.0... просто чтобы добавить к ответу, вот небольшой скрипт, к которому я подключил решение Metai - список хостов в файле конфигурации, из которого можно выбрать - мои два цента.

      #!/bin/bash

# list hosts segregating aliases from user's ssh config file
hosts="$(grep -P "^Host ([^*]+)$" $HOME/.ssh/config | sed 's/Host //')"

# select host from list
select host in ${hosts}; do echo "You selected ${host}"; break; done

# call sshfs to mount host
sshfs $host:/ ~/mnt/$host -oauto_cache,reconnect,no_readahead

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

Чтобы выяснить, что происходит, вы можете смонтировать с помощьюsshfs -dкоторый будет спавнитьсяsshfsна переднем плане, но затем будет отображаться отладочная информация, чтобы вы могли видеть, какие запросы выполняются к удаленному хосту. Это поможет вам понять, что происходит, и увидеть, должен ли вообще происходить какой-либо ввод-вывод.

Это не имеет отношения к вопросу, но вот в чем конкретно заключалась моя проблема: выполнение простого задания занимало 8 секунд. Используя режим отладки, я обнаружил, что во времяlsкоманды были запросы типа/libselinux.so.1и/libpcre.so.3и т. д. Для меня это не имело смысла. Потом я понял, что мойLD_LIBRARY_PATHпеременная содержала завершающий символ:, поэтому по сути он содержал пустую запись, что заставляло его искать общие библиотеки через SSHFS.

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

Я описываю тривиальное использование здесь: https://www.quora.com/How-can-I-use-SFTP-without-the-overhead-of-SSH-I-want-a-fast-and-flexible-file-server-but-I-dont-need-encryption-or-authentication

Войдите в систему как root.

Получите доступ к каталогу верхнего уровня, используя "cd /".

Затем убедитесь, что у вас есть созданная папка монтирования или создайте ее с помощью "mkdir folder_name".

После этого просто используйте "mount xxxx: / remote_mount_directory / local_mount_directory".

если все сработало на вашем конце, до этого у вас должно быть успешное монтирование. Вы можете проверить и убедиться, что каталог назначения является общим, используя команду "exportfs", чтобы гарантировать, что они могут быть найдены.

Надеюсь это поможет. Это не из среды lvie, оно было протестировано в локальной сети с использованием VMware и Fedora 16.