Когда облачную машину пора сменять на целиком свою

Сначала столбцы, которые вы уже умеете снимать

Решение начинается не с названия тарифа, а с двух команд на той машине, которая уже работает. Интервал — 1 или 10 секунд, окно — рабочий пик, не ночной бэкап. Нужны хотя бы пять рабочих дней.

vmstat 1
iostat -xz 1

В vmstat столбец us — пользовательское время, sy — система, id — простой, wa — ожидание диска, st — steal. si и so — подкачка туда и обратно. В iostat -xz для диска с данными смотрите aqu-sz (средняя длина очереди) и w_await (ожидание записи). Рядом положите p95 того же окна и время commit из медленного журнала. На контейнерном VPS столбца st нет. Возьмите прирост nr_throttled и throttled_usec из cpu.stat контроллера CPU. Без этой колонки вывод по процессору не делайте.

Чем облако, VPS и выделенный отличаются в этих столбцах

Облачный сервер чаще всего гостевая KVM. На хосте есть другие арендаторы. Гость видит steal: vCPU уже мог считаться, а время отдали соседу. Диск часто сетевой том, IOPS идут по тарифу или по кредитам. У памяти есть потолок. Balloon забирает у гостя страницы, которые тот сейчас не трогает. Выделенный сервер и облачный в этих трёх столбцах расходятся тем, есть ли там чужой арендатор.

VPS сначала делите на виртуалку и контейнер. Виртуалка читается как облако, только потолок обычно ниже. Контейнер душится квотой: растущий nr_throttled на пике — квота кончилась, это не «сервер сломался». Квота уже на потолке тарифа, а троттлинг остаётся — тот же вывод, что и по steal. VPS всё ещё доля чужого хоста. Выделенный сервер, в этой заметке он же bare metal, отдаёт планировщик одному заказчику. В ОС хоста steal должен быть около нуля. Диски — NVMe в этом корпусе. Память — планки этой машины, объём фиксируют в заказе.

Сосед виден в steal

Steal — время, когда гость хотел работать, а процессор держал гипервизор. В Prometheus это rate node_cpu_seconds_total в режиме steal, затем среднее по ядрам. Несколько секунд — короткий всплеск соседа. Облако остаётся. Строка, которая считается: steal несколько раз доходит примерно до 10 % и выше, держится минуты, ваши us и sy этого не объясняют, p95 API идёт туда же. Добавлять vCPU на уже плотном хосте часто значит удлинить очередь.

Другой пик отложите отдельно. us плюс sy почти полные, steal около нуля: ядра кончились у вас. Сначала поднимите CPU в облаке. Если после этого steal в те же рабочие часы возвращается, упёрлись в хост. Линия около 10 % — чтобы читать график, не норматив аварии. Жёсткий бюджет задержки — линия ниже. Пакет, который может подождать, — выше. Держатся вместе несколько рабочих дней и p95 в ту же сторону.

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

Рабочий набор упёрся в потолок памяти

Рабочий набор — страницы, которые нагрузка в этом окне трогает снова и снова. Linux отдаёт свободную память под кэш. Низкий MemAvailable при ровной задержке — обычно кэш. График «память 90 %» сам по себе слабый повод переезжать.

Строку записывайте, когда на рабочих часах вместе: si и so не возвращаются к нулю, major fault растёт вместе с задержкой базы, в журнале ядра есть OOM, нужный буферный пул уже больше памяти этой ВМ, а в линейке провайдера нет следующей ступени, которую вам можно взять. Balloon давит гостя, который по процессам ещё не полон: хост забрал страницы. Сначала отделите balloon от рабочего набора.

Набор около 32 ГБ, без swap и без OOM, закрывается более крупной облачной памятью. Когда набор уже на максимуме, который это облако продаёт, остаются две фиксированные ступени своей машины: 128 ГБ или 256 ГБ DDR4-3200 ECC RDIMM. После заказа планку не добавляют. Считайте от пика плюс запас на систему и страничный кэш. В 128 ГБ не входит — берите 256 ГБ за $592 в месяц. Не входит ни туда, ни туда — эта машина тоже не удержит.

Очередь диска держит commit

Когда база медленная, сначала очередь диска с данными, потом сетевая карта. OLTP смотрит на fsync в момент commit. Последовательные мегабайты ночного бэкапа дневной commit не объясняют.

На пике aqu-sz диска с данными часто больше 1, w_await уходит в десятки миллисекунд, время commit в медленном журнале растёт вместе с ними: очередь держит базу. Пропускная способность в МБ/с при этом может оставаться скромной. У сетевого тома сверху лежат кредиты IOPS. Кредиты кончились — ожидание прыгает и через несколько часов отпускает. Каждый день тот же час, перезапуск приложения ничего не меняет. Верхний тариф IOPS уже куплен, а ожидание повторяется по рабочим дням: предел в общем хранилище.

Ночью диск забит бэкапом, днём w_await обычный — сдвиньте окно копирования. Ожидание низкое, а медленные запросы — это блокировки или полный просмотр: правьте SQL. На NVMe %util около 100 % сам по себе про насыщение говорит плохо. После переезда оставьте длину очереди и ожидание записи.

Если задержка в основном из расстояния до площадки, steal можно убрать, а путь останется. Серверы стоят в Токио, Япония. Путь в Японию и путь в далёкий регион — разные задачи. Блокировки, отсутствующие индексы и вызовы через регионы в эти три строки не входят.

Как свести неделю и куда сядут кривые на своей машине

1. 1
   Пять рабочих пиков

   Оставьте us, sy, st, si, so и p95 того же окна. Час бэкапа храните отдельно.

2. 2
   Кэш или набор

   MemAvailable рядом с буферным пулом и фактическим пиком. Строку OOM из журнала ядра сохраните. На контейнере прочитайте лимит памяти.

3. 3
   Только диск с данными

   aqu-sz и w_await этого диска рядом с commit. Системный диск и диск бэкапа в эту строку не кладите.

4. 4
   Три строки

   На каждую: есть или нет, какие дни, шёл ли p95 туда же. Два «есть» — страница сборки. Одно «есть» — правка тарифа в облаке и повтор через неделю.

Когда два совпадения держатся, проверьте, примет ли их железо. Процессор — один AMD EPYC 7543P, 32 ядра / 64 потока, 2,8–3,7 ГГц. Им пользуется один заказчик. В ОС хоста steal должен быть около нуля. Steal ваших собственных гостей показывает только, как вы делите эти 32 ядра.

Память: 128 ГБ за $465 в месяц или 256 ГБ за $592, обе DDR4-3200 ECC RDIMM. Берите по пиковому рабочему набору. Набор ясно входит в 128 ГБ — берите 128 ГБ.

Диски по умолчанию: 2 × 1 ТБ NVMe, без аппаратного RAID, каждый диск подключён напрямую. Полезный объём читайте как 2 ТБ. Очередь с сетевого тома после перехода на локальный NVMe обычно сначала падает. Не падает — смотрите SQL или нехватку одного диска. Можно добавить до двух дисков по 2 ТБ, каждый по $83 в месяц, тоже напрямую. Сами в массив они не входят. Программный RAID ради избыточности возвращает полезный объём примерно к 1 ТБ. Копии держите вне машины.

Канал по умолчанию 250 Мбит/с, трафик не тарифицируется. Очередь диска — это ожидание хранилища. На 1 Гбит/с (+$251 в месяц) или 2 Гбит/с (+$749) поднимайтесь, когда забит сам порт 250 Мбит/с, а не потому что медленный fsync. Один IPv4 уже входит. Дополнительные адреса — по $2 в месяц за штуку, на сервере всего до 256, по одному, без продажи подсетью. Систему можно взять Ubuntu 24.04. Windows Server Standard добавляет $21 в месяц, Datacenter — $27. Linux по SSH, Windows по RDP.

Месячная сумма — цена машины плюс число дисков, умноженное на 83, плюс шаг канала, плюс число дополнительных IPv4, умноженное на 2, плюс система. К оплате — эта месячная сумма, умноженная на число месяцев. Месяц, квартал, полгода и год считаются этим произведением. Платы за установку нет. Серверы стоят в Токио, Япония. Если совпала только очередь диска, а процессор и память тихие, сначала доведите облачный том до верхнего тарифа и только потом сравнивайте с машиной от $465 в месяц. Лёгкий набор и короткая очередь обычно дешевле остаются на ВМ. Когда совпали две строки, откройте страницу сборки и выберите 128 или 256 ГБ.