ApsaraDB RDS:View RDS for MySQL metrics

Performans olaylarını görüntüleyin

Olay istatistikleri alanı, seçilen zaman aralığındaki olay sayılarını türe göre gösterir. Ayrıntılı bilgi için View Details öğesine tıklayarak View Performance Events sayfasını açın. Burada planlanmış, devam eden veya tamamlanmış anormal etkinlikleri ve optimizasyon olaylarını görebilirsiniz.

Performans ölçümlerini görüntüleyin

Varsayılan Classic View içinde:

• Ek ölçümler seçmek ve performans eğilimlerini görüntülemek için More Metrics öğesine tıklayın.

• Bir ölçüm adının ardından hangi alt ölçümleri içerdiğini görmek için simgesine tıklayın.

• Herhangi bir eğilim grafiğinde yakınlaştırmak ve zaman aralığını ayarlamak için Details öğesine tıklayın.

• Aynı ölçümü farklı zaman dilimlerinde karşılaştırmak için Add Trend Comparison öğesine tıklayın.

Ölçüm grafiklerindeki olayları analiz edin

Classic View içinde, ilgili olayları MySQL CPU/Memory Utilization ve Session Connections eğilim grafiklerinin üzerine bindirmek için bir olay düzeyi seçin. Tanılama sonucunu görüntülemek için herhangi bir olay işaretçisine tıklayın.

Bir zaman aralığında tanılama çalıştırın

Herhangi bir ölçüm eğilimi grafiğinde bir zaman aralığı seçmek için sürükleyin, ardından o dönem için ayrıntılı bir kök neden analizi almak üzere Diagnose öğesine tıklayın.

Tanılama görünümlerini kullanın

Belirli bir sorun türünü araştırmak için beş tanılama görünümünden herhangi birine tıklayın:

• Memory OOM Diagnosis

• Read-only Instance Delay Diagnosis

• Full Disk Space Diagnosis

• CPU Jitter Diagnosis

• Large Transaction Recognition Diagnosis

Her bir görünüm için ölçüm yorumlama ve sonraki adımlar hakkında bilgi edinmek için bkz. Diagnostic views.

Bellek OOM tanılama

Memory OOM Diagnosis görünümü, bellek yetersizliği (OOM) sorunlarını analiz etmenize yardımcı olur. Temel ölçümler ve bunların anlamları şunlardır:

Memory Usage — InnoDB Buffer Pool kullanımına karşı eğilimi yorumlayın:

Resident Memory kullanılan fiziksel bellek miktarını gösterir. Open files, Temp File Size, Temp Disk Tables ve Sort Rows bellek baskısının yaygın göstergeleridir.

OOM olayları genellikle yükselmeye neden olan işlemleri sonlandırdığından, olay sonrası tam SQL ifadesini belirlemek zordur. Hazırlık yapmak için:

• Bellek artışları meydana geldiğinde nedeni izlemek için iş günlüklerini kontrol edin.

• Bellek teknik özelliklerini yükseltin ve SQL Explorer and Audit özelliğini etkinleştirin. Böylece bir artış meydana geldiğinde, nedeni belirlemek için sorgu yürütme sürelerini kontrol edebilirsiniz.

Salt okunur örnek gecikmesi tanılama

Read-only Instance Delay Diagnosis görünümü, salt okunur örneklerdeki çoğaltma gecikmesini tanılamaya yardımcı olur. Temel ölçümler:

• Active Session: Meta veri kilidi engellemesini gösterir. Büyük miktarda veriyi tarayan sorgular, DDL ifadelerinin meta veri kilitlerini almasını engeller; bu da DDL'nin diğer oturumları engellemesine ve bağlantıların birikmesine neden olur.

• DML Rows Processed, Pages Requested, DML/DDL Operations, Temp Disk Space Used: Yaygın iş yükü ölçümleri.

• Replication Delay: Birincil gecikme göstergesi.

Dolu disk alanı tanılama

Full Disk Space Diagnosis görünümü, hangi dosya türlerinin depolama alanını tükettiğini ve boyutlarının zaman içinde nasıl değiştiğini gösterir. Aşağıdaki depolama kategorileri izlenir:

• Veri dosyaları (user_data_size): Veritabanı ve tablo bazında alan kullanımını belirlemek için Space Analysis özelliğini kullanın, ardından ölçeklendirme yapın veya gereksiz verileri silin. Bkz. Solutions for a full instance caused by data files.

• Geçici dosyalar (temp_file_size): SQL sıralama, gruplama ve birleştirme işlemleri sırasında ve büyük işlemler işlenmeden önce ikili günlük önbellek dosyaları olarak oluşturulur. Bkz. Resolve full instance storage caused by temporary files.

• İkili günlükler (binlog_size): Büyük işlemler ikili günlükleri hızla oluşturabilir. Hizmetleriniz örneğin ikili günlüklerine abone ise, günlükler zamanında temizlenmeyebilir. Bkz. Resolve full instance storage caused by binary log files.

• Geri alma günlükleri (undo_log_size): Uzun süren sorgular, geri alma günlüklerinin temizlenmesini engeller. Tamamlanmadan çalışan sorguları kontrol edin.

  Not

  MySQL 5.6 ve önceki sürümlerde, geri alma günlükleri ayrı bir tablo alanına sahip değildir.

• Yavaş günlük (slowlog_size): Aşırı alan kaplıyorsa, yavaş günlüğü temizlemek için yoğun olmayan saatlerde truncate komutunu çalıştırın.

  Not

  truncate komutu için destek, MySQL 5.7 sürüm 20210630 ve MySQL 8.0 sürüm 20210930'da eklenmiştir.

• Genel günlükler (general_log_size): Örneğin hata, Performance Agent ve kurtarma günlüklerinin toplam boyutu. Bu değer genellikle stabildir ve 1 GB'ın altındadır. Bu eşiği önemli ölçüde aşarsa, ürün ekibiyle iletişime geçmek için submit a ticket adresinden bir destek bileti oluşturun.

  Not

  general_log_size MySQL çekirdeği tarafından periyodik olarak oluşturulan verileri temsil eder; MySQL general_log dosyasının boyutu değildir.

CPU titremesi tanılama

CPU Jitter Diagnosis görünümü, CPU kullanımının neden dalgalı olduğunu belirlemenize yardımcı olur. Şu ölçümleri izleyin:

İş ölçümleri:

• Page Request: Buffer Pool istekleri genellikle CPU kullanımıyla senkronize şekilde dalgalanır.

• Rows Processed: Satır sayısı değişikliklerinin CPU artışlarıyla ilişkili olup olmadığını belirlemek için CPU kullanımıyla karşılaştırın.

• Queries: CPU kullanımı değişiklikleri sırasında yürütülen SQL ifadesi türlerini belirleyin.

Bağlantılar:

• Thread Running: Yüksek eşzamanlılık CPU kullanımını artırır. MDL yığılması ve satır kilitleri de bağlantı birikimine neden olarak CPU yükünü artırabilir.

Yaygın nedenler ve sonraki adımlar:

• CPU artışı sırasında Page Request veya Rows Processed değiştiyse, etkilenen zaman aralığını seçmek için sürükleyin ve ayrıntılı bir kök neden analizi almak için Diagnose öğesine tıklayın.

• Etkin bağlantılar arttıysa, bağlantı artışına neyin neden olduğunu belirlemek için uygulama tarafından araştırma yapın.

Büyük işlem tanılama

Large Transaction Recognition Diagnosis görünümü, büyük işlemleri ve etkilerini belirlemenize yardımcı olur. Üç temel ölçüm büyük bir işleme işaret eder:

Rows Processed, Logical Page Write ve Queries per Second işlem türünü gösterir. Örneğin, az sayıda sorgu ile yüksek satır silme sayısı kombinasyonu, büyük bir DELETE işlemine işaret eder.

Büyük işlemlerin örneği nasıl etkilediği:

1. Büyük işlem çalışırken, geçici tablo alanı (ikili günlük önbelleği) kademeli olarak artar, ardından stabilize olur.

2. Geçici tablo alanı stabilize olduktan sonra ikili günlük alanı artar. İkili günlük yazmaları küresel olarak seri olduğundan, diğer işlemler engellenir ve bağlantılar birikir.

3. High-availability Edition örneklerinde, birincil ve ikincil örneklerdeki HA bileşeninin prob ifadeleri de engellenir ve birincil/ikincil yük devretme gerçekleşir.

Bu sorunları önlemek için büyük işlemleri daha küçük parçalara bölün. DELETE ifadeleri için, her işlemde silinen satır sayısını sınırlayan bir WHERE yan tümcesi ekleyerek tek bir büyük silme işlemini birden çok küçük silme işlemine dönüştürün.