Я не пишу это как негативный отзыв об AVA Hosting.
Это просто один из моих обычных рабочих дней как разработчика: сервер ведёт себя плохо, очевидные объяснения не подходят, а потом Linux наконец показывает, что происходит.
У меня был небольшой KVM VPS от AVA Hosting:
1 vCPU
2 GB RAM
25 GB NVMeНа нём работала обычная продакшен-нагрузка. Nginx был запущен. Backend был запущен. Свободная память оставалась. Диск не был заполнен.
Но сервер не успевал обрабатывать нагрузку.
Поэтому я провёл пассивное 60-секундное наблюдение под обычным продакшен-трафиком. Без stress test, искусственного HTTP flood и дискового benchmark.
Результат:
vCPU count: 1
Average CPU user: 52.52%
Average CPU system: 8.07%
Average CPU softirq: 6.69%
Average CPU steal: 32.73%
Average CPU iowait: 0.00%
Average CPU idle: 0.00%
Maximum runnable queue: 11Главной цифрой оказались 32,73% CPU steal. После этого диагноз полностью изменился.
Почему меня это удивило
AVA Hosting сейчас рекламирует свои VPS фразой “Guaranteed resources — no sharing”. На страницах VPS также говорится о фиксированном или выделенном распределении vCPU и утверждается, что производительность не должна зависеть от других клиентов. В материалах о Linux VPS AVA идёт ещё дальше: интенсивная CPU-нагрузка другого tenant на том же хосте якобы не может вызвать steal time в вашей instance. На другой странице говорится, что CPU steal устраняется на уровне hypervisor.
Это очень конкретные заявления. Речь не о странице, где просто указано 1 vCPU, а модель распределения CPU не описана. AVA прямо заявляет защиту от того самого типа CPU contention, который Linux, судя по метрикам, фиксировал внутри моей VM.
Что означает CPU steal
steal — обычная метрика Linux для CPU в виртуализированных средах. Она показывает время, когда у гостевой системы была готовая к выполнению работа, но виртуальный CPU фактически не выполнялся.
Это не то же самое, что приложение, которое просто использовало весь доступный CPU. Если бы я видел около 100% user/system, 0% steal и 0% idle, я бы решил, что нагрузке просто требуется больше вычислительной мощности.
Но здесь примерно треть CPU accounting приходилась на steal.
Изнутри guest я не вижу hypervisor AVA. Я не могу знать загрузку физической ноды, количество соседних VM, политику CPU pinning или коэффициент overcommit. Но я могу видеть то, что сообщил Linux моей VM: vCPU неоднократно не выполнялся, хотя работа ждала процессорного времени.
Это был не секундный всплеск
Один плохой CPU sample меня бы не убедил. Поэтому я непрерывно измерял сервер в течение 60 секунд. Никакого stress test, синтетического HTTP flood или дискового benchmark я намеренно не запускал.
Посекундные значения регулярно выглядели так:
%usr %sys %soft %steal %idle
53.54 10.10 5.05 31.31 0.00
56.44 6.93 5.94 30.69 0.00
51.52 7.07 6.06 35.35 0.00
55.45 6.93 5.94 31.68 0.00
51.49 8.91 5.94 33.66 0.00
52.53 7.07 7.07 33.33 0.00
52.48 6.93 7.92 32.67 0.00Ближе к концу наблюдения картина сохранялась:
50.98 10.78 6.86 31.37 0.00
48.48 8.08 9.09 34.34 0.00
55.00 5.00 7.00 33.00 0.00Среднее за весь период:
user: 52.52%
system: 8.07%
softirq: 6.69%
steal: 32.73%
iowait: 0.00%
idle: 0.00%То есть это была не краткая аномалия scheduler. Большую часть минуты steal оставался около 30% или выше, а CPU idle всё время был равен нулю.
Для понимания масштаба: 32,73% от минуты — примерно 19,64 секунды. Это не означает, что VPS завис на 19,64 секунды подряд. Просто небольшие интервалы, когда vCPU не получал выполнение, суммарно дали примерно такое время.
Backend не мог разгрузить очередь
Проблема с CPU была видна и на уровне приложения. До наблюдения listen queue backend выглядела так:
Recv-Q: 168
Send-Q: 511Через 60 секунд:
Recv-Q: 166
Send-Q: 511Точные цифры здесь не главное. Важно, что очередь практически не уменьшилась. У приложения была целая минута, чтобы догнать нагрузку, но оно так и оставалось позади.
Также было много соединений CLOSE-WAIT. Только по этому состоянию я бы не обвинял хост, поскольку оно может быть связано и с обработкой соединений в самом приложении. Но общая картина была последовательной:
1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not drainingСервер был жив, но здоровым его назвать было нельзя.
RAM и диск не выглядели очевидными bottleneck
Я проверил и стандартные альтернативы. Память:
RAM total: ~1.9 GiB
RAM available: ~959 MiB
Swap total: 2 GiB
Swap used: ~33 MiBЗначительная часть памяти оставалась доступной, а очевидного OOM-события, которое объяснило бы проблему, не было.
Файловая система:
24 GB total
14 GB used
9.4 GB available
60% usedСредний CPU I/O wait составлял 0.00%. При этом CPU pressure держался около 99%, load average на VM с одним vCPU был примерно 3,5–4, а runnable queue доходил до 11.
Все измерения указывали в одну сторону: машине не хватало доступного CPU-времени, а не RAM или скорости диска.
Противоречие с формулировками AVA
Для меня это самая интересная часть истории.
AVA говорит “Guaranteed resources — no sharing”. Утверждает, что другие клиенты не должны влиять на производительность. В материалах Linux VPS говорится, что другой tenant не может вызвать steal time, а на другой странице — что CPU steal устраняется на уровне hypervisor.
Мой VPS у AVA показывал:
Average CPU steal: 32.73%Изнутри VM я не могу доказать точную причину. Я не могу доказать намеренный overselling, указать на конкретную соседнюю нагрузку или восстановить конфигурацию CPU на стороне хоста AVA.
Я также не утверждаю, что каждый VPS AVA Hosting ведёт себя таким образом. Я тестировал один сервер.
Но я могу сказать, что измеренное поведение очень трудно совместить с этими конкретными заявлениями об изоляции CPU. Для этой статьи этого достаточно.
Почему я не стал покупать более мощный тариф
Очевидным решением было бы купить больше vCPU.
Если бы VPS показывал почти нулевой steal, а моё приложение просто полностью использовало одно ядро, upgrade был бы логичным. Но примерно треть наблюдаемого CPU accounting приходилась на steal.
Я не хотел платить за дополнительные виртуальные CPU, пока не понимаю, почему такая большая часть времени выполнения первого vCPU уже фиксируется как недоступная. Поэтому я отменил VPS и запросил возврат денег.
AVA быстро вернула все деньги
Эта часть опыта была хорошей.
AVA Hosting вернула полную сумму. Возврат обработали быстро и не стали несколько дней спорить со мной по поводу измерений CPU. Я объяснил проблему, запросил деньги обратно, и мне их вернули.
За это спасибо.
Поэтому из моего опыта следуют два отдельных вывода: у полученного мной VPS была серьёзная проблема с доступностью CPU, и AVA нормально обработала мой возврат. Оба утверждения верны.
Что я вынес из этого опыта
Теперь я не оцениваю VPS только по характеристикам вроде 1 vCPU / 2 GB RAM / NVMe / KVM. Эти цифры говорят, что было provisioned, но не говорят, насколько предсказуемо CPU будет доступен под реальной нагрузкой.
Теперь среди первых проверок на новой VM у меня:
mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60Главный урок моего опыта с AVA Hosting не в том, что одного vCPU всегда мало. А в том, что запущенный процесс, свободная RAM и нормально выглядящий диск могут скрывать совершенно другую проблему.
В моём случае Linux показал её особенно ясно:
CPU steal: 32.73%
CPU idle: 0.00%
CPU pressure: ~99%AVA Hosting рекламирует CPU-ресурсы без sharing и утверждает, что соседние нагрузки не должны вызывать steal. Мой VPS показывал другое.
Я его отменил. AVA быстро и без споров вернула мне все деньги.
На этом этот рабочий день с отладкой закончился.