VDS Neden Yavaşlar? Steal, I/O Wait ve Load Average Yorumu

VDS yavaşladığında ilk iş, işlemlerin neyi beklediğini bulmaktır. top çıktısının CPU satırında us ve sy yüksekse işlemci gerçekten çalışıyordur, wa yüksekse işlemler diski bekliyordur, st yüksekse sanal makineniz işlemci istediği hâlde hipervizörden alamıyordur. Load average tek başına teşhis koymaz, çünkü Linux çalışmaya hazır işlemlerin yanında disk bekleyen (D durumundaki) işlemleri de sayar. Sırayla top, vmstat 1, iostat -x ve pidstat ile ilerleyin, sistem tarafı temiz çıkarsa yavaş sorgu günlüğüne inin.

top çıktısının üst kısmını okumak

Çoğu teşhis, top açıldığında görünen beş satırda başlar ve orada biter. Varsayımsal senaryo: 4 vCPU'lu bir VDS'te öğleden sonra sayfalar ağırlaşıyor ve top şunu gösteriyor.

top - 14:02:11 up 41 days,  3:12,  1 user,  load average: 7.84, 6.10, 4.25
Tasks: 212 total,   3 running, 208 sleeping,   0 stopped,   1 zombie
%Cpu(s): 12.3 us,  4.1 sy,  0.0 ni, 21.5 id, 61.7 wa,  0.0 hi,  0.4 si,  0.0 st
MiB Mem :   7940.2 total,    312.4 free,   5120.8 used,   2507.0 buff/cache
MiB Swap:   2048.0 total,   1830.5 free,    217.5 used.   2410.6 avail Mem

CPU satırındaki kısaltmalar, işlemci zamanının nereye gittiğini yüzde olarak verir. us uygulamaların (PHP, veritabanı) kendi kodunu çalıştırdığı süre, sy çekirdeğin çalıştığı süredir. ni önceliği düşürülmüş işlemlere, id boşta geçen zamana aittir. wa, işlemcinin yapacak başka işi yokken G/Ç'nin tamamlanmasını beklediği süredir. hi ve si donanım ve yazılım kesmelerine harcanan zamanı gösterir. st (steal) ise man sayfasındaki tanımıyla hipervizörün bu sanal makineden "çaldığı" zamandır.

Örnekteki tablo nettir: load average 7,84 ile vCPU sayısının neredeyse iki katı, ama işlemci zamanının %61,7'si G/Ç beklemesine gidiyor. Bu sunucunun derdi işlemci değil, disk tarafında bir şey. vCPU eklemek burada hiçbir şeyi düzeltmezdi.

top açıkken 1 tuşuna basın. Her vCPU ayrı satırda görünür. Bir vCPU %100'e yapışmış, diğerleri boşta duruyorsa tek iş parçacığıyla çalışan bir iş (uzun bir içe aktarma, tek bir ağır sorgu, döngüye girmiş bir betik) sunucuyu tıkıyordur. Bu tabloda da çekirdek eklemek işe yaramaz. vCPU ile fiziksel çekirdek arasındaki ilişkiyi vCPU'nun thread ve çekirdekle ilişkisini anlattığımız yazıda bulabilirsiniz.

Load average neden yanıltabilir?

VDS seçim rehberimizde load average'ı çekirdek sayısına bölerek yorumlamayı önerdik: 4 vCPU'da 4,0 tam dolu demektir. Bu kural, yük çalışmaya hazır işlemlerden geliyorsa doğrudur. Linux'un /proc/loadavg belgesi ise başka bir ayrıntı veriyor: değer, çalışma kuyruğundaki (R durumu) işlemlerle birlikte disk G/Ç'si bekleyen (D durumu) işlemleri de 1, 5 ve 15 dakikalık ortalamalarla sayar. Bu yüzden yüksek bir load average işlemcinin yetmediğini de, diskin yetişemediğini de anlatabilir. Bölme kuralını VDS seçerken CPU, disk ve ağ ihtiyacını hesaplama yazısında nasıl kullandığımıza bakarsanız koşulun aynı olduğunu görürsünüz: işlemci kaynaklı yük.

Ayrımı yapmak için o anda D durumunda bekleyen işlemleri listeleyin:

ps -eo state,pid,user,comm | awk '$1 ~ /^D/'

Liste kalabalıksa ve mysqld, yedek aracı ya da php-fpm işçileri burada görünüyorsa yük diske takılmış demektir. Liste boş ya da kısa, us ve sy yüksekse yük gerçekten işlemcidedir. Üç ortalamayı birlikte okuyun: 1 dakikalık değer 15 dakikalığın çok üzerindeyse sorun yeni başlamış ve büyüyordur, tersi ise geçmekte olan bir dalgayı gösterir.

vmstat 1 ile saniye saniye izlemek

top anlık bir fotoğraftır. vmstat 1 ise saniyede bir satır yazarak kısa bir film çeker:

procs -----------memory---------- ---swap-- -----io---- -system-- ------cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 1  6 222720 318400  10240 2556000    0    0 18420   960 2150 3900 11  4 22 63  0
 2  5 222720 309112  10240 2561200    0    0 17890  1012 2088 3815 12  4 21 63  0

İlk satır açılıştan bu yana ortalamadır, onu atlayın. Sonraki satırlarda beş sütuna bakın. r, çalışan ya da işlemci sırası bekleyen işlem sayısıdır ve nproc çıktısındaki vCPU sayısını sürekli aşıyorsa işlemci kuyruğu var demektir. b, G/Ç'nin bitmesini bekleyen engellenmiş işlemleri sayar. si ve so takastan okunan ve takasa yazılan belleği gösterir. wa ve st ise top'taki karşılıklarıyla aynıdır. Yeni procps sürümlerinde sonda gu (KVM misafir kodu) sütunu da görebilirsiniz.

Örnekte b sürekli 5–6, bi (blok cihazdan okunan) yüksek, si/so sıfır. Yani bir şey diskten yoğun okuma yapıyor ve takas sorunun parçası değil. si ve so sürekli sıfırın üzerinde olsaydı hikâye değişirdi: bellek yetmiyor, sistem takasa yaslanıyor ve disk beklemesi bunun sonucu olurdu. O durumda iz, bellek baskısının sonunda çekirdeğin bir işlemi sonlandırmasıyla biten OOM olaylarına kadar uzanabilir.

Steal: sorun sizde mi, altyapıda mı?

Steal, sanal makinenizin işlemci istediği ama alamadığı zamandır. İçeriden düşürülemez, çünkü hipervizör düzeyinde oluşur. Okurken şu ölçütü kullanın: %0–1 normaldir, yoğun saatlerde sürekli %5'in üzerinde seyreden steal ise fiziksel sunucuda işlemci rekabeti olduğunu gösterir. Tek seferlik, birkaç saniyelik sıçramalar tek başına teşhis değildir.

Kaynakları ayrılmış bir VDS'te yoğun saatlerde sürekli yüksek steal beklenen bir durum değildir. Netx VDS'te paketteki vCore ve RAM size ayrılmış kaynak olarak tanımlanır, bu yüzden böyle bir tablo görürseniz tahmin yürütmek yerine kanıt toplayıp bize iletin. Zaman damgalı bir kayıt yeterlidir:

vmstat -t 1 600 > steal-$(date +%Y%m%d-%H%M).txt

-t her satırın sonuna saat ekler. Komut on dakika boyunca saniyelik kayıt alır. Kayda, aynı aralıktaki kendi yükünüzü de not edin: steal yalnız sizin işlemciyi tamamen doldurduğunuz anlarda mı artıyor, yoksa sunucunuz sakinken de mi görünüyor? İkinci durum altyapı tarafını işaret eder.

I/O wait: diski kim meşgul ediyor?

Yüksek wa, "disk yavaş" demek değildir. İşlemlerin G/Ç beklediğini ve işlemcinin bu sırada yapacak başka işi olmadığını söyler. Beklemenin kaynağı çoğu zaman şu dört yerden biridir: belleğe sığmayan veritabanı sorguları, yoğun saate denk gelen yedek ya da sıkıştırma, takas, uzun bir dosya işlemi (log döndürme, toplu görsel işleme, dosya indeksleme).

iostat -x ile diskin kendisi

iostat -x 1 5

Komut sysstat paketiyle gelir. Cihaz satırlarında şu sütunlara bakın: r/s ve w/s saniyedeki okuma ve yazma isteği, r_await ve w_await bir isteğin kuyruk dahil milisaniye cinsinden ortalama süresi, aqu-sz ortalama kuyruk uzunluğudur (eski sürümlerde avgqu-sz adıyla geçer).

%util sütununa güvenmeyin. sysstat belgesi, isteklere paralel hizmet veren cihazlarda, yani RAID dizileri ve modern SSD'lerde, bu yüzdenin performans sınırını yansıtmadığını açıkça yazıyor. NVMe bir disk %100 %util gösterirken hâlâ rahatça yeni istek kabul ediyor olabilir. Daha anlamlı ölçü await değerleri ile aqu-sz'dir. NVMe diskte await'in normalde milisaniyenin altında kalması beklenir. Yük altında sürekli yükselen bir await, kuyruğun uzadığını gösterir. Disk teknolojisinin bu davranışa etkisini NVMe ve SATA SSD'nin kuyruk farkını anlattığımız yazıda bulabilirsiniz.

pidstat ile suçlu işlem

Diskin meşgul olduğunu bilmek yetmez, kimin meşgul ettiğini bulmak gerekir:

pidstat -d 5 3

Çıktıda işlem başına kB_rd/s ve kB_wr/s değerleri ile iodelay sütunu görünür. iodelay, işlemin blok G/Ç'si yüzünden beklediği süreyi saat tıkı (clock tick) cinsinden verir ve en çok bekleyen işlemi gösterir. Sıklıkla karşılaşılan tablo: listenin başında yedek aracı ya da mysqld olur. Yedekse zamanlamasını değiştirin. Veritabanıysa sıra yavaş sorgu günlüğündedir. Diskin donanım olarak beklediğiniz performansı verip vermediğini ayrıca ölçmek isterseniz yöntem fio ile disk performans testi yazısında.

İşlemci tarafında da aynı aracı kullanabilirsiniz. pidstat -u 5 3 çıktısındaki %wait sütunu, bir işlemin çalışmaya hazır olduğu hâlde işlemci sırası beklediği zamanın yüzdesidir. Pek çok işlemde birlikte yükseliyorsa işlemci kuyruğu gerçektir.

Yavaşlık geçtiyse: sar ile geçmişe bakmak

Sık yaşanan durum şu: şikâyet gelir, siz bağlandığınızda her şey normaldir. Geçmiş veri yoksa tahminden öteye gidemezsiniz. sysstat'ın veri toplayıcısı açıksa sar geçmişe dönük okuma yapar:

sar -u -f /var/log/sa/sa28 -s 13:00:00 -e 15:00:00
sar -q -f /var/log/sa/sa28 -s 13:00:00 -e 15:00:00
sar -d -f /var/log/sa/sa28 -s 13:00:00 -e 15:00:00

İlk komut işlemci dağılımını (%iowait ve %steal dahil), ikincisi çalışma kuyruğunu ve load average'ı, üçüncüsü disk istatistiklerini verir. Dosya adındaki sayı ayın gününü gösterir. RHEL ailesinde (AlmaLinux, Rocky Linux) dosyalar /var/log/sa/ altında durur. Debian ve Ubuntu'da yol /var/log/sysstat/'tır ve Debian belgesine göre toplama, /etc/default/sysstat dosyasında ENABLED="true" yapılana kadar kapalıdır. Toplama aralığı yaygın paketlerde 10 dakikadır, kendi sunucunuzdaki değeri systemctl cat sysstat-collect.timer gösterir. Birkaç dakikalık bir sıçrama bu ortalamada silikleşebilir, o yüzden sar'ı yön bulmak için kullanın.

Belirti, neden, kontrol ve çözüm tablosu

Sistem temizse uygulamaya inin

İşlemci boşta, disk sakin, takas yok ama sayfalar yine geç açılıyorsa bekleme sunucunun dışında ya da uygulamanın içindedir. İki günlük çoğu zaman cevabı verir.

MySQL ve MariaDB'de yavaş sorgu günlüğü varsayılan olarak kapalıdır ve long_query_time varsayılanı 10 saniyedir. Web isteklerinde sorun yaratan sorgular çoğu zaman bunun çok altında kalır, eşiği kısa süreliğine düşürün:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Yeni eşik, ayardan sonra açılan bağlantılarda geçerli olur. Birkaç yoğun saat topladıktan sonra mysqldumpslow ile günlüğü özetleyin ve en çok zaman yiyen sorgu kalıplarına bakın. İş bitince SET GLOBAL slow_query_log = 'OFF'; ile kapatın. SET GLOBAL ile yapılan değişiklik servis yeniden başladığında zaten kaybolur, kalıcı yapmak istemiyorsanız ayar dosyasına dokunmanız gerekmez.

PHP tarafında havuz ayarına request_slowlog_timeout = 5s ve bir slowlog yolu eklediğinizde, 5 saniyeyi aşan her istek için PHP yığın izi (backtrace) günlüğe düşer. Hangi eklentinin, hangi fonksiyonun ya da hangi dış çağrının beklediği orada görünür. Havuzu yeniden yükledikten sonra etkinleşir. İnceleme bitince satırları kaldırın.

Site Cloudflare arkasındaysa aşırı yüklenen kaynak sunucu ziyaretçiye Cloudflare 522 bağlantı zaman aşımı olarak da yansıyabilir. Yavaşlık yalnız kampanya günlerinde geliyorsa sorunu canlıda beklemek yerine kampanya öncesinde yük testiyle önceden üretmek çok daha az can yakar. Sunucuya çok sayıda site yerleştirdiyseniz site başına bellek ve işlemci kapasitesini yeniden hesaplamak da gerekebilir.

Düzeldiğini nasıl anlarsınız?

Değişikliği yaptıktan sonra aynı ölçümleri aynı saat diliminde tekrarlayın. Sabah yapılan ölçüm, öğleden sonraki sorunu kanıtlamaz. Karşılaştırmayı kolaylaştırmak için kullanıcı tarafındaki süreyi de sayıya dökün:

for i in $(seq 1 10); do
  curl -o /dev/null -s -w '%{time_starttransfer}\n' https://ornek.com.tr/
done

Komut ilk baytın gelme süresini on kez saniye cinsinden yazar. Önbellekten dönen bir sayfa yerine sorunlu sayfayı (arama, sepet, yönetim paneli) ölçmek daha anlamlıdır. Düzeltme işe yaradıysa yoğun saatte wa ya da r belirgin biçimde düşmüş, FPM ve yavaş sorgu günlüklerindeki satırlar seyrelmiş olmalı. Değişmediyse darboğaz başka yerdedir, tabloya geri dönün.

Destek ekibine ne zaman ve neyle yazmalı?

Steal yoğun saatlerde sürekli yüksekse ya da pidstat -d sizin tarafınızda kayda değer G/Ç göstermezken await değerleri uzuyorsa sorun büyük olasılıkla sanal makinenin dışındadır. Netx müşteri panelinden destek talebi açarken şunları ekleyin:

• Sunucunun IP adresi ve hizmet adı
• Sorunun başladığı ve bittiği saat aralığı (saat dilimini belirterek)
• vmstat -t 1 kaydı ve aynı aralıktan iostat -x 1 çıktısı
• top ekranının metin hâli ve vCPU sayısı
• O aralıkta sunucuda çalışan yedek, güncelleme ya da toplu iş
• Son yaptığınız yapılandırma değişiklikleri

Ölçümler kaynağın gerçekten yetmediğini gösteriyorsa yükseltme kararı artık tahmine değil veriye dayanır. Hazır paketleri ve ayrılmış vCore ile RAM ayrıntısını VDS sunucu sayfasında bulabilirsiniz. İzlemeyi, kayıt toplamayı ve bu tür ayarları sürekli yürütecek kimse yoksa işi sunucu yönetimi hizmetine devretmek de bir seçenektir. Neyin dahil olduğu teklif aşamasında yazılı olarak netleşir.