Przyspieszenie transferu SSH lub rclone w Linux przez zmianę konfiguracji

Załóżmy, że masz wyzwanie przekopiowania plików np. 100GB z jednego serwera Linux na drugi, przez SSH. To jest typowe zadanie dla administratora Linuxa, ale też np. twórcy treści cyrowych, który gromadzi wiele materiałów wideo, które zajmują GB a niekiedy TB dysków!

Problem pojawia się wtedy, gdy transfer zamiast kilku godzin trwa kilkanaście. Często pierwsza myśl to: „słaba sieć”. W praktyce jednak bardzo często wąskim gardłem jest… CPU oraz domyślna konfiguracja SSH.

W tym artykule pokażę, jak znacząco przyspieszyć transfer danych przez SSH oraz rclone, korzystając z prostych, ale skutecznych zmian konfiguracyjnych.

Dlaczego transfer przez SSH jest wolny?

SSH zapewnia bezpieczeństwo dzięki szyfrowaniu, ale ma to swoją cenę:

• szyfrowanie danych (CPU-intensive)
• obliczanie MAC (integrity check)
• narzut protokołu

Na słabszych maszynach (np. ARM, SBC, starsze VPS-y) CPU może stać się głównym ograniczeniem.

Typowe objawy:

• CPU 100%
• transfer 10–30 MB/s mimo szybkiego łącza
• duża różnica między scp/rclone a np. iperf

1. Zmiana cipher (największy boost)

Najważniejsza optymalizacja to wybór odpowiedniego algorytmu szyfrowania.

Najlepszy wybór dla słabszego CPU:

chacha20-poly1305@openssh.com

Jest:

• szybki programowo
• zoptymalizowany dla CPU bez AES-NI

Konfiguracja SSH (globalna lub per-host)

Edytuj:

nano ~/.ssh/config

Dodaj:

Host *
    Ciphers chacha20-poly1305@openssh.com

Lub tylko dla konkretnego serwera:

Host moj-serwer
    HostName 192.168.1.10
    User user
    Ciphers chacha20-poly1305@openssh.com

Weryfikacja

ssh -v user@host

Szukaj:

chacha20-poly1305@openssh.com

2. Wyłączenie kompresji

SSH może używać kompresji, ale dla plików video (mp4, mkv) to tylko spowalnia transfer.

NIE używaj:

ssh -C

W rclone upewnij się, że nie ma wymuszonej kompresji.

3. Optymalizacja rclone

Domyślne ustawienia rclone nie zawsze są optymalne.

Podstawowa komenda

rclone move /src remote:/dst \
  --transfers 2 \
  --checkers 4 \
  --sftp-concurrency 4 \
  -P

Co oznaczają parametry

• --transfers – liczba równoległych plików
• --checkers – liczba operacji sprawdzania
• --sftp-concurrency – równoległe operacje w jednym pliku

Dla dużych plików (video!)

Dodaj:

--multi-thread-streams 4
--multi-thread-cutoff 100M

To pozwala dzielić jeden plik na kilka strumieni.

4. Sprawdzenie rzeczywistej wydajności SSH

Zanim optymalizujesz – zmierz.

dd if=/dev/zero bs=1M count=1000 | ssh user@host "cat > /dev/null"

To pokazuje maksymalny throughput SSH bez dysku.

5. Wąskie gardła systemowe

CPU

Sprawdź:

htop

Jeśli 1 rdzeń = 100% → bottleneck znaleziony

Dysk

Sprawdź:

iotop

Jeśli dysk nie wyrabia, nawet szybka sieć nie pomoże.

Sieć

Test:

iperf3 -c host

6. Problem z przerwanymi plikami (rclone)

rclone przez SFTP:

• nie wznawia transferów
• ignoruje częściowe pliki

Rozwiązanie:

--partial-suffix .partial

Wtedy:

• plik w trakcie: video.mkv.partial
• po zakończeniu: video.mkv

7. Alternatywa: rsync (lepszy do dużych plików)

Jeśli zależy Ci na wznawianiu transferów:

rsync -avP --partial /src/ user@host:/dst/

Zalety:

• resume
• sprawdzanie różnic
• stabilność

8. Ominięcie SSH (największy boost)

Jeśli nie potrzebujesz szyfrowania:

Opcje:

NFS

• bardzo szybki
• niski narzut CPU

rsync daemon

• szybszy niż SSH

SMB

• wygodny w sieci lokalnej

Przykładowe wyniki

Podsumowanie

Najczęściej problemem nie jest sieć, tylko:

• CPU (szyfrowanie)
• zły cipher
• brak optymalizacji rclone

Największe zyski:

1. zmiana cipher na chacha20-poly1305
2. dostosowanie --transfers i --multi-thread
3. unikanie kompresji
4. rozważenie rezygnacji z SSH

Wersja rclone, do której odnoszą się powyższe przykłady:

$ rclone version
rclone v1.73.4
- os/version: debian 13.4
- os/kernel: 6.18.21-current-sunxi (armv7l)
- os/type: linux
- os/arch: arm (ARMv7 compatible)
- go/version: go1.25.9
- go/linking: static
- go/tags: none