Как проверить скорость дисков и сети на VPS

Скорость VPS определяется не только числом ядер и объёмом памяти: прежде чем решать, Какого провайдера VPS выбрать, полезно проверить реальную производительность дисков и сети на тестовом сервере MaxiPlace.

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

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

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

Есть и ещё одно ограничение: результаты зависят от времени проведения. Нагрузка в дата-центре меняется, а внешний маршрут может быть перегружен на отдельных участках. Разовая проверка полезна для первичной оценки, но не заменяет наблюдение в течение нескольких часов или дней.

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

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

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

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

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

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

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

В отчёте fio важно смотреть не только на показатель мегабайт в секунду. Для базы данных зачастую важнее количество операций в секунду и задержка. Особенно полезны значения задержки на высоких процентилях, например p95 или p99: среднее значение может выглядеть приемлемо, хотя отдельные операции будут периодически выполняться значительно дольше.

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

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

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

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

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

Один запуск iperf3 не даёт полной картины. Нужно проверить передачу от VPS к удалённой точке и в обратную сторону, а при необходимости — одновременный обмен в обоих направлениях. Результаты могут различаться, потому что маршруты и ограничения на промежуточных узлах не всегда симметричны.

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

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

Команды ping и mtr помогают увидеть задержку до выбранного узла и возможные проблемы на маршруте. Ping показывает время прохождения пакетов, а mtr объединяет проверку маршрута с повторными измерениями. Для анализа лучше выбирать несколько точек: сервер мониторинга, рабочий регион пользователей и внешнюю инфраструктуру, с которой приложение постоянно обменивается данными.

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

Важно разделять задержку до VPS и задержку внутри самого приложения. Если ping стабилен, но запросы выполняются медленно, причина может находиться в диске, процессоре, базе данных или настройках веб-сервера. Если же время ответа скачет вместе с потерями пакетов, следует изучить сетевой маршрут и нагрузку.

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

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

Следует вести собственный журнал тестов. В нём достаточно фиксировать дату, время, конфигурацию сервера, свободное место, параметры fio или iperf3 и полученные значения задержки. Такой журнал помогает отличить случайный всплеск от устойчивой характеристики и оценить эффект после изменения тарифа или настроек приложения.

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

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

Далее проводят серию дисковых тестов. Последовательные операции показывают работу с крупными файлами, случайные — поведение при обращении к разным блокам, а разные глубины очереди помогают понять, как меняется результат при росте параллелизма. Между прогонами полезно выдерживать паузу, особенно если тест создаёт заметный поток записи.

Сетевую часть начинают с ping и mtr до нескольких узлов, после чего измеряют пропускную способность через iperf3 или контрольную загрузку файла. Повторная проверка в обратном направлении позволяет увидеть асимметрию. Если проект рассчитан на постоянный обмен небольшими сообщениями, дополнительно оценивают время установления соединения и стабильность множества параллельных запросов.

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

При выборе площадки такой протокол удобно использовать как основу для сравнения условий: перед тем как решить, Какого провайдера VPS выбрать, можно провести одинаковые проверки на доступных конфигурациях и обратиться к MaxiPlace за уточнением параметров, которые нельзя установить только тестовой командой.

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

Нельзя считать один результат бессрочной характеристикой VPS. После миграции, изменения конфигурации, роста соседней нагрузки или обновления приложения производительность может измениться. Контрольные измерения после существенных изменений помогают вовремя заметить отклонения.

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