IOPS kullanımı, MongoDB örnekleri için kritik bir ölçümdür. Bu değer %100'e ulaştığında veya yaklaştığında uygulama yanıtları yavaşlar ve hizmetler kullanılamaz hale gelebilir. Bu kılavuzda IOPS kullanımını kontrol etme yöntemleri, yüksek kullanımın yaygın nedenleri ve optimizasyon stratejileri ele alınmaktadır.
Genel bilgiler
Cloud veritabanı sağlayıcıları, paylaşılan ana bilgisayarlardaki G/Ç çekişmesini önlemek amacıyla cgroups (Control Groups) gibi teknolojileri kullanarak her örnek başına G/Ç izolasyonu ve IOPS (Saniye Başına Giriş/Çıkış İşlemi) sınırları uygular. Bu nedenle her örnek türünün belirli bir maksimum IOPS kapasitesi bulunur.
Önemli notlar
Tek düğümlü örneklerde ve cloud disklerle çalışan MongoDB 4.2 sürümünü kullanan çoğaltma kümesi veya parçalanmış küme örneklerinde IOPS Kullanımı ve IOPS kullanımı ölçümleri kullanılamaz.
Bu örnekler için ApsaraDB for MongoDB konsolundaki Monitoring Information sayfasında IOPS Usage ve IOPS Usage ölçümleri her zaman 0 olarak görüntülenir. Bu değer gerçek IOPS verilerini yansıtmaz.
IOPS kullanımını kontrol etme
IOPS kullanımını izleme grafiklerini kullanarak veya komut çalıştırarak kontrol edebilirsiniz.
ApsaraDB for MongoDB konsoluna giriş yapın. Basic Information sayfasında, Specification Information bölümünde örneğin maksimum IOPS değerini görüntüleyin. Farklı örnek türlerinin IOPS sınırları hakkında bilgi almak için bkz. Örnek türleri.
ApsaraDB for MongoDB konsoluna giriş yapın. Monitoring Information sayfasında, örneğin IOPS sınırına yaklaşıp yaklaşmadığını belirlemek için IOPS Usage ve IOPS Usage ölçümlerini kontrol edin. IOPS ile ilgili ölçümler hakkında daha fazla bilgi için bkz. Ölçümler.
G/Ç sorunlarının yaygın nedenleri
Bir MongoDB örneğinde yüksek disk G/Ç'si genellikle aşağıdaki faktörlerden kaynaklanır:
Yetersiz bellek: G/Ç performansı büyük ölçüde WiredTiger önbellek boyutuna bağlıdır. Daha büyük bir önbellek daha fazla sıcak veriyi tutarak disk G/Ç'sini azaltır ve darboğaz riskini düşürür. Daha küçük bir önbellek sistemin kirli sayfaları diske daha sık yazmasına neden olarak G/Ç baskısını artırır.
Uygunsuz yapılandırma: Yüksek G/Ç'ye neden olabilecek yapılandırma sorunları arasında journal veya çalışma zamanı günlüklerinin sık sık yazılması, verimsiz bir Write Concern düzeyi veya parçalanmış bir kümede moveChunk hataları yer alır.
G/Ç sorunları için optimizasyon stratejileri
Bir ApsaraDB for MongoDB örneğindeki G/Ç sorunlarını çözmek için uygun bir örnek türü seçin, dizinleri optimize edin ve uygulama yazma kalıplarını iyileştirin.
-
Uygun bir örnek türü seçin
Dağıtımdan önce sıcak veri ile önbellek boyutu arasındaki ideal oranı tahmin etmek genellikle zordur. Genel bir kural olarak, günlük en yüksek CPU kullanımını ve IOPS kullanımını %50'nin altında tutarken iş gereksinimlerinizi karşılayan bir örnek türü seçin.
-
Dizinleri optimize edin
Tam tablo taramaları ve verimsiz dizinlere sahip sorgular önemli miktarda G/Ç tüketir. Örneğin, bir koleksiyonun tamamını dışa aktarmak ani bir G/Ç artışına neden olabilir. Aşırı dizinleme ayrıca diskteki veri boyutunu artırarak WiredTiger önbelleğinin tutabileceği sıcak veri miktarını azaltır. Her yazma işlemi dizinleri güncellemek için ek G/Ç gerektirerek performansı daha da düşürür. Bu sorunları azaltmak için sorgu kalıplarınıza uygun dizinler oluşturun.
-
Uygulama mimarinizi ve işlemlerinizi optimize edin
Disk G/Ç'sinin uygulama düzeyinde bir darboğaza dönüşmesini önlemek için aşağıdaki optimizasyonları düşünün:
-
Eşzamanlı yazma ve okuma iş parçacıklarını kontrol edin
MongoDB çok iş parçacıklı bir uygulamadır. Yüksek sayıda eşzamanlı yazma veya karmaşık sorgular G/Ç darboğazlarına ve ikincil düğümlerde kalıcı çoğaltma gecikmesine neden olabilir. Yüksek yazma hacmi G/Ç darboğazlarına neden oluyorsa verileri yatay olarak dağıtarak yazma performansını doğrusal şekilde ölçeklendirmek için parçalanmış bir kümeye yükseltmeyi değerlendirin.
-
Mümkün olduğunda yazma artışlarından kaçının
Bazı uygulamalar periyodik yazmalar veya toplu veri kalıcılığı gerçekleştirerek IOPS artışlarına neden olur. Mevcut örnek bu tepe yükleri işleyemiyorsa yazma işlemlerini daha eşit şekilde dağıtın. Örneğin, her toplu iş yazma işlemine küçük ve rastgele bir gecikme ekleyin.
-
Yoğun saatlerde bakım işlemleri yapmaktan kaçının
Belirli bakım işlemleri performansı önemli ölçüde etkileyebilir ve IOPS artışlarına neden olabilir. Bu tür işlemleri mümkün olduğunda yoğun olmayan saatlerde planlayın. Yüksek G/Ç gerektiren işlemler arasında toplu veri değişiklikleri (yazma, güncelleme ve silme), dizin oluşturma, koleksiyon sıkıştırma ve toplu veri dışa aktarma yer alır.
-