Tiesto

Tiesto

WFN Üye
Konular
635
Mesajlar
635
Çözüm
0
Ticaret Puanı
0
Üyelik
24 Gün
Konum
Antalya
Web Sitesi
Var
Alanı
Domain Uzmanı
1/1
Konu sahibi
İlk olarak iostat ile hangi disk aygıtının yoğun olduğunu, ardından iotop veya pidstat ile hangi işlemin okuma-yazma yaptığını izleyin. İşlem adını tek başına görmek yeterli değildir; yazma miktarı, I/O bekleme süresi, ilgili dosya yolu ve işlemin hangi kullanıcıya ait olduğu birlikte değerlendirilmelidir. Böylece sorunun veritabanı, günlük dosyası, yedekleme, log döngüsü veya başka bir servis kaynaklı olup olmadığı anlaşılır.

Önce yoğunluğun gerçekten diskten kaynaklandığını doğrulayın​


Sunucuya SSH ile bağlandıktan sonra aşağıdaki komutu çalıştırın:

Bash: 
iostat -xz 1

Bu komut sysstat paketinin parçasıdır. Paket kurulu değilse dağıtımınızın paket yöneticisiyle sysstat paketini kurmanız gerekir. Komut, disk istatistiklerini bir saniyelik aralıklarla yeniler.

İlk çıktı çoğunlukla sistem açılışından beri biriken ortalamadır; değerlendirmeye başlamadan önce bir sonraki güncellenen satırları izleyin. Özellikle şu sütunlara bakın:
  • r/s ve w/s: Saniyedeki okuma ve yazma işlemi sayısı.
  • rkB/s ve wkB/s: Saniyede okunan ve yazılan veri miktarı.
  • await: I/O isteğinin ortalama tamamlanma süresi. Değer yükseldikçe işlemler diski bekliyor olabilir.
  • %util: Aygıtın isteklerle ne kadar meşgul olduğunu gösterir. Tek başına yüzde 100 olması kesinlikle arıza olduğu anlamına gelmez; ancak yüksek await ile birlikte görülüyorsa darboğaz ihtimali güçlenir.
Birden fazla disk veya sanal aygıt varsa önce hangi aygıtın yoğun olduğunu belirleyin. Örneğin sda düşükken nvme0n1 yüksek olabilir. Bu ayrım, yanlış işlemi incelemenizi önler.

Diski hangi işlemin kullandığını görün​


En pratik araç iotop komutudur:

Bash: 
sudo iotop -oPa

-o yalnızca aktif I/O yapan işlemleri, -P iş parçacıkları yerine işlemleri, -a ise ölçüm boyunca biriken toplam I/O değerlerini göstermeye yarar. Bazı sistemlerde çekirdekten işlem I/O bilgisi alınabilmesi için yönetici yetkisi gerekir.

Ekranda özellikle DISK READ, DISK WRITE, SWAPIN, işlem kimliği (PID) ve komut sütunlarını karşılaştırın. Bir işlemin toplam yazması yüksek olabilir fakat o anda yazma hızı düşük olabilir; bu nedenle birkaç yenileme boyunca aynı işlemin üst sıralarda kalıp kalmadığını gözlemleyin.

iotop kurulu değilse veya çalışmıyorsa, pidstat iyi bir alternatiftir:

Bash: 
pidstat -d -p ALL 1

Buradaki -d disk I/O istatistiklerini, -p ALL tüm işlemleri, sonundaki 1 ise bir saniyelik örnekleme aralığını belirtir. kB_rd/s ve kB_wr/s sütunlarında sürekli yüksek değer üreten PID'yi not alın. Yalnızca anlık bir sıçrama görüyorsanız bunun kalıcı bir disk yükü olduğunu varsaymayın.

Aşağıdaki karşılaştırma, hangi aracı ne zaman kullanacağınızı gösterir.
AraçGösterdiği bilgiEn uygun kullanım
iostatDisk aygıtının genel yoğunluğu ve bekleme süresiSorunun hangi disk veya aygıtta olduğunu bulmak
iotopİşlem bazında anlık ve toplam okuma-yazmaDiski zorlayan işlemi hızlıca görmek
pidstat -dPID bazında belirli aralıklarla I/O miktarıKısa süreli ölçüm almak ve işlemleri karşılaştırmak
lsofİşlemin açık tuttuğu dosyalarYüksek I/O yapan işlemin hangi dosyalarla çalıştığını incelemek
İşlemi belirledikten sonra açık dosyalarını kontrol etmek için PID yerine gerçek işlem kimliğini kullanın:

Bash: 
sudo lsof -p PID

Örneğin PID 2481 ise sudo lsof -p 2481 çalıştırılır. Çıktıda günlük dosyaları, veritabanı dosyaları, geçici dosyalar veya yedekleme hedefleri görülebilir. lsof yalnızca işlemin açık dosyalarını gösterir; dosyanın o anda yüksek miktarda I/O aldığını tek başına kanıtlamaz. Bu nedenle önceki iotop veya pidstat ölçümüyle birlikte yorumlanmalıdır.

Sonucu işlem türüne göre yorumlayın​


Yüksek I/O yapan işlem bir veritabanı servisi ise doğrudan sonlandırmak yerine hangi sorgu, tablo, indeks veya bakım görevinin çalıştığını uygulama ve veritabanı günlüklerinden inceleyin. Veritabanını zorla kapatmak veri bütünlüğü ve hizmet kesintisi riski oluşturabilir.

İşlem rsync, tar, yedekleme yazılımı veya benzeri bir görevse ölçümün zamanlanmış yedekleme saatine denk gelip gelmediğini kontrol edin. Yüksek yazma miktarı beklenen bir yedekleme sırasında görülüyorsa bu tek başına arıza kanıtı değildir; ancak await yükseliyor ve normal servisler belirgin biçimde yavaşlıyorsa yedekleme zamanlaması, paralel iş sayısı veya hedef disk gözden geçirilmelidir.

İşlem journald, web sunucusu veya başka bir günlük yazıcısıysa log seviyesini, tekrarlayan hata mesajlarını ve logrotate yapılandırmasını kontrol edin. Aynı hata kısa sürede binlerce kez yazılıyorsa asıl sorun disk değil, sürekli hata üreten uygulama olabilir.

İşlem görünmüyorsa hangi kontroller yapılmalı?​


ve pidstat belirgin bir işlem göstermediği hâlde iostat yoğunluk bildiriyorsa şu olasılıkları ayırın:
  • I/O, kısa ve seyrek patlamalar hâlinde gerçekleşiyor olabilir. Örnekleme aralığını daha kısa tutup birkaç dakika gözlemleyin.
  • Sorun sanal makinenin ana makinesinde veya depolama altyapısında olabilir. Konuk işletim sistemi kendi işlemini görse bile fiziksel disk kuyruğunun tamamını göremeyebilir.
  • Bellek yetersizliği nedeniyle takas alanı kullanılıyor olabilir. free -h ile Swap kullanımını, vmstat 1 ile si ve so değerlerini kontrol edin. Sürekli takas kullanımı RAM baskısına işaret eder.
  • Dosya sistemi doluluğu veya inode tükenmesi yazma hatalarına yol açabilir. df -h ve df -i çıktılarında yüzde 100'e yaklaşan dosya sistemi olup olmadığını kontrol edin.
vmstat 1 çıktısında wa değeri yüksekse CPU'ların I/O beklediği anlaşılır; bu değer hangi işlemin diski kullandığını göstermez. İşlemi bulmak için yine iotop, pidstat ve gerekirse lsof birlikte kullanılmalıdır.

İşlemi bulduktan sonra güvenli müdahale​


Önce PID'yi, servis adını, yoğunluğun başladığı zamanı ve ilgili komut çıktısını kaydedin. Ardından işlemin beklenen bir görev mi yoksa tekrarlayan bir hata mı olduğunu belirleyin. Beklenen bir servis ise yapılandırmasını, sorgularını, loglarını veya zamanlanmış görevini düzeltin; yalnızca I/O'yu gizlemek için işlemi durdurmayın.

Geçici tanılama sırasında alınan çıktılarda kullanıcı adları, dosya yolları veya uygulama parametreleri bulunabilir. Bu bilgileri paylaşmadan önce hassas verileri maskeleyin. İşlem tamamlandıktan sonra geçici izleme komutlarını ve gereksiz tanılama kayıtlarını açık bırakmayın.

Kalıcı yüksek await, sürekli yüksek %util ve birden fazla serviste gözlenen yavaşlık birlikte devam ediyorsa sorun tek bir işlemin davranışından çok depolama kapasitesi, disk sağlığı, sanal depolama kotası veya ana makine tarafındaki yoğunlukla ilgili olabilir. Bu durumda destek talebine iostat -xz 1, pidstat -d 1, free -h, df -h çıktılarının sorun yaşanan saat bilgisiyle birlikte eklenmesi, incelemenin doğru disk ve zaman aralığı üzerinden yapılmasını sağlar.
 

Sende şimdi bize katılmak ister misin?

Kayıt ol

Bize katılım kolay ve ücretsizdir!

Üye ol
Foruma git ?

Bu konuyu görüntüleyen kullanıcılar

Bu konuyu şu anda görüntüleyen üye bulunmuyor.
Robotlar:
  • Anthropic
Toplam: 1 (Üye: 0, misafir: 0, robot: 1)