Tüm Ürünler
Search
Belge Merkezi

ApsaraDB RDS:ApsaraDB RDS for MySQL örneğinde bellek kullanımı sorunlarını giderin

Son Güncelleme:Oct 03, 2026

Bu konu, bellek kullanımını nasıl görüntüleyeceğinizi açıklar ve yaygın bellek sorunlarının nedenleri ile çözümlerini sunar.

Genel bilgiler

Bellek kullanımı ve arabellek havuzu isabet oranı, bir ApsaraDB RDS for MySQL örneği için temel ölçümlerdir. Yüksek bellek kullanımı bellek tükenmesine yol açabilir. Düşük arabellek havuzu isabet oranı, birçok veri sayfasının arabellek havuzunda bulunamadığı ve diskten okunması gerektiği anlamına gelir. Bu durum G/Ç aktarım hızını ve gecikme süresini artırır.

Bellek kullanımını görüntüleme

RDS Management Console adresindeki etkin iş parçacıklarını aşağıdaki yöntemlerle görüntüleyebilirsiniz:

  • İzleme ve Uyarılar

    Konsolda Monitoring and Alerts sayfasına gidin. Standard Monitoring sekmesinde, örneğin MySQL CPU/Memory Usage ve InnoDB Buffer Pool Hit Rate değerlerini görüntüleyebilirsiniz.

    内存使用率缓存命中率

  • Database Autonomy Service (DAS)

    Konsolda Autonomy Service > Performance Trend sayfasına gidin. Performance Trend sekmesini tıklayın ve MySQL CPU/Memory Usage ile InnoDB Buffer Pool Hit Rate değerlerini görüntüleyin.

    内存利用率缓存命中率

Bellek araçlarını ayarlamak için performance_schema da kullanabilirsiniz. Bu sayede bellek özet tablolarında bellek kullanımı istatistiklerini görüntüleyebilirsiniz. Daha fazla bilgi için official MySQL documentation adresine bakın.

  • Örnek başlatılırken bellek izlemeyi etkinleştirmek için konsoldaki performance_schema parametresini değiştirin. RDS for MySQL 5.6 için ON olarak ayarlayın. RDS for MySQL 5.7 ve 8.0 için 1 olarak ayarlayın. Daha fazla bilgi için bkz. View instance parameters. Değişikliklerin etkili olması için örneği yeniden başlatın.

  • Örnek çalışırken bellek izlemeyi etkinleştirmek için aşağıdaki komutu çalıştırın:

    update performance_schema.setup_instruments set enabled = 'yes' where name like 'memory%';

Aşağıdaki tablolar, çeşitli boyutlardaki bellek tüketimini özetler:

  • memory_summary_by_account_by_event_name: Olayları hesap (kullanıcı ve ana bilgisayar kombinasyonu) ve olay adına göre özetler.

  • memory_summary_by_host_by_event_name: Olayları ana bilgisayar ve olay adına göre özetler.

  • memory_summary_by_thread_by_event_name: Olayları iş parçacığı ve olay adına göre özetler.

  • memory_summary_by_user_by_event_name: Olayları kullanıcı ve olay adına göre özetler.

  • memory_summary_global_by_event_name: Olayları olay adına göre özetler.

RDS for MySQL'de yüksek bellek kullanımının yaygın nedenleri

InnoDB Buffer Pool genellikle en çok belleği tüketir. Arabellek havuzunun maksimum bellek kullanımı yapılandırma parametreleriyle sınırlıdır. Ancak istek yürütme sırasında önemli miktarda bellek dinamik olarak ayrılır ve ayarlanır. Buna bellek içi geçici tablolar, ön getirme önbelleği, tablo önbelleği, karma dizinler ve satır kilidi nesneleri için ayrılan bellek dahildir. Bellek kullanımı ve parametre sınırları hakkında daha fazla bilgi için official MySQL documentation adresine bakın.

Çoklu ifade sorguları

MySQL, noktalı virgül (;) ile ayrılmış birden fazla SQL ifadesinin birlikte gönderilmesini destekler. MySQL her SQL ifadesini sırayla işler. Ancak bazı ayrılan bellekler yalnızca tüm SQL ifadelerinin yürütülmesi tamamlandıktan sonra serbest kalır.

Tek seferde birçok çoklu ifade sorgusu (örneğin birkaç yüz megabayt) gönderirseniz yürütme sırasında çeşitli nesneler tarafından tüketilen kümülatif bellek çok büyük olabilir. Bu durum MySQL işleminin belleğinin kolayca tükenmesine yol açabilir.

Genellikle büyük bir çoklu ifade sorgu yığını ağ trafiğinde ani bir artışa neden olur. Bu kalıbı ağ trafiği izleme ve SQL Explorer kullanarak kontrol edebilirsiniz. Uygulama mantığınızda çoklu ifade sorgularını kullanmaktan kaçının.

内存耗尽

Arabellek havuzu sorunları

Tablolara ait tüm veri sayfaları arabellek havuzunda depolanır. Bir sorgu çalıştırıldığında gereken veri sayfaları arabellek havuzunda bulunursa fiziksel G/Ç işlemi gerçekleşmez. Bu durum SQL yürütmeyi verimli hale getirir. Arabellek havuzu veri sayfalarını yönetmek için En Son Kullanılan (LRU) algoritmasını kullanır. Tüm kirli sayfalar temizleme listesine yerleştirilir.

Varsayılan olarak RDS for MySQL için InnoDB Buffer Pool boyutu örneğin belleğinin %75'i olarak ayarlanır. Bu genellikle örneğin tükettiği belleğin en büyük kısmıdır.

Arabellek havuzuyla ilgili yaygın sorunlar şunlardır:

  • Yetersiz veri sayfası ön ısıtma yüksek sorgu gecikme süresine neden olabilir. Bu sorun genellikle bir örnek yeniden başlatıldıktan sonra, soğuk veriler okunurken veya arabellek havuzu isabet oranı düşük olduğunda ortaya çıkar. Sorunu çözmek için örnek türünü yükseltebilir veya satış promosyonlarından önce verileri ön ısıtabilirsiniz.

  • Çok sayıda kirli sayfa birikir. Temizlenmemiş bir kirli sayfanın en eski Günlük Sıra Numarası (LSN) ile geçerli LSN arasındaki mesafe %76'yı aştığında kullanıcı iş parçacıkları kirli sayfaları eşitlemek ve temizlemek için tetiklenir. Bu durum örnek performansını ciddi şekilde düşürür. Optimizasyon için yazma yükünü dengeleyin, aşırı yüksek yazma aktarım hızından kaçının, kirli sayfa temizleme parametrelerini ayarlayın veya örnek türünü yükseltin.

  • innodb_buffer_pool_instances parametresi yüksek belleğe sahip bir örnek için çok düşük ayarlanmıştır. Saniye Başına Sorgu (QPS) yükü yüksek olduğunda arabellek havuzundaki kilit çekişmesi yoğunlaşabilir. Yüksek bellekli örnekler için innodb_buffer_pool_instances parametresini 8, 16 veya daha yüksek bir değere ayarlayın.

Geçici tablolar

Bellek içi geçici tabloların boyutu tmp_table_size ve max_heap_table_size parametreleriyle sınırlıdır. Bir tablo bu sınırları aşarsa disk geçici tablosuna dönüştürülür. Aynı anda birçok bağlantı büyük geçici tablolar oluşturursa ani bir bellek artışına neden olabilir. MySQL 8.0 yeni bir temptable altyapısı tanıttı. Tüm iş parçacıkları tarafından ayrılan tüm bellek içi geçici tabloların toplam boyutu temptable_max_ram parametresinin değerini aşamaz. temptable_max_ram varsayılan değeri 1 GB'tır. Bu sınır aşılırsa tablolar disk geçici tablolarına dönüştürülür.

Diğer nedenler

Bir örnekte çok sayıda tablo varsa veya QPS yüksekse tablo önbelleği de önemli miktarda bellek tüketebilir. Bir örnekte çok fazla tablo oluşturmaktan veya table_open_cache parametresini çok yüksek ayarlamaktan kaçının.

Uyarlamalı karma dizin tarafından kullanılan bellek varsayılan olarak arabellek havuzu boyutunun 1/64'üdür. Çok büyük Binary Large Object (BLOB) alanlarını sorgularsanız veya yazarsanız bu büyük nesneler için bellek dinamik olarak ayrılır ve bu da genel bellek kullanımını artırır.

Bellek kullanımının artmasına neden olan başka birçok sorun vardır. Bellek kullanımı anormal şekilde artarsa veya örneğin belleği tükenirse nedeni belirlemek için official MySQL documentation adresine bakın.