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

Есть ли какой-нибудь более быстрый способ монтировать удаленную файловую систему локально? Мой приоритет номер один — это скорость.

Удаленная машина — Fedora 15, локальная машина — Ubuntu 10.10. Также могу использовать Windows XP локально, если необходимо.

sshfs использует протокол передачи файлов SSH, что означает шифрование.

Если просто монтировать через NFS, это, конечно, быстрее, потому что без шифрования.

Вы пытаетесь монтировать тома в одной сети? Тогда используйте NFS.

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

oauto_cache,reconnect,defer_permissions,noappledouble,nolocalcaches,no_readahead

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

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

Помимо уже предложенных решений с использованием Samba/NFS, которые вполне приемлемы, вы можете также добиться некоторого увеличения скорости, используя более быстрое шифрование (аутентификация будет такой же безопасной, но передаваемые данные будет легче расшифровать) посредством добавления параметра -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"

Вы также можете ознакомиться с опциями, рекомендованными Meetai, в его ответе.

Рекурсия

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

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

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

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

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

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

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

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

Возможно, можно сократить общее время, запросив несколько процессов 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,reconnect,defer_permissions -o Ciphers=aes128-ctr -o Compression=no [email protected]:/home/maple ~/mntpoint

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

sshfs -V

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

-o max_conns=4

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

# Чтобы узнать количество ядер:
grep -c ^processor /proc/cpuinfo

ПРИМЕЧАНИЕ

Это может повлиять на загрузку процессора, используемую ssh / 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

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

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

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

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

Я сейчас на Linux Mint Cinnamon 20.0… просто чтобы дополнить ответ, вот маленький скрипт, который я взял из решения meetai — список хостов в файле конфигурации, где можно выбрать — мои два цента.

#!/bin/bash

# список хостов, разделяющий псевдонимы из файла конфигурации пользователя SSH
hosts="$(grep -P "^Host ([^*]+)$" $HOME/.ssh/config | sed 's/Host //')"

# выбор хоста из списка
select host in ${hosts}; do echo "Вы выбрали ${host}"; break; done

# вызов sshfs для монтирования хоста
sshfs $host:/ ~/mnt/$host -oauto_cache,reconnect,no_readahead

Мой SSHFS внезапно стал очень медленным в полдень. Я испробовал почти все невидимые на различных страницах приемы из интернета. Ничто не решило мою проблему. После 12 часов попыток исправить проблему, я пошел и подкорректировал некоторые настройки на сервере, увеличил почти все параметры, такие как настройки Apache, настройки соединения, немного увеличил все, и, методом проб и ошибок, он снова заработал нормально. Похоже, что высокое количество запросов и неправильные настройки (установлены для легкого сервера) для высоконагруженного сервера вызывали медленную работу файлового сервера и передачу данных. Я рекомендую вам пересмотреть настройки на обоих серверах, и если нужно что-то изменить для лучшего результата, то вы можете попробовать и увеличить эти пределы (Возможно, вам просто нужно больше памяти или рабочих процессов). Сервер может нормально работать какое-то время, но когда вы получаете большой трафик, все может стать более напряженным там.