Що може спричинити повільний ssh ​​сеанс? [зачинено]

Я ssh на віддаленому хості, але продуктивність терміналу погана. Символи, які я набираю, не відображаються відразу, але з деякою затримкою. Іноді два символи відображаються одночасно після затримки.

Висока затримка - ще одна причина низької продуктивності ssh. Я настійно рекомендую використовувати mtr як кращу заміну для traceroute. Він повинен бути в змозі дати вам деяке уявлення про те, де можуть виникнути ваші мережеві проблеми.

Вимкнення переадресації X11, якщо він вам не потрібен (ssh -x), і включення стиснення (ssh -C) також може пришвидшити ваш сеанс.

Я можу придумати дві можливі причини:

1. Втрата пакету підключення
2. Високе навантаження на сервер.

Я спробував оцінити продуктивність мережі, невдовзі виявивши, що термінал добре. Що відбулося?

У нас балансування навантаження між двома маршрутизаторами Інтернет-каналів. Іноді він спрямовує мій ssh ​​трафік через wan1, а іноді через wan2. Я припустив, що з одним каналом щось не так. Тому я виміряв продуктивність мережі mtr (чудовий інструмент!) Для двох каналів окремо.

так! wan2 має 21 стрибок зі 110 мс, а у wan1 15 лише 21 мс! wan2 затримка - це проблема.

Використовуйте Compression and CompressionLevel з 9. Це мало би допомогти. Ви можете налаштувати ці параметри в / etc / ssh / ssh_config. Але якщо фактична мережа дуже погана, то ці трюки не принесуть нічого хорошого.

Найбільш очевидною причиною такої поведінки є посилання, що є або насиченими, або кидаючими пакетами. Скільки у вас хмелю від вашої робочої станції до машини, в яку ви перебираєтесь? Чи проаналізували ви сліду, якщо вона застосовується?

Якщо ви використовуєте OpenSSH для довгожирової труби (висока пропускна здатність + висока затримка), переконайтеся, що ви використовуєте принаймні версію 4.7 з обох сторін, оскільки вона містить виправлення, щоб OpenSSH використовував більший розмір вікна tcp.

 * The SSH channel window size has been increased, and both ssh(1)
   sshd(8) now send window updates more aggressively. These improves
   performance on high-BDP (Bandwidth Delay Product) networks.

Це може бути важливо, якщо ви хочете використати з'єднання з його повним потенціалом, оскільки в іншому випадку відправника, можливо, доведеться чекати аків, перш ніж він може продовжити надсилання.

Як уже говорили інші, це може спричинити затримку, втрати вашої мережі, повільний сервер.
Колись ви бачите 2 символи одного типу, оскільки сучасний стек TCP використовує алгоритм під назвою Naggle .

Це також може бути спроба SSH Brute Force, яка пригнічує ваше з'єднання. Кожен раз, коли мій сеанс працює повільно, я перевіряю журнали, і в цілому ряді випадків хтось пробує паролі, як божевільні.

Неправильно налаштований DNS може спричинити це. Після входу в систему сервер відгукнеться чудово, а файли завантажуватимуться та завантажуватись досить швидко, але SSH вхід буде повільним.

Одне на що слід звернути увагу - це просто пам'ять сервера. Я працював на Ubuntu VM з 256 Мб пам'яті, і SSH був дуже млявим. Подвоєння цього до 512Mb вирішило проблему.