Aeza

Что означает steal time %st, понять можно только вместе с очередью CPU и метриками приложения. Если вы хотите разобраться, как читать CPU steal time, не нужно считать единичный максимум доказательством перегрузки хоста. Усреднение по длинному окну способно скрыть короткие паузы, из-за которых сервис и вышел за SLO.

Что означает %st в top и vmstat?

%st показывает долю интервала, когда готовый к работе vCPU не получал физический CPU, потому что хост в это время занимался другой виртуальной машиной, собственными задачами или упирался в лимит. В top и vmstat процент рассчитывается по накопительным счётчикам ядра. Нулевое значение говорит лишь о том, что за этот интервал ядро не насчитало steal. Другие паузы хоста при этом возможны, а часть сред вообще не передаёт счётчик гостю.

Разобрать, какое CPU-время гипервизор забрал у гостя

Планировщик гостевого ядра делит время vCPU между процессами гостя. Планировщик хоста решает, когда vCPU получит физический CPU. Если готовый к запуску vCPU не получает его, гостевое ядро считает интервал как steal. Поэтому %st относится не к конкретному процессу, а к vCPU целиком.

Если вы хотите разобраться, как читать CPU steal time, разделите два уровня планирования. Высокие %usr и %sys относятся к работе гостя. %idle означает простой без ожидающего I/O, а %iowait не измеряет ожидание физического CPU. Троттлинг из-за cgroup quota тоже возникает внутри VM, его проверяют по квоте в cpu.max и счётчикам cpu.stat, а не по %st.

Для такого учёта гипервизор должен передавать данные гостю. KVM поддерживает steal time на x86 и arm64, но наличие показателя зависит от гостевого ядра и настроек платформы. Нулевой %st означает отсутствие учтённого steal за интервал и не исключает других задержек хоста.

Измерять steal по интервалам, а не по строке с момента загрузки

В procps-ng vmstat столбец st, а в mpstat поле %steal показывают долю выбранного интервала. Первая строка vmstat без -y содержит средние значения с момента загрузки и сглаживает недавний эпизод. Минутный срез лучше начать без этой строки и снять 60 замеров с шагом в секунду:

Такой срез показывает %st в виртуальной машине вместе с r, %usr, %sys, %iowait и %idle. Строка all в mpstat усредняет vCPU, поэтому всплеск на одном из них может потеряться в общем значении. Поле r в vmstat – это очередь готовых задач (run queue): число процессов, которые уже исполняются или ждут CPU. Это не точная очередь на каждом ядре.

К сырым логам добавьте UTC-время, число vCPU, версию ядра и тип виртуализации. Без этих данных одно и то же значение может относиться к разным конфигурациям и периодам:

Найти обычный уровень для этой VM и этого часа

Baseline формируют на той же VM до инцидента. Нужны интервалы в часы низкой и обычной нагрузки, одинаковые дни недели и сопоставимый профиль запросов. После изменения числа vCPU, версии ядра, тарифа или лимитов прежний baseline перестаёт быть точкой отсчёта, и замеры нужно снять заново. Другое число vCPU меняет распределение потоков по ядрам и усреднение в строке all, а смена тарифа или лимитов меняет условия, в которых гость получает физический CPU.

Для отчёта полезнее медиана и верхние перцентили %st по минутным окнам, чем максимум за месяц. Секундный пик может не повлиять на сервис, а продолжительный умеренный steal способен сдвинуть хвост задержки. Поэтому высокий steal time на VPS определяют как устойчивое отклонение от обычного уровня конкретной VM с измеримым эффектом.

При каком steal time пора искать проблему?

Универсального порога для steal time нет. Проверку стоит начинать, когда %st устойчиво выше обычного уровня этой VM и совпадает с ростом очереди CPU, прикладной задержки или снижением throughput. Короткий всплеск без пользовательского эффекта сначала нужно подтвердить повторным интервальным замером и, если это возможно, данными гипервизора.

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

Отделить steal от собственной загрузки CPU

Разбор начинается с сопоставления steal в vmstat с остальными полями того же интервала. Большие %usr или %sys, низкий %idle и r выше числа vCPU означают, что готовым задачам не хватает CPU-времени. Эти признаки ещё не отделяют собственное насыщение от steal, так как оба источника могут действовать одновременно.

Среднее по VM может скрыть занятый vCPU: один CPU-bound поток загрузит его на 100 %, пока остальные свободны. mpstat -P ALL обнаружит неравномерность, а pidstat покажет CPU-время потоков процесса:

Ровная загрузка vCPU и отсутствие тяжёлых потоков ещё не закрывают вопрос: процессу может не хватать CPU из-за лимита cgroup, а не из-за хоста. Проверьте, упирается ли нагрузка в квоту. Если CPU-контроллер cgroup v2 активен, файл cpu.stat содержит nr_throttled и throttled_usec, и рост этих счётчиков означает throttling выбранной cgroup. Саму квоту показывает cpu.max. Такой троттлинг может увеличить latency и при нулевом %st, поскольку его создаёт гостевая ОС.

При I/O и блокировках задержка растёт даже с небольшой очередью готовых задач. Эти случаи проверьте по метрикам диска, приложения и внешних зависимостей.

Связать недоступный CPU с latency и throughput

Все ряды нужно привести к одной временной шкале. Сопоставьте в UTC значения %st, r, request rate, throughput, error rate и p50/p95/p99 за одинаковые окна. Секундный замер %st нельзя напрямую сравнивать с пятиминутным p99, поскольку в длинном окне короткий эпизод растворится.

Совпадение высокого %st с жалобами на сервис обычно объясняют соседом по хосту, но шумный сосед и CPU steal здесь остаются гипотезой, пока её не подтвердят данные хоста. Эта версия становится правдоподобнее, если деградация повторяется при сопоставимом потоке запросов и не объясняется релизом, сборкой мусора, I/O или cgroup quota. Если данные хоста показывают тот же эпизод, оснований становится больше. Без них корректный вывод ограничивается наблюдением: VM ждала CPU, и в тот же период сервис вышел за SLO.

Для перепроверки минимальный CSV объединяет ряды по временной метке. Рядом сохраните vmstat.txt, mpstat.txt и экспорт приложения:

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

Проверить гипотезу контролируемой CPU-нагрузкой

Контрольный тест добавляет к текущей картине ровно одну известную переменную – предсказуемую CPU-нагрузку на одном vCPU. На тестовой VM закрепите нагрузку на vCPU 0 на две минуты, а версию stress-ng и выбранный CPU-метод сохраните вместе с результатом:

Вторая команда создаёт CPU-bound нагрузку на одном vCPU, поэтому на рабочей VM для неё нужно согласованное окно. Одновременно снимите vmstat и mpstat. Bogo-ops сравнивайте только между прогонами с одной версией stress-ng, одинаковом образе и прежних параметрах. Другая VM подходит для контроля лишь при том же классе CPU и лимитах.

На хосте платформенная команда проверяет oversubscription, время ожидания потоков vCPU и их привязку к физическим ядрам. Эти счётчики показывают hypervisor scheduling напрямую, поэтому сопоставьте их с гостевым %st за тот же UTC-интервал. Конкретный набор зависит от гипервизора, и часть значений доступна только через интерфейсы платформы.

Как отличить steal time от нагрузки самого приложения?

1. Сопоставьте %st с %usr, %sys, %idle и r: эти поля дают разные признаки дефицита CPU.

2. Проверьте загрузку отдельных vCPU и cpu.stat нужной cgroup: неравномерность или throttling укажут на источник внутри VM.

3. Повторите одинаковую нагрузку и синхронизируйте прикладные метрики. Совпадение всплесков %st с провалами throughput укажет на хост, но окончательный ответ дадут только его счётчики.

Подготовить доказательства для провайдера или платформенной команды

Начните заявку с того, что вы наблюдали, без версий о причине. Формулировка может выглядеть так: «с 10:14 до 10:22 UTC средний %st вырос относительно обычного уровня, одновременно увеличились run queue и p99». Утверждать, что виноват сосед по хосту, вы не можете – гостевые счётчики этого не показывают.

К описанию приложите данные, по которым отклонение можно проверить: идентификатор VM, регион, число vCPU, версию ядра, UTC-интервал и baseline. Дальше идут сырые логи – по ним принимающая сторона пересчитает агрегаты своим шагом и проверит границы эпизода. Собранный архив можно назвать по инциденту и сложить в него metadata.txt, vmstat.txt, mpstat.txt, прикладной CSV и README с порядком воспроизведения. Пароли, токены и пользовательские данные обязательно удалите перед отправкой.

Отдельно попросите проверить на узле ожидание потоков vCPU, oversubscription по vCPU и события платформы за тот же интервал.

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

Настроить сигнал по длительности и влиянию, а не по всплеску

Для постоянного наблюдения нужен накопительный счётчик по каждому CPU. В node_exporter это node_cpu_seconds_total с режимом steal. Долю за пять минут рассчитывают так:

Ollama или vLLM для конкурентного инференса нужно выбирать по нагрузке и затратам на поддержку. Ollama против vLLM по конкурентности нельзя просто оценить одним запуском, ведь результат зависит от модели, формата весов, оборудования и длины контекста. Личному чату важен простой жизненный цикл модели, а серверному API – batching и загрузка ускорителя.

При какой конкурентности vLLM начинает выигрывать у Ollama?

Общего порога нет: vLLM начинает выигрывать, когда очередь запросов даёт планировщику собирать полезные пакеты, а ускоритель ещё не упёрся в память. Практический порог показывает sweep-тест на своей модели, контексте и SLO. При одном клиенте или CPU-инференсе преимущество может не проявиться вовсе.

Начать с конкуренции, контекста и цели сервиса

Поток запросов у трёх типичных сервисов выглядит по-разному. Личный чат ведёт один активный диалог и допускает паузу при загрузке модели. Внутренний API получает всплески от сотрудников. Многопользовательскому batch-сервису приходится выдерживать очередь и соблюдать пределы TTFT и полной задержки.

Для каждого случая нужны длины входа и ответа, доля потоковых запросов, всплеск, средняя и пиковая конкурентность. Эти данные влияют на выбор ускорителя: длинный контекст расходует KV-cache, долгая генерация удерживает слот, а средняя конкурентность не покажет момент, когда длинные диалоги сойдутся и поднимут p99.

Сравнение Ollama и vLLM требует одинакового CPU-бюджета, GPU и сетевого пути. Результат будет иметь смысл только внутри SLO по TTFT, inter-token latency и доле успешных запросов. Иначе суммарная скорость сервера вырастет, а время ответа для пользователя – увеличится.

Оценить простоту локального жизненного цикла модели

Ollama объединяет загрузку модели, локальное хранилище, Modelfile и HTTP API. Один инженер может быстро заменить модель, изменить системный промпт или выгрузить веса после простоя. Холодный старт здесь тоже часть жизненного цикла, его оценивают отдельно от последующих запросов.

В прогретом режиме результат зависит от OLLAMA_NUM_PARALLEL, OLLAMA_MAX_QUEUE, OLLAMA_MAX_LOADED_MODELS, размера контекста и keep_alive. Параллельные запросы увеличивают память под контекст, поэтому настройка под короткие промпты даст очередь или ошибку на длинных запросах.

Быстрый старт и удобный CLI не обязательно означают высокий throughput. Для личного чата и небольшого API Ollama обычно достаточно, а под конкурентной нагрузкой раскрывается continuous batching в vLLM: запросы приходят в разное время и плотнее заполняют ускоритель. Здесь стоит судить по поведению серверов на одинаковой нагрузке, а не по названиям функций.

Разобрать планировщик, batching и управление KV-cache

vLLM рассчитан на серверную очередь: планировщик обновляет состав пакета по мере освобождения ресурсов, а KV-cache хранится блоками. Такой планировщик приносит пользу, когда есть очередь, совместимый GPU и подходящий бэкенд. На одиночных запросах он ничего не даёт.

В отчёте нужно фиксировать --max-num-seqs, --max-model-len, --gpu-memory-utilization, dtype и настройку chunked prefill, на нескольких GPU – ещё и --tensor-parallel-size. Распределение модели между устройствами может увеличить бюджет памяти, но требует обмена данными между GPU.

Параллельные запросы Ollama используют общую память, поэтому у обоих серверов отслеживают очередь, ошибки и OOM. Также у vLLM дополнительно смотрят preemption и состояние KV-cache. На одном коротком запросе дополнительная настройка vLLM может не окупиться.

Какой сервер проще для одного пользователя?

Один пользователь обычно быстрее настроит Ollama, ведь установка, загрузка модели и локальный API собраны в одном инструменте. Это упрощает запуск и дальнейшее обслуживание. vLLM стоит выбрать сразу, если нужны доступные только в нём модели, определённый GPU-бэкенд, подробные метрики или ожидается заметный рост конкурентности.

Уравнять модель, точность и генерацию

Честное сравнение серверов инференса LLM начинается с эквивалентных весов, dtype и схемы квантования. GGUF и safetensors задают упаковку весов и совместимость с движком, а на качество и память влияют точность и квантование. Если общая сборка недоступна, вывод относится только к протестированным вариантам, поэтому в отчёте остаются хеши и источники файлов.

Клиент отправляет одинаковые запросы с общими max_tokens, temperature, top_p, stop и потоковым режимом. Для chat completions этого недостаточно: токенизатор и шаблон тоже должны совпадать, иначе messages превратятся в разные последовательности токенов. По числу входных токенов видно, совпали ли токенизатор и шаблон. В карточку запуска следует записывать версии ПО, GPU, VRAM, CPU, RAM и ОС.

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

Построить кривую от одного клиента до насыщения

Sweep-тест начинается с минимальной конкуренции и идёт по ступеням при неизменных запросах и параметрах генерации. Каждая ступень включает прогрев и несколько серий. Закрытый генератор держит число активных запросов, открытый задаёт частоту запросов, и режимы оценивают отдельно. Эти ступени наращивают до первого отказа: OOM, таймаут, HTTP 503, отклонённые запросы или выход p99 за SLO.

Итоговый график объединяет throughput и задержку vLLM с Ollama. Ось X показывает конкуренцию, а ряды по Y – запросы в секунду, выходные токены в секунду, TTFT, ITL или TPOT и end-to-end latency. Критерий выбора – выполнение SLO, даже если максимум токенов в секунду достигается при большей конкурентности.

Клиент записывает время отправки, первого токена ответа и завершения генерации, число токенов, HTTP-статус и ошибку, а рядом обычно сохраняют конфигурации, логи, загрузку GPU и памяти. Сырые данные делают график проверяемым: нужны requests.jsonl, run.json, results.csv, server.log и gpu.csv.

Считать хвосты задержки, а не только tokens/s

Отсчёт TTFT начинается с отправки запроса и заканчивается на первом токене ответа. Первый фрагмент потока не считается ответом, если в нём нет текста, так как серверы по-разному шлют служебные поля. ITL описывает интервалы между токенами, а интервалы между сетевыми фрагментами правильнее назвать inter-chunk latency. TPOT равен времени генерации после первого токена, делённому на число последующих токенов. Отчёт содержит формулу, точки времени, p50, p95 и p99.

Суммарный throughput характеризует сервер, а клиентские метрики – скорость диалога. Batching увеличивает общую производительность, но одновременно и TTFT клиента. Отдельный блок теста нужен для fairness: короткие запросы не должны надолго задерживаться из-за длинных, а новые этапы prefill – создавать заметные паузы в генерации.

Единый клиент обращается к обоим серверам через локальный OpenAI-совместимый API и собирает сопоставимые метрики. Совпадение URL не гарантирует одинаковой токенизации, шаблона чата и функций, поэтому перед sweep-тестом нужна сверка полей, лимитов, stop-условий и числа токенов.

Что измерять кроме суммарных токенов в секунду?

1. TTFT и end-to-end latency в p50, p95 и p99.

2. ITL или TPOT, длину очереди и долю успешных запросов.

3. Число входных и выходных токенов, OOM, таймаут и отклонённые запросы.

Сравнить API, наблюдаемость, безопасность и обновления

OpenAI-compatible API – слой совместимости без гарантии полного совпадения. Список проверок зависит от приложения: chat completions, streaming, структурированный вывод, embeddings, вызов инструментов и параметры генерации нужны только там, где используются. Сверка по этому списку выявит неподдерживаемые поля до миграции.

Совпадение по полям не сделает сервис сразу готовым к публикации. При публикации сервиса reverse proxy или платформенный слой отвечает за TLS, аутентификацию, ограничение частоты запросов и журналирование. Открытый порт ещё не означает, что первый запрос уложится в SLO, поэтому проверка доступности должна отличать запущенный процесс от загруженной модели.

Наблюдаемость vLLM охватывает очередь, KV-cache, TTFT и полную задержку. Ollama возвращает длительности загрузки, обработки входа и генерации, а набор клиентских метрик остаётся тем же. Перед обновлением новую версию прогоняют на копии рабочего трафика, так как она может изменить бэкенд, шаблон чата, память или параметры. На случай отката стоит держать прежний образ или пакет, конфигурацию и хеш модели.

Принять решение и оставить путь миграции

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

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

Миграция начинается с небольшой доли трафика, а старый сервер остаётся для быстрого отката. На этой же доле проверяют очередь и backpressure. Бесконечная очередь перегрузку не устраняет, она превращает её в рост p99.

• Один пользователь: стартовый выбор: Ollama.
  Проверить: поддерживается ли модель, приемлемы ли холодный старт и потребление памяти.

• Небольшой API команды: стартовый выбор: Ollama или vLLM.
  Проверить: укладываются ли всплески нагрузки в SLO и корректно ли обрабатываются ошибки перегрузки.

• Высокая конкурентность на GPU: стартовый выбор: vLLM.
  Проверить: растёт ли throughput без недопустимого увеличения p99 и без OOM.

Ollama или vLLM для конкурентного инференса выбирают по кривой задержки и throughput внутри SLO. Сильные стороны Ollama – быстрый локальный запуск, простой жизненный цикл модели и умеренная очередь. vLLM требует больше настройки и подходит там, где batching, KV-cache и высокая загрузка GPU дают измеримый выигрыш. Сырые результаты дополняют версиями, весами, оборудованием, промптами и параметрами. Если преимущество исчезает после учёта p99, ошибок и сопровождения, миграция не нужна.

Изоляция ресурсов KVM от шумного соседа проверяется по метрикам полезной нагрузки. Если шумный сосед в KVM занял CPU, память, очередь диска или сетевой канал, начните смотреть, сохранились ли латентность и пропускная способность контрольной VM. Стало: Также стоит иметь в виду, что по типу виртуализации нельзя судить об оверкоммите, NUMA-размещении и правилах cgroup на хосте.

Какие ресурсы KVM изолирует надёжнее всего?

Связка KVM/QEMU разделяет адресные пространства и состояние виртуальных машин. Реальная стабильность производительности зависит от политик хоста: CPU-квот, привязки vCPU, NUMA-размещения, лимитов block I/O и сетевого шейпинга. Эти механизмы не изолируют все общие очереди, поэтому результат проверяют по SLO полезной нагрузки.

Определить общие ресурсы и SLO жертвы

Для начала разделите слои, через которые проходит запрос. Контрольная нагрузка (victim workload) работает внутри гостя. QEMU обслуживает виртуальные устройства и vCPU, ядро планирует его потоки, а физические CPU, NUMA-узлы, накопители и сетевые порты остаются общими. Поэтому шумный сосед в KVM может увеличить ожидание процессора, очередь диска или задержку в сети.

Для контрольной нагрузки задайте один SLO, например верхнюю границу p99 ответа API. Порог берите из требований сервиса. Базовые показатели снимают в одинаковых прогонах и сохраняют с версиями ядра, QEMU, libvirt и параметрами теста.

Топологию нужно фиксировать до нагрузки. На хосте собирают сведения о CPU, NUMA, привязке vCPU и XML обеих VM, а внутри гостевой системы – топологию и метрики приложения. Без такой карты просадка показывает корреляцию, а не причину. Отдельная RAM в ней ничего не гарантирует, так как контроллер памяти, кэш последнего уровня (LLC), диск и сетевой канал остаются общими.

Проверить квоты, pinning и steal под CPU-aggressor

Изоляция CPU виртуальной машины начинается с топологии vCPU. В libvirt указаны допустимые pCPU, а quota и period ограничивают процессорное время. Привязка vCPU сокращает миграции, но конкуренция внутри ядра и за общий кэш остаётся.

Сначала измерьте контрольную нагрузку без соседа, затем запустите конкурирующую нагрузку на другой VM или в отдельной cgroup. В госте собирайте p50/p95/p99 приложения, очередь выполнения и %steal. Рост %steal означает, что гипервизор отдавал время другой работе. Какой именно VM, счётчик не показывает, а нулевой %steal не исключает конкуренцию за LLC и память.

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

Исключить ballooning, reclaim и удалённый доступ к памяти

В госте на нехватку памяти указывают reclaim, major page faults и подкачка. На хосте похожие симптомы создают memory.high, ballooning, KSM и удалённый NUMA-доступ. Эти симптомы совпадают, поэтому причину определяют сопоставлением метрик гостя и хоста.

Перед нагрузкой сохраните numatune, memoryBacking, huge pages и состояние memballoon. Затем создайте давление на память в другой VM. Во время прогона собирайте PSI для памяти, memory.events, распределение памяти QEMU по NUMA-узлам и латентность приложения. Параметр memory.high замедляет процессы и усиливает reclaim, а memory.max может привести к OOM внутри cgroup.

Как воспроизвести и измерить влияние шумного соседа?

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

NUMA-доступ проверяют отдельно: vCPU и память контрольной VM размещают сначала на одном узле, затем на разных. Ограничение I/O в KVM не заменит NUMA-политику, поскольку лимиты диска не влияют на то, с какого узла VM читает память. Если memory pressure не меняется, а латентность растёт при удалённом доступе, проверьте NUMA-размещение и пропускную способность памяти.

Ограничить очередь соседа на общем хранилище

Посмотрите, на каком устройстве лежит диск: разные виртуальные диски могут попадать на один NVMe, RAID или сетевой пул. Изоляция ресурсов cgroup в block I/O опирается на лимиты, которые ядро применяет к процессу QEMU. Через iotune в libvirt задают BPS и IOPS на уровне QEMU, а io.max и io.weight – на уровне cgroup. Вес действует только при конкуренции, жёсткий лимит – всегда.

Профиль контрольной нагрузки не меняют: например, синхронная запись по 4 КиБ при глубине очереди 1. Соседа запускают отдельно для чтения, записи и fsync. После сравнивают p50/p95/p99 латентности операций и пропускную способность. Буферизованная запись без fsync может не дойти до накопителя за время прогона. Поэтому прямой I/O, размер блока и глубину очереди фиксируют.

Лимит задаётся на общем узком участке. Без общей throttle group сосед может использовать второй диск в обход ограничения. Затем повторяют базовый прогон, нагрузку и восстановление. Лимит сработал, если p99 контрольной нагрузки остался в базовом диапазоне, а сосед достиг заданных IOPS. Если нет, проверьте устройство, планировщик ввода-вывода и writeback.

Проверить очереди vhost, shaping и общий uplink

Сетевой трафик проходит через очереди virtio/vhost, CPU для softirq, qdisc, виртуальный коммутатор и uplink. Поэтому перед прогоном сохраните модель интерфейса, число очередей, привязку IRQ и лимиты. В одном прогоне нагружают канал крупными пакетами, в другом – мелкими с высоким PPS. Эти профили нагружают разные части тракта.

На контрольной VM измеряйте латентность, джиттер, потери и прикладную пропускную способность. Работа без потерь не означает стабильный p99, так как очередь может расти перед qdisc или uplink. Шейпинг нужно проверять в обоих направлениях. Очереди virtio-net расходуют CPU, поэтому их число не стоит механически приравнивать к числу vCPU.

Поток мелких пакетов может загрузить softirq и вытеснить QEMU с pCPU. Тот же профиль латентности даёт конкуренция за пропускную способность памяти, поэтому сетевую гипотезу нужно подтверждать отдельно. Для этого сопоставьте IRQ, softnet_stat, сбросы qdisc и загрузку vhost-потоков. Какой бы не оказалась причина, к отчёту приложите топологию, XML libvirt, политики cgroup, параметры нагрузок и сырые ряды.

Построить повторяемую матрицу victim и aggressor

В строке матрицы указывают вид и интенсивность нагрузки соседа, p50/p95/p99 латентности, пропускную способность контрольной VM, метрики ресурса и время восстановления. Порядок один: базовый прогон, нагрузка, остановка соседа, восстановление. Конфигурацию и лимиты менять не нужно.

Какие лимиты снижают помехи без лишней потери мощности?

1. CPU-квота ограничивает процессорное время, а cpuset оставляет планировщику выбор внутри набора ядер.

2. Параметры io.max или iotune сдерживает BPS и IOPS соседа, не резервируя накопитель целиком.

3. Шейпинг ограничивает полосу и кратковременные всплески. Выделенное ядро или устройство нужны лишь при подтверждённом риске для SLO.

Пиннинг CPU KVM проверяйте отдельно: сначала задайте VM пересекающиеся наборы pCPU, затем разведите их по физическим ядрам. Команды ниже фиксируют топологию и складывают вывод в каталог прогона. В каждом таком каталоге укажите автора замера, дату и версии ПО.

Разделить сигналы гостя и доказательства хоста

Метрики гостя показывают влияние на сервис, но редко доказывают причину. Чаще всего смотрят три сигнала. Счётчик %steal указывает на время, отданное гипервизором другой работе. Показатель iowait отражает простой CPU при незавершённых I/O, а скорость диска не измеряет вовсе. PSI даёт долю простоя задач из-за нехватки CPU, памяти или I/O. Ни один из трёх не уличает оверкоммит, поскольку похожие симптомы дают квота, NUMA-размещение, writeback и перегруженный uplink.

На хосте сигнал сопоставляют с cgroup и потоками QEMU. Нужны cpu.stat, cpu.pressure, memory.events, memory.pressure, io.stat, io.pressure, статистика домена libvirt и устройства. Совпадение просадки контрольной нагрузки, давления в её cgroup и активности соседа сужает круг причин. Тот же результат после перезапуска соседа подтверждает вывод.

Клиент публичного VDS обычно не видит cgroup хоста, привязку vCPU к pCPU и устройство хранения. Эту часть картины может дать только провайдер, поэтому в обращении поддержке приложите время, ID VM, профиль теста, базовые показатели, отклонение и сырые ряды. Точный интервал будет полезнее скриншота load average, ведь его можно сопоставить с миграцией VM и телеметрией узла.

Выбрать контроль по измеренному риску

Ограничение нужно выбирать по тому ресурсу, который нарушил SLO. CPU-квота ограничивает соседа, но увеличивает его латентность после исчерпания квоты за период. Параметр cpuset сужает область конкуренции, а выделенное ядро убирает чужие vCPU. Такой резерв дороже и требует учёта SMT, потоков эмулятора и IOThreads.

Для памяти применяют NUMA-привязку, memory.high и отказ от агрессивного ballooning. Для диска выбирают вес, лимит BPS/IOPS или отдельное устройство, для сети – шейпинг, отдельную очередь или uplink. Объём RAM при конкуренции за пропускную способность памяти или LLC не поможет, а любое резервирование снижает коэффициент консолидации.

Выбранное ограничение оценивают по p99 latency и пропускной способности контрольной нагрузки, а не по XML. После миграции хоста, смены тарифа, ядра, QEMU или схемы хранения тест повторяют, так как могут измениться NUMA-топология и устройство хранения. Если мягкий лимит удерживает SLO, выделенный ресурс избыточен. Если хвосты нестабильны, резервирование оправдано измеренным риском.

Изоляцию ресурсов KVM от шумного соседа можно подтвердить, если нагрузка соседа не нарушает SLO контрольной VM, а результат воспроизводится. Недостаточно строки KVM в тарифе, низкого load average или отдельного объёма RAM. Нужны карта общих ресурсов, один изменяемый фактор, временные ряды и проверка восстановления. Если видны только метрики гостя, зафиксируйте влияние на приложение и передайте поддержке точный интервал: без телеметрии хоста причину установить нельзя.

p99 fsync против пиковых IOPS сравнивать бессмысленно, поскольку показатели снимают в разных режимах работы накопителя. Для WAL важна хвостовая задержка fsync при подтверждённой записи, тогда как пиковые IOPS обычно получают с глубокой очередью. Вывод действует только для указанной конфигурации: устройства, файловой системы, кэша, sync-метода и нагрузки.

Почему p99 fsync полезнее пиковых IOPS?

p99 fsync показывает границу, ниже которой уложились 99% синхронизаций в прогоне. Пиковые IOPS показывают пропускную способность при заданной очереди и ничего не говорят об одном flush WAL. Но и p99 оценивают только вместе с числом операций, длительностью теста и конфигурацией конкретного хранилища.

Показать, где WAL ждёт подтверждения записи

При COMMIT процесс добавляет запись о завершении транзакции в WAL и вызывает XLogFlush до нужного LSN. PostgreSQL сбрасывает WAL-буферы в файл, затем просит ОС синхронизировать его. При synchronous_commit=on клиент получает подтверждение после локального flush. Если настроена синхронная репликация, время ответа также зависит от ожидания standby и выбранного режима.

Способ синхронизации WAL задаёт wal_sync_method. На Linux по умолчанию используется fdatasync: PostgreSQL пишет WAL через файловый кэш, затем вызывает fdatasync(). Варианты open_datasync и open_sync открывают файл с другими флагами. Семантика каждого варианта разобрана в документации PostgreSQL, а скорость проверяют на файловой системе будущего pg_wal.

Завершённый write() ещё не говорит о сохранности после потери питания, поскольку данные могли остаться в памяти ядра или энергозависимом кэше контроллера. Поэтому хвостовая задержка fsync включает работу ядра, файловой системы и контроллера, а не только запись блока. Перед тестом фиксируют устройство, LVM или RAID, mount options, политику кэша и наличие power-loss protection.

Почему пик операций не предсказывает транзакционную задержку

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

Средняя latency тоже скрывает паузы. Если 9900 синхронизаций заняли 0,2 мс, а 100 заняли 20 мс, среднее составит около 0,4 мс, хотя у 1% транзакций задержка будет около 20 мс. Заявленная p99 задержка хранилища требует единиц, числа выборок и периода. Без них доля медленных операций неизвестна.

Глубину очереди меняют отдельной серией. QD=1 показывает задержку без очереди, а QD=8 или 32 проверяет параллелизм. При синхронном psync значение iodepth выше единицы не создаёт настоящую очередь, поэтому нужен асинхронный engine с direct=1. Полученную пропускную способность нельзя выдавать за задержку WAL и тем более сравнивать с рекламным read IOPS.

Читать p50, p95 и p99 как форму риска

Перцентили относятся к одному распределению. p50 делит выборку пополам, выше p95 остаются 5% операций, выше p99 остаётся 1%. Для 100 000 операций этот хвост даёт около тысячи наблюдений, а для 1000 – только десять, поэтому маленькая выборка сильнее реагирует на шум.

Как измерять fsync при реалистичной нагрузке?

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

Показатели p50/p95/p99 дополняют гистограммой: по ней видно, образует ли хвост один пик или несколько режимов. На графике, где IOPS отложены против задержки, подпишите block size, queue depth, jobs и длительность. Максимум сохраняют отдельно, так как выброс мог совпасть с checkpoint, discard или работой гипервизора.

По временному ряду видно, распределены ли редкие паузы по всему тесту или хвост создал один провал. Всплески сопоставляют с выводом iostat -x 1, телеметрией NVMe и checkpoint.

Повторить размер записи, очередь и конкурентность WAL

Как правило, сначала фиксируют версию PostgreSQL, wal_sync_method, synchronous_commit, объём WAL за секунду и число одновременно завершающихся транзакций. Скорость генерации WAL считают по разнице показаний pg_stat_wal, а конкурентность берут из журналов и метрик за тот же период. Размер синхронной записи берут из реального профиля, а при его отсутствии помечают как допущение. При конкуренции PostgreSQL может подтвердить несколько транзакций одним flush, поэтому число синхронизаций окажется меньше числа COMMIT.

Сначала моделируют одиночную синхронизацию с выбранным размером блока, например 8 KiB: один job, QD=1, тот же каталог и sync-метод. Затем повышают число jobs. Асинхронный QD-тест идёт отдельно, иначе невозможно понять, что дало прирост: конкурентность приложения или внутренняя очередь устройства.

Набор данных и длительность выбирают так, чтобы тест не закончился на быстром кэше. Для виртуального диска указывают thin provisioning, репликацию и локальный кэш. Бенчмарк надёжной записи, упирающийся в RAM или короткий SLC-burst, ничего не показывает. Поэтому в отчёт вносят свободное место, заполнение и способ предварительной записи.

Согласовать pg_test_fsync, fio и транзакционный прогон

pg_test_fsync сравнивает способы синхронизации и выводит среднее время операции. По документации PostgreSQL файл размещают на той же файловой системе, где будет pg_wal. Утилита помогает выбрать wal_sync_method, но не показывает хвост распределения и не предсказывает пропускную способность базы.

В прогоне, опубликованном 27 мая 2025 года, использовались PostgreSQL 16, Samsung 990 Pro, XFS и write-back-кэш. Фрагмент сырого вывода:

На том же сервере, но на Micron 7400 с PLP среднее время fdatasync составило 24 мкс. Полный вывод и топология стенда есть в исходном отчёте, но из-за разной конфигурации это сравнение классов накопителей, а не моделей.

Чтобы получить распределение, используют fio job, в котором заданы engine, block size, QD и длительность. Укажите отдельный тестовый файл: fio перезапишет его и потребует не менее 32 GiB свободного места.

Команда fio wal-fsync.fio --output=wal-fsync.txt --output-format=normal сохраняет отчёт, а percentile_list задаёт перцентили. Для WAL смотрите раздел fsync/fdatasync/sync_file_range. Отдельная асинхронная серия покажет, как меняется задержка NVMe при разной глубине очереди. Затем подтвердите результат в pgbench с -l или прикладном сценарии при тех же гарантиях сохранности данных.

Поймать cache exhaustion, flush и фоновые паузы

Короткий запуск может закончиться до исчерпания быстрого кэша SSD. Поэтому файл предварительно заполняют, устройство прогревают, а тест ведут до устойчивого режима. По временному ряду видно, как после исчерпания SLC-кэша падает пропускная способность или растёт задержка. Там же видны фоновые паузы. Один итоговый p99 смешивает быстрый старт с установившимся режимом.

Перед серией фиксируют write cache, PLP, температуру, прошивку, заполнение, discard и фоновые операции. Что из этого списка недоступно на виртуальном диске, также отмечают в отчёте. Кэш не отключают, поскольку тест повторяет рабочую конфигурацию, а потерю питания проверяют отдельно.

Какой p99 допустим для транзакционной нагрузки?

1. Универсального порога нет: вычтите из SLO время сети, блокировок, CPU и других синхронных шагов.

2. Определите, какую часть остатка можно отдать ожиданию WAL с учётом group commit.

3. Задайте запас и долю нарушений, затем подтвердите порог транзакционным тестом.

p99 fsync 5 мс уже больше, чем весь SLO в 4 мс. При SLO 100 мс такая задержка может поместиться в бюджет только после учёта остальных ожиданий. Результат проверяют после прогрева и при рабочем заполнении диска, а критерий пересматривают при смене прошивки, миграции VM или росте нагрузки.

Связать хвост fsync с SLO транзакций

p99 fsync нельзя напрямую приравнивать к p99 транзакции. В критический путь транзакции входят блокировки, вычисления, сеть, репликация и иногда несколько flush. Group commit объединяет синхронизации, а synchronous_commit=off убирает ожидание локального диска. Поэтому перед сравнением выясняют, какие этапы идут последовательно, а какие перекрываются.

Затем сопоставляются временные ряды. Если пики commit latency совпадают с ростом времени WAL fsync, await и длины очереди, накопитель становится основной гипотезой. Если метрики хранения остаются ровными, задержку ищут в блокировках, CPU или ожидании реплики. Причину подтверждают изменением одного фактора: устройства, sync-метода или профиля нагрузки.

В SLO записывайте порог, долю нарушений, окно и минимальное число операций. Вместе с результатами транзакционного теста нужно сохранить latency histogram, указав границы бакетов и число наблюдений. Размер запаса задаётся до серии. При росте конкурентности тест лучше повторить: очередь и group commit меняют связь между одним flush и числом завершённых транзакций.

Сделать результат проверяемым на другом стенде

К job-файлу и сырому выводу обычно добавляют дату, версии fio, PostgreSQL и ядра, файловую систему и mount options, модель и прошивку диска, RAID/LVM, кэш и PLP, размер файла, block size, QD, jobs, длительность и прогрев. Для VM также указывают контроллер и неизвестные свойства хранилища.

В папку результата положите fio.job, fio.txt, вывод pg_test_fsync, журналы pgbench, iostat, NVMe log и CSV временного ряда. Рядом с графиком приведите перцентили и число операций. Без исходных файлов нельзя проверить единицы, фильтрацию и границы интервала.

У steady-state workload должен быть критерий: например, 10 минут после 5-минутного прогрева или остановка fio по условию steady state. Выбор зафиксируйте в job-файле. В краткой версии публикации оставьте график p99 и ссылку на полную методику.

Хранилище для WAL выбирают по повторяемой задержке подтверждённой записи и по тому, укладывается ли транзакция в свой SLO. Сначала проверьте sync-метод на файловой системе pg_wal, затем снимите распределение задержек в fio и подтвердите вывод транзакционным тестом. Сырой вывод нужен, чтобы не спутать смену накопителя с изменением нагрузки. После такой проверки p99 fsync против пиковых IOPS перестаёт быть выбором между двумя цифрами: для планирования берут p99, измеренный при нужных гарантиях записи и сопоставленный с SLO.

Настройка VPS начинается со сверки: тот ли сервер выдали и кто, кроме вас, может на него войти. После первого входа нужно сверить параметры заказа, подтвердить SSH-отпечаток, создать отдельного администратора, ограничить входящие соединения и сохранить базовые метрики. Установка VPS по этой схеме рассчитана на образ Ubuntu 24.04 LTS с одним администратором. Панель или cloud-init могут менять эти шаги, поэтому некоторые пункты стоит проверять.

Что сделать сразу после получения доступа к VPS?

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

Что приходит после заказа VPS и что проверить до входа

В личном кабинете или письме указаны IPv4, логин, начальный пароль либо открытый ключ, а также IPv6, если он выдан. Сверьте с заказом регион, образ ОС, vCPU, RAM и диск. После загрузки проверьте их командами nproc, free -h, lsblk и cat /etc/os-release. С ошибкой в регионе или тарифе обратитесь в поддержку до размещения своих данных на сервер.

До первого SSH-входа найдите VNC или другую аварийную консоль, а также порядок запуска rescue mode. Это может понадобится, если ошибка в sshd_config или firewall закроет сетевой доступ. Инструкция Aéza по аварийному режиму показывает, где включается среда восстановления. Конечно, сама она не заменит резервную копию.

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

Как подключиться к VPS и проверить отпечаток ключа

В Linux, macOS и Windows Terminal SSH-клиент вызывается одинаково. В примере данные замените на те, что в карточке сервера:

При первом соединении OpenSSH показывает тип ключа хоста и SHA256-отпечаток.

The authenticity of host '203.0.113.42' can't be established.
ED25519 key fingerprint is SHA256:Wq6...K3A.
Are you sure you want to continue connecting (yes/no/[fingerprint])?

Не подтверждайте yes, пока не получите отпечаток другим путём. Откройте аварийную консоль и выполните ssh-keygen -lf /etc/ssh/ssh_host_ed25519_key.pub, затем сравните строку целиком.

После переустановки ключ хоста меняется. Если сервер не переустанавливали, предупреждение REMOTE HOST IDENTIFICATION HAS CHANGED требует остановки и проверки через консоль или поддержку. Команду ssh-keygen -R IP запускают только после подтверждения причины. На Windows запись хранится в %USERPROFILE%\.ssh\known_hosts, в Linux и macOS – в ~/.ssh/known_hosts.

Отдельный пользователь, sudo и вход по ключу

Сначала создайте учётную запись и каталог для ключа. Текущий сеанс пока не закрывайте:

На рабочем компьютере создайте ключ ssh-keygen -t ed25519 -a 100, если его ещё нет. В Linux перенесите открытую часть командой ssh-copy-id operator@IP. В macOS и Windows Terminal при отсутствии ssh-copy-id добавьте содержимое .pub в /home/operator/.ssh/authorized_keys через открытый сеанс, затем задайте владельца operator и права 600. Приватный ключ на сервер копировать не нужно. Войдите как operator во втором терминале и выполните sudo -v. После проверки можно продолжать настройку VPS сервера.

Как безопасно перейти с пароля на SSH-ключи?

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

В Ubuntu файлы из sshd_config.d читаются раньше основного sshd_config, а для большинства директив действует первое найденное значение. Имя 00-local-hardening.conf помещает локальный фрагмент в начало порядка чтения.

После sshd -t выполните reload и, не закрывая текущую сессию, откройте вторую новым пользователем. Проверка вторым сеансом важнее самой команды: на Ubuntu 24.04 с сокет-активацией reload может вернуть ошибку, если ssh.service не запущен. Если вход не работает, исправьте фрагмент через VNC и повторите sshd -t.

Запретить входящие и открыть только нужные порты

UFW в стандартном Ubuntu изначально выключен, а в облачном образе пакет и вовсе может отсутствовать. Проверьте его, задайте политики и откройте SSH-порт. Если sshd слушает не 22-й порт, возьмите значение из sudo ss -utlnp.

Перед ufw enable оставьте SSH-сеанс открытым. Второй терминал понадобится, чтобы проверить, как подключиться к VPS при действующих правилах. ufw status показывает эти правила, а ss -utlnp – слушающие сокеты и связанные процессы. Сетевой экран не останавливает сами службы.

Порты 80 и 443 добавляют после запуска веб-сервера. Базу данных, Redis и административную панель не нужно открывать всему интернету только потому, что приложение к ним подключается. Смена SSH-порта уменьшает шум от сканеров в журнале, но не заменяет ключи и запрет входа по паролю. В руководстве Ubuntu по UFW описаны простые правила, однако сетевой экран в панели провайдера остаётся отдельным уровнем.

Docker направляет трафик к опубликованным портам в обход обычных правил UFW. Сервис за обратным прокси привязывайте к 127.0.0.1. Для iptables правила пишите в цепочку DOCKER-USER: она документирована и не перезаписывается при перезапуске Docker. При другом бэкенде фильтруйте трафик в панели провайдера.

Обновления, время, локаль и swap без лишнего тюнинга

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

В стандартной установке Ubuntu 24.04 пакет unattended-upgrades ежедневно применяет обновления безопасности. Сторонние репозитории без отдельного правила он не охватывает, а автоматическая перезагрузка по умолчанию выключена. Ответственного за окно обновлений и перезагрузку лучше всё равно назначить, а результат контролировать по /var/log/unattended-upgrades/.

Для серверных журналов удобно оставить UTC: sudo timedatectl set-timezone UTC. Локаль C.UTF-8 уменьшает расхождения в выводе скриптов, если приложение не требует другой: sudo localectl set-locale LANG=C.UTF-8. Менять локаль ради отдельной команды не нужно, достаточно запускать её с LC_ALL=C.

Swap даёт ядру запас при резком пике памяти. При нехватке RAM этот механизм может вызвать длительные задержки при обращении к диску. Сначала проверьте текущий swap и профиль приложения. Для базы данных или сервиса, чувствительного к задержке, размер и vm.swappiness выбирают после замеров. Если в vmstat постоянно растут столбцы si/so, пересмотрите лимиты или тариф до увеличения swap.

Как доказать, что VPS работает после настройки

Сразу после настройки сервер пустой, и это лучший момент снять базовую линию. Через месяц, когда появится жалоба на медленную работу, сравнивать будет не с чем. Зафиксируйте дату, исполнителя, ОС, ядро, vCPU, RAM, диск и версии утилит. Для CPU сохраните минутный лог mpstat, для диска используйте временный файл, а iperf3 запускайте до своего узла в целевом регионе.

Как проверить безопасность и базовую производительность VPS?

1. Сохраните эффективные параметры sshd -T, правила ufw status numbered и список слушающих сокетов ss -utlnp.

2. Сохраните минутный лог mpstat, запустите fio на две минуты и запишите p50/p95/p99, затем выполните прямой и обратный прогоны iperf3.

3. Приложите конфигурацию, версии и сырой вывод, затем повторите замеры в другое время. Один максимум не считается базовой линией.

date -Is; uname -r; lscpu | sed -n '1,16p'; free -h; lsblk
fio --version; iperf3 --version; mpstat -V
LC_ALL=C mpstat -P ALL 1 60 | tee mpstat.log
fio --name=baseline --filename=/var/tmp/fio.bin --size=1G --direct=1 \
--rw=randrw --rwmixread=70 --bs=4k --ioengine=libaio --iodepth=1 \
--runtime=120 --time_based --group_reporting --percentile_list=50:95:99 \
--output-format=json --output=fio.json
rm -f /var/tmp/fio.bin
: "${IPERF_HOST:?Укажите адрес сервера iperf3}"
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 --json > iperf3-send.json
iperf3 -c "$IPERF_HOST" -P 4 -t 30 -O 5 -R --json > iperf3-recv.json

fio нагружает диск, поэтому запускайте его в согласованное окно: на основном сервере и на соседних VM нагрузка будет заметна. iodepth=1 показывает задержку одиночной очереди, а не максимальные IOPS при глубине 32. Файл должен помещаться на диске с запасом. В документации fio JSON содержит IOPS и completion latency percentiles, включая заданные p50, p95 и p99.

На собственном контрольном узле запустите iperf3 -s, задайте его адрес в IPERF_HOST и выполните прямой и обратный прогоны с одинаковыми параметрами. Публичный узел не служит эталоном. По официальной документации iperf3 для теста нужны клиент и сервер. Между прогонами не меняйте конечные узлы и их конфигурацию. Сохраните JSON и повторите замер трижды. Оценивайте %steal вместе с загрузкой vCPU: одиночный всплеск не доказывает проблему хоста.

Привязать домен и не ждать TTL вслепую

A-запись содержит IPv4 сервера, AAAA-запись содержит IPv6. Перед добавлением AAAA проверьте маршрут, сетевой экран и прослушивание сервиса по IPv6. Первоначальная настройка VPS также требует проверить, проксирует ли DNS-провайдер веб-трафик и какой IP увидит пользователь.

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

Если ответы расходятся, сравните их TTL с ответом авторитетного сервера. Очистка локального кеша не изменит запись у внешнего резолвера. Для HTTPS дополнительно проверьте сертификат и имя виртуального хоста, поскольку правильный A/AAAA ещё не подтверждает готовность приложения.

Для исходящей почты нужен PTR, который настраивает владелец IP-диапазона. Имя из PTR должно прямым запросом возвращаться к тому же адресу. Требования Gmail для всех отправителей включают согласованные прямую и обратную DNS-записи, а также SPF или DKIM. При отправке более 5000 писем в сутки на адреса Gmail нужны оба механизма и DMARC. Если сервер не отправляет почту напрямую, веб-сайту PTR не нужен.

Что добавить после первого часа: бэкап, мониторинг и сервис

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

Бэкапы храните вне VPS и регулярно восстанавливайте тестовую копию. Не стоит путать со снапшотами: они фиксируют состояние на момент создания, но не заменяют независимую копию и журнал восстановления. Частоту выбирают по RPO, а время восстановления по RTO. Для базы данных нужна согласованная копия средствами СУБД или остановка записи на время снимка.

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

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

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

Через сутки после первого запуска повторите контрольные проверки. Убедитесь, что обновления завершились, место на диске не заканчивается, сервис отвечает, а задание бэкапа выполнилось успешно. Считайте, что настройка VPS закончена, когда текущее состояние можно проверить, а порядок восстановления понятен тому, кто будет сопровождать сервер.

MSPT и TPS сервера Minecraft показывают темп тиков и длительность каждого тика. Среднее значение может скрыть длинные тики, поэтому разберём, как читать тайминги Minecraft на Paper. Результат зависит от версии ядра, мира, плагинов, онлайна и метода измерения.

Чем TPS отличается от MSPT?

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

Понять бюджет главного потока Minecraft

Чтобы понять, как читать тайминги Minecraft, начните с цикла сервера. При стандартном tick rate сервер должен выполнять 20 тиков в секунду, поэтому на один тик приходится 50 мс. За это время главный поток обновляет миры, сущности и блоковые сущности, выполняет запланированные задачи плагинов, обрабатывает часть сетевых пакетов и применяет изменения мира. Большая часть этой работы идёт последовательно: следующий тик не начнётся, пока не завершится текущий.

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

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

Читать темп тиков с учётом сглаживания и потолка

TPS показывает средний темп за окно измерения. В выводе spark встречаются значения за несколько периодов, поэтому число нужно подписывать: «TPS за последнюю минуту», а не просто «TPS». На сервере со стандартным tick rate верхняя граница равна 20. Из-за этого ровные 20 TPS не говорят, что все тики были короткими: после одного длинного тика следующие могли завершиться быстро.

Связка 20 TPS и 50 MSPT даёт границу только для стандартного темпа. Когда средний тик стабильно занимает больше 50 мс, сервер уже не успевает поддерживать 20 TPS. Но обратный вывод другой: близкий к 20 средний TPS не исключает редкий тик на 200 или 500 мс. На длинном интервале он мало изменит среднее, хотя игрок заметит паузу.

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

Смотреть медиану и хвост времени тика

По MSPT видно распределение tick time, то есть длительности отдельных тиков. Медиана отражает обычный тик, p95 показывает границу для 95% наблюдений за выбранное окно, а максимум отмечает самый длинный эпизод. Среднее чувствительно к выбросам и не отвечает на вопрос, насколько часто они возникают. Поэтому для жалобы «раз в минуту всё зависает» важнее хвост распределения и временная линия, чем одно среднее значение.

Почему при нормальном TPS игроки всё равно видят лаги?

TPS может оставаться около целевого значения, потому что он усредняет темп за выбранное окно и имеет верхнюю границу. Игроки при этом замечают отдельные длинные тики. Похожий симптом дают паузы GC или задержки в сети. Сначала сопоставьте жалобу с MSPT, ping и профилем того же периода.

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

Снять профиль именно во время воспроизводимого лага

Диагностика лагов тика Minecraft начинается не с длинной записи «на всякий случай», а с воспроизводимого эпизода. Запишите версию Paper, Java и spark, число игроков, список миров и плагинов, view-distance и simulation-distance. Рядом опишите действие: например, перелёт в ещё не сгенерированную область, запуск фермы или массовое перемещение сущностей. Без этого профиль трудно повторить после правки.

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

/spark tickmonitor --threshold-tick 80
/spark profiler start --only-ticks-over 80 --timeout 300

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

Найти работу, которая удерживает главный поток

Профайлер spark MSPT показывает отдельно от TPS, но причину лага не называет. В viewer откройте Server thread и идите по ветке с наибольшим временем до конкретного метода, сущности или плагина. Верхние узлы вроде MinecraftServer.tickChildren() лишь объединяют работу ниже. Их доли включают дочерние вызовы, поэтому соседние уровни нельзя складывать как независимые расходы.

Публичный профиль Paper 1.21.11 от 4 августа 2026 года показывает, как читать дерево. За 30-секундное окно при одном игроке средний темп составил 0,91 TPS; медиана равнялась 1110 мс, p95 1227 мс, максимум 1282 мс. В мире было 32 695 сущностей. В ветке Server thread профилировщик отнёс 28,6 из 30 секунд к Slime.tick() и 24,9 секунды к вложенному pushEntities(). Профиль указывает не на абстрактную нехватку CPU, а на обработку столкновений огромной группы слаймов.

Вывод относится только к профилю: Paper 1.21.11, один игрок, 30 секунд, запись запущена из консоли. В другом отчёте узел с именем плагина может лишь вызывать код ядра. Гипотезу подтверждают только после спуска к дочернему узлу и проверки тем же сценарием.

Сопоставить длинные тики с событиями мира и JVM

Какой раздел таймингов обычно показывает узкое место?

1. В spark сначала откройте Server thread: именно он выполняет последовательную работу игрового тика.

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

3. Сверьте дорогой узел с временной линией и повторяемым действием. Верхний контейнер сам по себе не доказывает причину.

Снимок дерева показывает, на каких вызовах профилировщик собрал образцы CPU, но не всегда объясняет редкий всплеск. Поэтому spark profiler читают вместе с временной линией. Отметьте момент генерации чанков, autosave, массового спавна, телепортации и сборки мусора. Если тот же пик появляется после одинакового действия, гипотеза становится проверяемой.

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

Изменить один фактор и повторить тот же сценарий

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

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

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

Превратить профиль в приоритет исправлений

Исправления сортируют по подтверждённому времени главного потока, а не по популярности совета. Если в viewer доминируют entities and chunks, проверяют источник массового спавна, размер активной области, генерацию мира и тяжёлые операции. Настройку выбирают по найденной ветке: снижение view-distance не исправит плагин, который синхронно обходит всех игроков каждый тик.

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

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

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

Цель диагностики не удержать TPS на отметке 20, а убрать подтверждённую работу, которая растягивает тик. Для каждого вывода сохраняют версию, условия, временное окно и профиль. В таком отчёте MSPT и TPS сервера Minecraft помогают проверить причину лага и результат исправления, не ограничиваясь двумя цифрами.

Как проверить VPS-сервер, если API по какой-то причине отвечает дольше, а список процессов не объясняет задержку? Нужно поймать сам симптом и одновременно записать top, vmstat, iostat -x и ss. Эти данные покажут вам, где образовалась очередь: у CPU, памяти, диска или сокета. Такой сбор подходит для первичной диагностики Linux-сервера под прикладной нагрузкой, но без истории метрик и данных приложения не даёт точную причину сбоя. Поэтому проверку VPS-сервера нельзя сводить к одной команде.

Какие четыре команды сначала запустить на медленном сервере?

Для начала запустите top, интервальные vmstat и iostat -x, а ss повторяйте циклом. Начните запись до воспроизведения замедления и сохраните время каждого среза. Команды помогут выбрать между CPU, памятью, диском и сетью, но вывод нужно сопоставить с метриками приложения и проверить повторным запуском.

Сначала зафиксировать, когда и как сервер замедляется

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

На образе без systemd стоит отдельно проверить службу синхронизации времени.

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

Проверить процессы, CPU и память в одном срезе

Данные интерактивного top пропадут после закрытия терминала, а набор полей зависит от настроек пользователя. Пакетный режим -b печатает срезы обычным текстом, без перерисовки экрана, поэтому вывод можно перенаправить в файл. Ключи описаны в руководстве procps-ng. Два запуска ниже сортируют процессы по CPU и памяти, а системная сводка остаётся в обоих логах.

На вопрос, как проверить скорость VPS, один список процессов не ответит. us показывает время пользовательского кода, sy – работу ядра, wa – простой CPU при незавершённом I/O, st – время, которое гипервизор не предоставил vCPU. Высокий load average не доказывает нехватку CPU, так как Linux учитывает готовые к выполнению задачи и состояние непрерываемого ожидания. Поэтому сопоставляйте загрузку ядер с работающими процессами и состоянием D. Тот же срез закрывает и память: судить о ней по free нельзя, кеш освобождается по мере необходимости.

Увидеть очередь CPU, swap и системную динамику

vmstat сводит в одну строку процессы, память, swap, I/O и CPU. Команда пишет 13 строк с шагом 5 секунд. Первая содержит средние значения с момента загрузки, а текущий эпизод отражают следующие строки.

r показывает готовые к выполнению задачи, b – задачи в непрерываемом ожидании. Очередь r выше числа vCPU вместе с высоким us или sy поддерживает мысль о нехватке CPU. si и so показывают обмен со swap, а не его занятый объём. При включённом swap стабильно ненулевые si/so, дисковая активность и задержка указывают на подкачку. Без swap нулевые значения ни о чём не говорят, здесь нужны MemAvailable, OOM-события и /proc/pressure/memory.

Как отличить проблему CPU, памяти, диска или сети?

Снимайте показатели в одном окне: очередь r и загрузку CPU, обмен со swap, r_await, w_await и очередь диска, повторные передачи и очереди сокетов. Один всплеск не определяет узкое место. Нужны замедление приложения и второй сигнал того же ресурса в соседнем логе.

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

Проверить очередь и задержку конкретного диска

Расширенный режим iostat снимает статистику по блочным устройствам. Ключ -y пропускает отчёт со средними с момента загрузки, -z скрывает неактивные устройства, -t добавляет время. В Debian и Ubuntu утилита входит в sysstat. Установить пакет лучше до диагностики, а не во время короткого сбоя.

Когда диагностика медленного сервера приводит к дисковой ветке, сначала найдите устройство проблемного пути. r/s и w/s показывают операции, rkB/s и wkB/s – поток данных, aqu-sz – среднюю очередь. По описанию sysstat, r_await и w_await включают очередь и обслуживание запроса. Сравнивайте r_await и w_await с задержкой приложения и профилем нагрузки.

%util, близкий к 100%, показывает насыщение устройства с последовательным обслуживанием. Для NVMe, RAID и других параллельных устройств показатель не показывает предел производительности. На VPS видимый диск может скрывать хранилище хоста. Не суммируйте строки диска, раздела и device mapper: одна операция учитывается на нескольких уровнях.

Найти переполненные очереди, retransmits и состояние сокетов

ss не имеет интервального режима, поэтому скрипт ниже запускает его циклом. -n отключает разрешение имён, -a включает все сокеты, -p показывает процесс, -i – TCP-данные. Без root сведения о чужих процессах могут отсутствовать.

Чтобы понять, как проверить скорость VPS-сервера со стороны сети, различайте слушающие и установленные сокеты. У установленного соединения Recv-Q показывает непрочитанные байты, Send-Q – неподтверждённые данные. У слушающего сокета поля показывают текущую и предельную очередь подключений. Её рост у одного процесса указывает, что он может не успевать принимать соединения.

В TCP-информации ищите retransmits, RTT и RTO. Повторная передача означает, что отправитель не получил пригодное подтверждение вовремя. Причинами могут быть потеря, задержка, переупорядочивание пакетов или ложный тайм-аут. Точную сторону проблемы счётчик не определяет. Много TIME-WAIT не считается ошибкой без исчерпания локальных портов. Ключи описаны в руководстве iproute2.

Пороги для RTT, retransmits и очередей у каждого сервиса свои: эталоном служит ваш же базовый интервал без замедления. Скрипт ниже собирает такой пакет за одно окно, после того как вы опишете нагрузку в LOAD_DESC.

Свести четыре вывода в дерево решений

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

1. CPU: r устойчиво выше числа vCPU, а top показывает занятые ядра. При высоком wa сначала проверьте диск.

2. Память: при включённом swap растут si/so и задержка. Без swap нужны MemAvailable, OOM-события и PSI.

3. Диск: растут r_await, w_await или aqu-sz, а vmstat показывает задачи b либо top – состояние D.

4. Сеть или сокет: одновременно растут RTT, retransmits либо очереди сокетов и ухудшаются latency или error rate.

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

Какие данные собрать до проверки приложения?

5. Версию ОС и утилит, часовой пояс, начало симптома и длительность выборки.

6. Полные команды и сырые интервальные логи top, vmstat, iostat -x и ss.

7. Описание нагрузки, endpoint или задачу, latency, throughput, error rate и базовый интервал.

Эти интервалы должны перекрывать один эпизод: разновременные логи в причинную цепочку не сводятся.

Проверить, отвечает ли ресурсная гипотеза на симптом

Системный сигнал нужно связать с сервисом. Сопоставьте по времени p50, p95 и p99 latency, throughput и error rate. Для очереди заданий подойдут время жизни старейшей задачи и скорость обработки. Рост r_await или w_await без прикладной задержки может относиться к другому диску. Если сервис замедлился без ресурсных сигналов, проверяйте блокировки, внешние зависимости и DNS.

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

Гипотеза должна предсказывать результат. Если CPU занят фоновой задачей, её ограничение должно уменьшить r и задержку сервиса. При дисковой очереди уменьшение интенсивности тестовой записи должно снизить w_await. Если прогноз не сбылся, зафиксируйте результат и проверьте другую ветку.

Оформить короткий пакет для следующего шага

Передавайте каталог с логами и коротким README, а не один скриншот top. Укажите автора, дату, конфигурацию VPS, ОС, ядро, команды, нагрузку и границы симптома.

Разделите диагноз на факты, гипотезу и недостающие данные. Факт содержит время и источник, например одновременный рост w_await и p95 одного адреса API. Гипотеза описывает механизм и ожидаемый результат проверки. Термин network latency без маршрута, RTT и стороны измерения остаётся предположением.

Для следующего инженера оставьте одну строку на ветку: симптом, два сигнала, проверка и критерий. Сырые логи храните в основном материале или приложении вместе с командами и контекстом.

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