“Guaranteed Resources — No Sharing” denmesine rağmen AVA Hosting VPS'imde ortalama CPU Steal %32,73 çıktı

Bunu AVA Hosting hakkında olumsuz bir inceleme olarak yazmıyorum.

Bu, geliştirici olarak yaşadığım sıradan iş günlerinden biri: sunucu kötü davranıyor, bariz açıklamalar uyuşmuyor ve sonunda Linux gerçekten ne olduğunu gösteriyor.

AVA Hosting'de küçük bir KVM VPS'im vardı:

1 vCPU
2 GB RAM
25 GB NVMe

Üzerinde normal bir production workload çalışıyordu. Nginx çalışıyordu. Backend çalışıyordu. Kullanılabilir bellek vardı. Disk dolu değildi.

Yine de sunucu yükü yetiştiremiyordu.

Bu nedenle normal production trafiği altında 60 saniyelik pasif bir gözlem yaptım. Stress test, sentetik HTTP flood veya disk benchmark çalıştırmadım.

Sonuç:

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

Asıl önemli sayı %32,73 CPU steal oldu. Bu noktadan sonra teşhis tamamen değişti.

Bu neden şaşırtıcıydı

AVA Hosting şu anda VPS ürününü “Guaranteed resources — no sharing” ifadesiyle tanıtıyor. VPS sayfalarında vCPU tahsisi fixed veya dedicated olarak anlatılıyor ve performansın diğer müşterilerden etkilenmemesi gerektiği söyleniyor. Linux VPS materyalinde AVA daha da ileri giderek aynı host üzerindeki başka bir tenant'ın CPU-intensive workload'unun sizin instance'ınıza steal time ekleyemeyeceğini belirtiyor. Başka bir sayfada CPU steal'in hypervisor seviyesinde ortadan kaldırıldığı yazıyor.

Bunlar oldukça spesifik iddialar. Yalnızca 1 vCPU yazıp CPU'nun nasıl paylaştırıldığını açıklamayan sıradan bir VPS sayfası değildi. AVA, Linux'un VM'im içinde rapor ediyor gibi göründüğü CPU contention türüne karşı açıkça koruma sunduğunu söylüyordu.

CPU steal ne anlama geliyor

steal, sanallaştırılmış ortamlarda Linux'un kullandığı normal bir CPU metriğidir. Guest'in çalıştırılabilir işi olmasına rağmen virtual CPU'nun gerçekten çalışmadığı süreyi gösterir.

Bu, uygulamamın yalnızca mevcut CPU'nun tamamını kullanmasından farklıdır. Yaklaşık %100 user/system, %0 steal ve %0 idle görseydim, workload'un yalnızca daha fazla işlem gücüne ihtiyaç duyduğu sonucuna varırdım.

Burada ise CPU zamanının yaklaşık üçte biri steal olarak kaydediliyordu.

Guest içinden AVA'nın hypervisor'ını göremem. Physical node yükünü, komşu VM sayısını, CPU pinning politikasını veya overcommit oranını bilmiyorum. Görebildiğim şey Linux'un VM'ime bildirdiği durum: çalıştırılacak işler beklerken vCPU tekrar tekrar çalışmıyordu.

Bu tek saniyelik bir sıçrama değildi

Tek bir kötü CPU sample beni ikna etmezdi. Bu yüzden makineyi 60 saniye boyunca kesintisiz ölçtüm. Bilerek stress test, sentetik HTTP flood veya disk benchmark çalıştırmadım.

Saniyelik örnekler tekrar tekrar şöyle görünüyordu:

%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

Gözlemin sonlarına doğru da aynı desen devam ediyordu:

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

Tüm sürenin ortalaması:

user:       52.52%
system:      8.07%
softirq:     6.69%
steal:      32.73%
iowait:      0.00%
idle:        0.00%

Yani bu kısa süreli bir scheduling anomaly değildi. Dakikanın büyük bölümünde steal yaklaşık %30 veya üzerinde kaldı, CPU idle ise sıfırdı.

Ölçeği anlamak için, bir dakikanın %32,73'ü yaklaşık 19,64 saniyedir. Bu, VPS'in art arda 19,64 saniye donduğu anlamına gelmez; vCPU'nun schedule edilmediği kısa sürelerin toplamı yaklaşık bu değere ulaştı.

Backend kuyruğu eritemiyordu

CPU sorunu uygulama seviyesinde de görünüyordu. Gözlem öncesinde backend listen queue:

Recv-Q: 168
Send-Q: 511

60 saniye sonra:

Recv-Q: 166
Send-Q: 511

Kesin sayıların kendisi önemli değil. Önemli olan kuyruğun neredeyse hiç boşalmaması. Uygulamanın toparlanmak için tam bir dakikası vardı ama yine de geride kaldı.

Ayrıca çok sayıda CLOSE-WAIT bağlantısı vardı. Yalnızca bu durum nedeniyle host'u suçlamam; uygulama tarafındaki connection handling de buna yol açabilir. Ancak genel tablo tutarlıydı:

1 vCPU
32.73% steal
0% idle
~99% CPU pressure
elevated runnable queue
backend queue not draining

Sunucu çalışıyordu ama sağlıklı değildi.

RAM ve disk bariz darboğazlar değildi

Yaygın alternatifleri de kontrol ettim. Bellek:

RAM total:      ~1.9 GiB
RAM available:  ~959 MiB
Swap total:     2 GiB
Swap used:      ~33 MiB

Hâlâ kayda değer miktarda bellek mevcuttu ve davranışı açıklayacak belirgin bir OOM olayı yoktu.

Dosya sistemi:

24 GB total
14 GB used
9.4 GB available
60% used

Ortalama CPU I/O wait 0.00% idi. Buna karşılık CPU pressure yaklaşık %99'da kalıyor, tek-vCPU VM'de load average yaklaşık 3,5–4 seyrediyor ve runnable queue 11'e ulaşıyordu.

Tüm ölçümler aynı yönü gösteriyordu: makine CPU zamanı açısından yetersiz kalıyordu; RAM veya storage nedeniyle bariz biçimde tıkanmış değildi.

AVA'nın söylemiyle çelişki

Bence hikâyenin en ilginç kısmı bu.

AVA “Guaranteed resources — no sharing” diyor. Performansın diğer müşterilerden etkilenmemesi gerektiğini söylüyor. Linux VPS materyali başka bir tenant'ın steal time oluşturamayacağını, başka bir sayfa ise CPU steal'in hypervisor seviyesinde ortadan kaldırıldığını belirtiyor.

Benim AVA VPS'im ise şunu gösteriyordu:

Average CPU steal: 32.73%

VM içinden bunun tam olarak neden olduğunu kanıtlayamam. Kasıtlı overselling'i kanıtlayamam, belirli bir komşu workload'u işaret edemem veya AVA'nın host tarafındaki CPU yapılandırmasını yeniden oluşturamam.

Ayrıca tüm AVA Hosting VPS'lerinin böyle davrandığını da söylemiyorum. Tek bir VPS test ettim.

Ancak ölçtüğüm davranışın bu spesifik CPU izolasyonu iddialarıyla bağdaştırılmasının çok zor olduğunu söyleyebilirim. Bu yazı için bu kadarı yeterli.

Neden upgrade etmedim

En bariz çözüm daha fazla vCPU satın almak olurdu.

VPS neredeyse sıfır steal gösteriyor ve uygulamam gerçekten tek core'un tamamını tüketiyor olsaydı upgrade mantıklı olurdu. Fakat gözlemlediğim CPU zamanının yaklaşık üçte biri steal idi.

İlk vCPU'nun execution time'ının bu kadar büyük bir bölümü zaten unavailable olarak raporlanırken nedenini anlamadan ek virtual CPU için para ödemek istemedim. Bu yüzden VPS'i iptal edip refund istedim.

AVA tüm parayı hızlıca iade etti

Deneyimin bu kısmı iyiydi.

AVA Hosting tutarın tamamını geri ödedi. Refund hızlı işlendi ve CPU ölçümlerim hakkında günlerce tartışmadılar. Sorunu anlattım, paramı geri istedim ve iade ettiler.

Bunu takdir ediyorum.

Dolayısıyla deneyimimden iki ayrı sonuç çıkıyor: aldığım VPS'te ciddi bir CPU erişilebilirliği sorunu vardı ve AVA refund sürecimi doğru şekilde yönetti. İkisi de doğru.

Bu deneyimden ne öğrendim

Artık bir VPS'i yalnızca 1 vCPU / 2 GB RAM / NVMe / KVM gibi özelliklere bakarak değerlendirmiyorum. Bu rakamlar neyin provision edildiğini gösterir; gerçek workload altında CPU'nun ne kadar öngörülebilir biçimde kullanılabileceğini göstermez.

Yeni bir VM'de artık ilk kontrollerimden bazıları şunlar:

mpstat 1 60
vmstat 1 60
cat /proc/pressure/cpu
ss -ltnp
free -h
df -h
iostat -xz 1 60

AVA Hosting deneyiminden çıkardığım en yararlı ders, tek vCPU'nun mutlaka yetersiz olduğu değil. Çalışan bir process, kullanılabilir RAM ve sağlıklı görünen bir disk, altında bambaşka bir problemi gizleyebilir.

Benim durumumda Linux bunu oldukça net gösterdi:

CPU steal:    32.73%
CPU idle:      0.00%
CPU pressure: ~99%

AVA Hosting CPU kaynaklarını sharing olmadan sunduğunu ve komşu workload'lardan kaynaklanan steal'in olmaması gerektiğini söylüyor. Benim VPS'im farklı bir tablo raporladı.

VPS'i iptal ettim. AVA tüm paramı hızlıca ve tartışmadan geri verdi.

Bu debugging günü de böyle sona erdi.