Bunu REGXA hakkında olumsuz bir inceleme yazmak için kaleme almıyorum ve kimseye onlardan VPS alıp almaması gerektiğini söylemeye çalışmıyorum. Bu, geliştirici olarak yaşadığım sıradan günlerden sadece biri.
2 vCPU, 2 GB RAM ve 60 GB NVMe sunan bir KVM VPS'e normal bir workload taşıdım. Nginx çalışıyordu. Backend çalışıyordu. Buna rağmen makine aşırı yüklenmiş gibi davranıyordu: istekler birikiyor, TLS işlemleri yavaşlıyor, bağlantılar açık kalıyor ve bazı istekler iki dakikadan uzun süre sonra HTTP 504 ile sonuçlanıyordu.
CPU muhasebesi araştırmanın yönünü değiştirdi
İlk varsayımım açıktı: VPS'in içindeki bir şey CPU'yu tüketiyordu. Ardından mpstat çalıştırdım.
Average CPU steal: 92.58%
CPU 0 steal: 90.62%
CPU 1 steal: 94.57%
CPU user: 4.02%
CPU system: 1.47%
CPU iowait: 0.41%
CPU idle: 0.53%Tek tek örneklerde tekrar tekrar yaklaşık %89–98 steal görülüyordu. CPU pressure da aşırı yüksekti:
CPU PSI some avg10: 79.47
CPU PSI some avg60: 75.32
CPU PSI some avg300: 76.31
Load average: 5.85 / 5.75 / 5.73Bu yalnızca iki vCPU'lu bir makineydi. Linux'ta CPU bekleyen runnable process'ler vardı. Önemli sayı normal application CPU kullanımı değil, %steal idi.
Yüksek CPU kullanımı ile CPU steal farklı sorunlardır
Uygulamam gerçekten processor'ı tüketiyor olsaydı user veya system değerlerinin yüksek olmasını beklerdim. Bunun yerine VPS yaklaşık şöyle görünüyordu:
user: 4%
system: 1%
steal: 93%CPU steal, virtual CPU'nun çalışmaya hazır olduğu ancak hypervisor tarafından schedule edilmediği süredir. Dolayısıyla VPS'ten CPU time alındığını söylerken bunu sanallaştırmadaki bu teknik anlamda söylüyorum. REGXA'nın yalnızca bana ait fiziksel çekirdekleri kasıtlı olarak başka müşterilere verdiğini kanıtlayamam ve guest metric'lerinden niyet çıkarılamaz. Kanıtlayabildiğim şey, guest'in tekrar tekrar çalışmaya hazır işi olduğu hâlde CPU scheduling time alamamasıdır.
Tüm production trafiğini kaldırdım
Hâlâ makul bir itiraz vardı: belki sorunu workload'um yaratıyordu. Bu değişkeni ortadan kaldırdım. Aktif workload'u başka yere taşıdım, bu VPS'e production trafiğini durdurdum, kuyrukların boşalmasını bekledim ve ölçümü tekrarladım.
Average CPU steal: 94.17%
CPU 0 steal: 95.56%
CPU 1 steal: 92.83%
CPU user: 1.95%
CPU system: 0.59%
CPU iowait: 0.59%
CPU idle: 2.18%Sonuç daha da kötüleşti. Tek tek vmstat örneklerinde hâlâ %91–98 steal vardı ve 15'e kadar runnable process CPU bekliyordu. En önemli kombinasyon şuydu:
user: 1.95%
system: 0.59%
steal: 94.17%Uygulamalarım neredeyse hiçbir şey yapmıyordu, ancak VM scheduling time'ın neredeyse tamamını kaybetmeye devam ediyordu. Normal production yükü artık inandırıcı bir açıklama değildi.
localhost bile absürt derecede yavaşladı
HTTPS'i 127.0.0.1 üzerinden de test ettim; böylece public DNS, ISP'm, coğrafi mesafe ve dış network path testin dışında kaldı.
Trafik varken on localhost HTTPS denemesinin dördü TLS handshake sırasında başarısız oldu. Başarılı istekler 29,30, 22,77, 12,25, 11,87, 11,12 ve 9,40 saniye sürdü. Bazı TLS handshake işlemleri tek başına yaklaşık dokuz saniyeydi.
Production trafiğini kaldırdıktan sonra localhost iyileşti ama kararsız kalmaya devam etti: 0,061, 0,745, 0,830, 0,873, 1,010, 1,117, 1,121, 2,188 ve 3,355 saniye. Aynı local operation bir sefer yaklaşık 61 ms, bir sonraki sefer 3,3 saniyeden fazla sürebiliyordu.
Stack'in geri kalanı sonuçları gösteriyordu
Bir noktada yaklaşık 450 established connection, 122 orphaned connection, 110 FIN-WAIT-1 ve 33 CLOSE-WAIT gördüm. Local backend listen queue yaklaşık 14–15'e, HTTPS queue ise yaklaşık 40'a çıktı.
Nginx 142,857, 138,902, 135,064, 129,819 ve 128,657 saniye sonra HTTP 504 kaydetti. Diğer istekler yaklaşık 67–130 saniye açık kaldı. Yaklaşık 35–41 saniyelik secure-connect timeout, database network timeout ve geciken TLS işlemleri de gördüm.
Tek tek bakıldığında bunlar ayrı Nginx, database, network veya backend sorunları gibi görünebilirdi. Ancak timeout'u artırmak hypervisor'ın schedule etmediği CPU time'ı yaratmaz.
RAM ve disk sorunu açıklamıyordu
VPS'te hâlâ yaklaşık 1,0–1,1 GiB kullanılabilir RAM vardı, swap neredeyse hiç kullanılmıyordu, OOM event veya OOM killer aktivitesi yoktu. Filesystem yalnızca yaklaşık %20 doluydu ve yaklaşık 44 GB boş alan vardı. Önemli CPU ölçümleri sırasında I/O wait %1'in altında kaldı.
Memory tükenmemişti, disk dolu değildi ve uygulamalarım kayıp CPU'yu tüketmiyordu. Baskın metric hâlâ %steal idi.
Sağlıklı bir KVM VPS tamamen farklı görünüyordu
Aynı tür tanı testini normal trafik sunan başka bir KVM VPS'te çalıştırdım:
Average CPU steal: 0.02%
CPU idle: 87.86%
CPU PSI avg10: 0.29
CPU PSI avg60: 0.63
CPU PSI avg300: 0.49
Load average: 0.47 / 0.33 / 0.14On localhost HTTPS isteği yaklaşık 37–69 ms arasında tamamlandı. Daha sonra gerçekten yoğun olan başka bir production VPS'te %61,71 user CPU, %5,08 system CPU, %24,09 idle ve yalnızca %0,13 steal gördüm.
Bugün önem verdiğim ayrım bu. VPS, yazılımım gerçekten processor kullandığı için yoğun olabilir. Bu, guest'in ölçülen CPU time'ın %90'ından fazlasını hypervisor bekleyerek geçirmesinden tamamen farklıdır.
REGXA sonunda altyapıdaki resource contention'ı doğruladı
VM içinden guest'i ölçebiliyordum ancak physical host'u, scheduler yapılandırmasını, CPU quota'larını veya komşu VM'leri göremiyordum. REGXA görebiliyordu.
Support sonunda VPS'in shared CPU infrastructure üzerinde barındırıldığını, CPU resource'larının birden fazla virtual machine arasında paylaşıldığını ve performansın physical node yüküne bağlı olarak değişebileceğini söyledi. Ayrıca Frankfurt infrastructure'ın özellikle yüksek demand yaşadığını ve yükselen CPU steal değerimi açıkça resource contention on the underlying infrastructure ile ilişkilendirdi.
Mevcut altyapıda bu shared VPS için CPU quota veya scheduling policy değiştiremeyeceklerini ve ek dedicated CPU resource tahsis edemeyeceklerini de belirttiler. Önerilen teknik çözüm VPS'i daha düşük utilization olan başka bir location'a taşımaktı.
Bu açıklamayı daha önce gördüğüm dedicated CPU cores ve guaranteed resources ifadeleriyle bağdaştırmak zordu. Host'un kesin yapılandırmasını göremediğim için doğrudan mekanizmanın CPU overcommitment, quota, scheduler weighting, throttling veya bunların birleşimi olduğunu söyleyemem. Niyet de kanıtlayamam. Buna gerek yok: Linux sürekli %92–94 steal gösterdi ve REGXA'nın kendisi bu yüksek değeri shared infrastructure üzerindeki contention'a bağladı.
Refund almak da ekstra ısrar gerektirdi
Altyapı sorunu netleşince VPS'i taşımaya ve başka node'ları denemeye devam etmek istemedim. Service'i iptal edip paramı geri almak istedim.
Başlangıçta yalnızca kısmi bir tutar teklif edildi ve önerilen refund ödeme yaptığım karta değil REGXA hesap bakiyesine aktarılacaktı. Hizmetten ayrılmak isterken provider credit benim için gerçek refund ile aynı şey değildir.
Bu yüzden yanıt vermeye devam ettim ve ödemenin %100'ünün original payment method'a iade edilmesini istedim. Sonunda REGXA kabul etti ve tam tutarı ilk ödeme yöntemine geri gönderdi; full refund'ı bir exception olarak tanımladı.
Sonunda tüm parayı iade etmelerini takdir ediyorum. Ancak support altyapıdaki contention'ı kabul ettikten sonra bile finansal çözüm için ayrıca bastırmak zorunda kalmam da deneyimimin bir parçası.
Bu olaydan çıkardığım ders
En kolay hata uygulamayı optimize etmeye devam etmek olurdu. Nginx'i değiştirebilir, timeout'ları artırabilir, concurrency'yi azaltabilir, retry ekleyebilir, MongoDB'yi inceleyebilir veya backend kodunu yeniden yazabilirdim. Bazı semptomlar değişebilirdi. Hiçbiri asıl soruyu yanıtlamazdı: CPU steal neden %90'ın üzerindeydi?
Artık yalnızca SSH çalışıyor mu, Nginx başlıyor mu ve health endpoint 200 döndürüyor mu diye bakmıyorum. Yeni bir VPS'te %user, %system, %iowait, %idle, %steal, CPU PSI, run queue ve localhost latency'yi de kontrol ediyorum.
Bir şey şüpheli görünürse workload'u kaldırıp tekrar ölçüyorum. Bu olayda en net sonucu bu test verdi:
CPU user: 1.95%
CPU system: 0.59%
CPU steal: 94.17%Her REGXA VPS'in böyle davrandığını iddia etmiyorum. Bir VPS'i test ettim ve o makinede ne olduğunu belgeledim. Ancak o VPS'te kanıt son derece açıktı: uygulamalarım neredeyse hiç CPU tüketmiyordu, buna karşın Linux virtual CPU time'ın büyük çoğunluğunun hypervisor scheduling beklerken kaybolduğunu gösteriyordu. REGXA daha sonra tam olarak bu davranışı shared infrastructure üzerindeki resource contention'a bağladı.
Bu yüzden deneyimi belgeliyorum. Bir puan veya tavsiye olarak değil, bir geliştiricinin hayatındaki sıradan bir gün ve bir VPS'te bir daha asla görmezden gelmeyeceğim bir metric olarak.