Bunu FDCServers hakkında olumsuz bir inceleme olarak yazmıyorum. İnsanlara buradan VPS alıp almamaları gerektiğini söylemeye de çalışmıyorum. Elimde bir sunucu, bir workload ve belirli bir problem dizisi var. Bunlar bütün bir hosting şirketini yargılamak için yeterli değil.
Bu sadece geliştirici olarak günlük hayatımdan bir olay. VPS bir süre normal çalıştı ve 3 TB'tan fazla trafik aktarmıştı. Daha sonra sıradan workload ciddi gecikmeler üretmeye başladı. Sayfalar çok uzun sürede cevap verebiliyor veya tamamen timeout olabiliyordu. İlk şüpheliler her zamanki şeylerdi: application, Nginx, memory, network, connection limitleri veya aşırı yük. Linux metrics başka bir yeri işaret ediyordu.
VPS en başından beri yavaş değildi
Olaylar arasında makine tamamen sağlıklı görünebiliyordu. Normal bir dönemde D-state içinde process yoktu, CPU iowait yaklaşık %0, disk latency yaklaşık 2–4 ms ve I/O PSI neredeyse sıfırdı:
D-state processes: 0
CPU iowait: ~0%
disk latency: ~2–4 ms
I/O PSI some: 0.04
I/O PSI full: 0.04Sadece o anda bağlanıp top, free -h, df -h ve systemctl status nginx kontrol etseydim, büyük ihtimalle VPS'in normal olduğuna karar verirdim. Sonra normal workload geri geldi ve makinenin durumu dramatik biçimde değişti.
18,7 saniyelik okumalar incelemenin yönünü değiştirdi
En güçlü iostat örneklerinden biri şöyleydi:
r_await = 18744 ms
f_await = 53561 ms
aqu-sz = 128.54
util = 100.10%
read = 88 KB/sBu sayıları birlikte değerlendirmek gerekiyor. Tamamlanan okumaların ortalama latency değeri yaklaşık 18,7 saniyeydi. Flush latency yaklaşık 53,6 saniyeydi. Ortalama I/O queue 128'in üzerindeyken yararlı read throughput sadece 88 KB/s idi. Bu, çok veri taşıdığı için meşgul olan sıradan bir disk değildi. Storage path operasyonların tamamlanmasını bekleyerek çok büyük zaman harcıyordu.
iowait ve PSI sistem çapındaki I/O pressure'ı gösterdi
En kötü dönemlerde vmstat 4–9 blocked process, CPU iowait yaklaşık %97–100 ve CPU idle %0 gösteriyordu. iowait, application'ın tüm CPU'yu kullandığı anlamına gelmez. Yararlı işin outstanding I/O'nun tamamlanmasını beklediği anlamına gelir.
Linux Pressure Stall Information tabloyu daha da netleştirdi:
I/O PSI some avg10 = 99.14
I/O PSI full avg10 = 95.55Daha sonraki tekrar testlerinde full %98'e yaklaştı. Disk utilization device'ın meşgul olduğunu söyler; PSI ise workload'un bu resource nedeniyle gerçekte ne kadar stall olduğunu gösterir. %95–98 civarında sürekli I/O pressure küçük bir performans düşüşü değildir.
D-state ve kernel stack'leri application katmanının altını gösterdi
Daha sonra hangi process'lerin blocked olduğuna baktım. Aynı anda jbd2, systemd-journald, Nginx worker'ları, Nginx cache process'leri ve başka filesystem aktiviteleri D-state içindeydi. Sadece application takılsaydı application'ı incelerdim. Nginx, system journal ve EXT4 journal aynı anda bloklanıyorsa storage en belirgin ortak bağımlılıktır.
EXT4 journaling path'lerinde şunlar vardı:
wait_on_buffer
jbd2_log_wait_commit
jbd2_journal_commit_transactionNginx worker'ları normal file read işlemlerinde bekliyordu:
folio_wait_bit_common
filemap_read
generic_file_read_iter
ext4_file_read_iter
vfs_read
pread64Bir noktada kernel bir Nginx task'ının 122 saniyeden uzun süredir blocked olduğunu bildirdi. Nginx hâlâ active görünebiliyordu, fakat bu worker'larının yararlı işi tamamlayabildiği anlamına gelmiyordu. running ile sağlıklı olmak farklı durumlardır.
3 ms'lik backend cevabı application ile filesystem path'i ayırdı
En temiz karşılaştırma Nginx ile local application backend arasındaydı. Nginx üzerinden gelen request'ler connection veya TLS timeout ile HTTP=000 dönüyordu. Backend'e doğrudan gönderilen request ise yaklaşık 3 ms'de tamamlandı:
connect = 0.000423 s
TTFB = 0.003063 s
total = 0.003139 sBu test için exact HTTP status önemli değildi. Backend connection'ı aldı, request'i işledi ve neredeyse anında response üretti. Aynı sırada Nginx worker'ları EXT4 read bekliyordu. Bu, application'ın normal execution'ı ile önündeki filesystem-dependent path'i birbirinden ayırdı.
Problem tekrar üretilebiliyor ve yeniden kaybolabiliyordu
Bir tekrar testinden önce makine normal görünüyordu:
HTTP: 200
D-state: 0
CPU iowait: 3%
r_await: ~1.18 ms
I/O PSI full: ~2.95%Yaklaşık yarım dakika sonra:
D-state: 4
CPU iowait: 91%
CPU idle: 0%
I/O PSI some: 86.11%
I/O PSI full: 78.02%
r_await: 236.50 ms
HTTP: 000Daha sonra CPU iowait %96–100'e, I/O PSI full yaklaşık %98'e, HTTPS queue 512'ye ulaştı ve HTTP kontrolleri başarısız olmaya devam etti. Bu, VPS yavaş hissettiriyor demekten çok daha yararlı bir kanıttı.
Workload kaldırıldığında ters değişim de hızlı olabiliyordu:
D-state: 0
CPU iowait: 6%
r_await: ~0.98 ms
queue depth: ~0.07
HTTP: 200Bu nedenle intermittent storage problemlerini olay geçtikten sonra incelemek zordur. Provider recovery sonrasında sunucuya bakıp gerçekten normal latency görebilir. Ancak bu, on dakika önce ne olduğunu açıklamaz. Exact UTC timestamp'ler bu yüzden kritik hâle geldi.
Yanıltıcı olabilen iki metric: await=0 ve boş disk alanı
Bazı kötü interval'larda r_await = 0 görüyordum; buna karşın iowait yüksek, process'ler D-state içinde, request'ler in-flight ve tamamlanan read neredeyse yoktu. Latency istatistikleri tamamlanmış I/O üzerine kurulur. Operation sampling interval içinde tamamlanmazsa tamamlanmış operation'ların average latency değerine giremez. Bu nedenle sıfır her zaman anlık disk anlamına gelmez.
Disk fullness ihtimalini de düşündüm. Daha sonra filesystem normalde izin vereceğimden daha dolu hâle geldi, ancak aynı failure tipi root filesystem yalnızca yaklaşık %24 doluyken de yaşanmıştı. O sırada yaklaşık 1,2 GiB RAM available, inode usage yaklaşık %5'ti ve network interface error veya dropped packet göstermiyordu. Disk fullness bütün olayı açıklayamıyordu.
Neyi kanıtlayabildim, neyi kanıtlayamadım
VPS içinden application, Linux VFS, EXT4 ve virtual block device'ı görebiliyordum. Sonrasında provider'ın infrastructure'ı başlıyor: virtualization, distributed storage, storage network, fiziksel cihazlar, scheduling ve guest içinden inceleyemediğim başka katmanlar.
Dolayısıyla belirli bir physical SSD'nin bozuk olduğunu veya belirli bir storage node, network path ya da virtualization component'ın root cause olduğunu dürüstçe söyleyemem.
Söyleyebildiğim şey daha dar kapsamlı ama güçlü biçimde destekleniyor: Linux guest'ime sunulan virtual storage path tekrar tekrar, normal filesystem I/O'nun saniyeler sürdüğü veya makul süre içinde tamamlanmadığı durumlara girdi. Kanıtlar iostat, PSI, D-state, kernel wait stack'leri, EXT4/jbd2 wait'leri, Nginx filesystem wait'leri, queue depth ve request timing'lerinden geldi. İhtiyacım olan engineering diagnosis için yeterliydi, fiziksel root cause için değildi.
Önceki 3 TB'tan fazla trafik neden sonraki stall'larla çelişmiyor
Başta bu konu beni şaşırtmıştı. Storage problemliyse VPS daha önce birkaç terabyte veriyi nasıl başarılı biçimde aktardı?
Çünkü network traffic ile physical disk I/O aynı şey değildir. Bir dosya backing storage'dan bir kez okunup Linux page cache içinde kalabilir, sonra memory'den defalarca servis edilebilir. Network üzerinden üç terabyte aktarılmış olması üç terabyte unique physical disk read anlamına gelmez.
Infrastructure koşulları da zamanla değişir: cache state, storage load, queueing, host placement ve diğer workload'lar değişebilir. VPS'in dün normal çalışması storage'ın bugün tamamen aynı davranacağını garanti etmez.
Sonunda daha derin bir root cause beklemeyi bıraktım
Exact timestamp'ler, vmstat, iostat, PSI, blocked-process snapshot'ları, kernel stack'leri, filesystem wait'leri, queue depth ve HTTP timing'leri topladım. Diagnostics'i FDCServers'a gönderdim ve infrastructure seviyesinde daha derin bir açıklama bekledim.
Uzun süre bekledim. Sonunda bıraktım. Kendi tarafımda operational karar vermek için yeterince şey biliyordum: problem reproducible ve ciddiydi, application layer'ın altında görünüyordu ve fiziksel nedeni VPS'imin visibility alanının dışındaydı.
Refund istedim ve FDCServers parayı iade etti
FDCServers'a sorunların ve topladığım diagnostics'in özetini gönderdim, service'in iptalini ve refund talep ettim. Paramı iade ettiler.
Yani bu hikâye para için uzun bir kavgayla bitmedi. Kesin teknik açıklamayı bekledim, daha fazla beklemek istemediğime karar verdim, elimdeki kanıtları gönderdim ve paramı geri istedim. FDCServers iade etti.
Bundan sonra neyi değiştirdim
Bu deneyimin yararlı sonucu bir hosting şirketinin iyi mi kötü mü olduğuna karar vermek değildi. Yavaş Linux sunucuları debug etme biçimimi değiştirdi.
top, free -h ve df -h hâlâ kullanıyorum, fakat artık çok daha erken şunlara bakıyorum:
date -u
uptime
cat /proc/pressure/io
cat /proc/pressure/memory
cat /proc/pressure/cpu
vmstat 1 10
iostat -x 1 10
ps -eo state,pid,ppid,etime,wchan:50,comm,args | awk 'NR==1 || $1 ~ /^D/'
ss -lntp
journalctl -k --since '30 min ago' --no-pagerMümkün olduğunda request path'lerini de ayrı test ediyorum: public request, local Nginx, direct backend, filesystem ve block-device metrics. Soru artık yalnızca sunucunun neden yavaş olduğu değil. Soru şu: yararlı iş hangi katmanda tamamlanmayı bırakıyor?
Mümkün olduğunda reboot öncesinde kanıtları kaydediyorum. Reboot service'i geri getirebilir ama intermittent incident'ı teşhis etmeyi sağlayan D-state, PSI, queue ve latency bilgilerini de silebilir.
Son düşünce
FDCServers VPS'i hosting yazısı için malzeme olsun diye satın almadım. Çok bandwidth sunan bir server istiyordum. Bir süre tam olarak bunu aldım: gerçek workload'u taşıdı ve üç terabyte'tan fazla veri aktardı.
Sonra normal workload tekrar üretilebilir şekilde iowait %100'e kadar, I/O PSI neredeyse %100, read 18,7 saniyeye kadar, flush latency 53 saniyenin üstünde, büyük queue'lar, filesystem read içinde blocked Nginx ve I/O bekleyen EXT4/jbd2 üretmeye başladı.
Hangi fiziksel veya host-side component'ın buna neden olduğunu hiçbir zaman öğrenmedim ve biliyormuş gibi davranmam gerekmiyor. Failure'ın ortaya çıktığı katmanı belirledim, application probleminden ayırmaya yetecek kanıtı topladım, daha derin root-cause açıklamasını beklemeyi bıraktım ve paramı geri istedim. FDCServers refund yaptı.
Bu, tüm FDCServers VPS'leri hakkında bir hüküm değil. Bir service active, bir process running görünebilirken makinenin yararlı zamanının neredeyse tamamını storage bekleyerek geçirebileceğini gösteren iyi belgelenmiş tek bir örnek.