Коротка відповідь: Йдіть по ланцюгу: (1) тест із паралельними потоками (iperf3 -P 8), щоб виключити ліміти одного TCP-потоку, (2) перевірка навантаження сервера й диска, (3) вимір затримки та втрат через MTR, (4) порівняння різних кінцевих точок, щоб локалізувати повільний сегмент. Більшість випадків «повільної мережі» виявляються фізикою відстані, перевантаженим застосунком або лінією самого клієнта.

Огляд

Пропускна здатність = вікно ÷ RTT: один TCP-потік фізично не може заповнити порт 1G через шлях у 200 мс, якщо вікна не величезні, а втрати не нульові. Додайте вузькі місця диска, CPU steal чи насичений домашній канал — і мережа часто ні до чого. Методичне виключення б’є вгадування.

Що потрібно мати

  • Визначення «повільно» цифрою: очікуване проти виміряного, який напрямок, один файл чи все разом.
  • Готові інструменти тестування на сервері (iperf3, wget) і знання швидкості порту.

Покрокова інструкція

  1. Відтворіть із паралельними потоками: 
    iperf3 -c TARGET -P 8      # якщо -P 8 швидко, а -P 1 повільно => затримка, не ємність
  2. Перевірте, що сервер не вузьке місце: 
    uptime                      # навантаження
iostat -x 2 3               # диск зайнятий? (пакет sysstat)
top                         # CPU steal (st) на завантаженому хості
  3. Виміряйте шлях: mtr -rwc 100 TARGET — високий RTT пояснює ліміти одного потоку; втрати пояснюють зависання (див. втрату пакетів).
  4. Тріангулюйте: тест до/з другої точки в іншій мережі. Повільно всюди = бік сервера; повільно лише з одного провайдера = той шлях/клієнт.
  5. Перевірте рівень застосунку: TLS, PHP, час бази домінують у затримці малих запитів — швидкий порт не пришвидшить бекенд-відповідь у 900 мс.

Типові проблеми

  • Один потік через міжконтинентальний шлях визнано «поламаним»: 100–300 Mbps на потік при 200 мс RTT — очікувано; для далеких користувачів — CDN/паралелізм.
  • Власний аплінк клієнта: офісні 100 Mbps обріжуть будь-який тест до 100 Mbps незалежно від сервера.
  • Тест під час бекапів: нічні задачі з’їдають порт — гляньте vnstat -h, що ще качалося.

Коли звертатися в підтримку

Якщо багатопотокові тести до близьких, добре підключених точок стабільно значно нижчі за швидкість порту, а сервер простоює — надішліть докази: команди, виводи, мітки часу, кінцеві точки.

Часті запитання

Чому одне завантаження повільне, а паралельні швидкі?

Пропускна здатність TCP на потік обмежена розміром вікна та часом обігу. На великих відстанях це фізика — рішенням є CDN і паралельні потоки.

Як виключити сам сервер?

Перевірте навантаження в uptime, насичення диска через iostat і CPU steal у top. Зайнятий сервер передає повільно в будь-якій мережі.

Які докази зібрати перед тикетом?

Результати iperf3 з -P 1 та -P 8, швидкості wget із тестових файлів, MTR в обох напрямках, мітки часу та перелік кінцевих точок, до яких тестували.

Схожі статті

Потрібна допомога? Звернутися в підтримку Cloud2Y →

Ця відповідь Вам допомогла? 0 Користувачі, які знайшли це корисним (0 Голосів)

Найпопулярніші

Огляд мережі Cloud2Y

Коротка відповідь: Cloud2Y експлуатує власну мережу в Україні (DC2 Київ, DC3 Львів), Європі...
Що означає інфраструктура на базі Cisco?

Коротка відповідь: «На базі Cisco» означає, що маршрутизація та комутація Cloud2Y працюють на...
Як перевірити швидкість мережі

Коротка відповідь: Три стандартні інструменти — speedtest-cli (швидка публічна перевірка), iperf3...
Як перевірити затримку до локацій Cloud2Y

Коротка відповідь: Запустіть ping або mtr звідти, де перебувають ваші користувачі, до сервера (чи...
Як користуватися Looking Glass

Коротка відповідь: Looking Glass (LG) — це веб-інструмент, що дозволяє запускати ping, traceroute...