ApsaraDB RDS for MySQL örneğinde yaşanan yüksek G/Ç sorunu genellikle beş temel nedenden kaynaklanır: yüksek aktarım hızı, geçici tablolar, soğuk veri okumaları, DDL deyimleri ve büyük işlemli ikili günlük yazmaları. Nedeni belirlemek ve hedefe yönelik önlem almak için bu kılavuzu kullanın.
Yaygın nedenlere genel bakış
| Neden | Konsolda nereye bakılır | Temel gösterge |
|---|---|---|
| Yüksek aktarım hızı | Autonomy Service > Dashboard > Performance Trends | Okuma/yazma yükü |
| Geçici tablolar | Autonomy Service > Dashboard > Performance Trends | tmp dizini boyutu |
| Soğuk veri okumaları | Autonomy Service > Dashboard > Performance Trends | Buffer pool isabet oranı |
| DDL deyimleri | Monitoring and Alerts > Standard Monitoring > Standard View | Disk kullanımı ve IOPS |
| Büyük işlemli ikili günlük yazmaları | — | İkili günlük hacminde ani büyük artış |
InnoDB'nin G/Ç işlemlerini nasıl yönettiği
InnoDB, veri sayfalarını okumak ve yazmak için bağımsız bir G/Ç sistemi kullanır. Bir SQL deyimi buffer pool'da bulunmayan bir veri sayfası istediğinde, InnoDB bu sayfayı diskten eşzamanlı G/Ç kullanarak okur. Arka plan iş parçacıkları ise kirli sayfaları diske boşaltmak için eşzamansız G/Ç kullanır.
Veri dosyası G/Ç'sinin yanı sıra, redo günlüğü yazmaları, undo günlüğü yazmaları, ikili günlük yazmaları, geçici tablo sıralamaları ve DDL tablespace yeniden oluşturma işlemleri gibi diğer işlemler de G/Ç'yi önemli ölçüde artırabilir. Aşağıda açıklanan beş nedenin her biri, bu mekanizmalardan biri veya birkaçıyla ilişkilidir.
Yüksek aktarım hızından kaynaklanan yüksek G/Ç sorunlarını giderme
Belirti
Çok sayıda dizine veya büyük alanlara sahip tablolar üzerinde sık yapılan UPDATE, DELETE ve INSERT işlemleri G/Ç'yi iki şekilde etkiler. İlk olarak, RDS veri sayfalarını buffer pool'a okur. Ardından, arka plan iş parçacıkları ortaya çıkan kirli sayfaları diske boşaltır. Birleşen okuma ve yazma baskısı G/Ç kullanımını artırır.
Durumu doğrulamak için ApsaraDB RDS konsolunun sol gezinme bölmesinde Autonomy Service > Dashboard şuraya gidin, Performance Trends sekmesini açın ve okuma/yazma yükü ölçümlerini kontrol edin.
Çözüm
Okuma/yazma sıklığını azaltın, örnek türünü yükseltin veya kirli sayfa boşaltmayı kontrol eden parametreleri ayarlayın.
| Parametre | Varsayılan | Açıklama |
|---|---|---|
innodb_max_dirty_pages_pct |
75 | Buffer pool'da izin verilen maksimum kirli sayfa yüzdesi |
innodb_max_dirty_pages_pct_lwm |
0 (devre dışı) | Kirli sayfalar için alt sınır; aşıldığında, RDS buffer pool'da yeterli alan sağlamak amacıyla kirli sayfaları proaktif olarak boşaltır |
innodb_io_capacity |
20000 | InnoDB arka plan görevleri için saniyede mevcut olan maksimum G/Ç işlemi sayısı; kirli sayfa boşaltma hızını ve buffer pool yazmalarını kontrol eder |
innodb_io_capacity_max |
40000 | Saniyedeki G/Ç işlemleri için üst sınır; yalnızca kirli sayfa boşaltma işlemi geride kaldığında etkili olur; innodb_io_capacity değerinden büyük olmalıdır |
innodb_max_dirty_pages_pct_lwm değeri innodb_max_dirty_pages_pct değerine eşit veya ondan küçük olmalıdır. Daha yüksek bir değer ayarlarsanız, RDS bu değeri otomatik olarak innodb_max_dirty_pages_pct değerine sıfırlar.
Geçici tablolardan kaynaklanan yüksek G/Ç sorunlarını giderme
Belirti
Sıralama veya yinelenen verileri kaldırma içeren yavaş SQL deyimleri, InnoDB'nin diskte büyük geçici tablolar oluşturmasına neden olur. Bu geçici tabloların hem oluşturulması hem de üzerine yazılması G/Ç kullanımını artırır. Büyük bir tmp dizini, bunun güvenilir bir göstergesidir.
Durumu doğrulamak için ApsaraDB RDS konsolunun sol gezinme bölmesinde Autonomy Service > Dashboard şuraya gidin, Performance Trends sekmesini açın ve tmp dizininin boyutunu kontrol edin.
Çözüm
Geçici tablolar oluşturan SQL deyimlerini optimize edin. Database Autonomy Service (DAS), yavaş sorguları belirlemenize ve düzeltmenize yardımcı olmak için yerleşik SQL optimizasyonu sağlar. Ayrıntılar için bkz. SQL optimizasyonu.
Soğuk veri okumalarından kaynaklanan yüksek G/Ç sorunlarını giderme
Belirti
Bir sorgu veya DML deyiminin ihtiyaç duyduğu veri sayfaları buffer pool'da bulunmadığında, InnoDB bunları diskten okur. Düşük bir buffer pool isabet oranı, çoğu isteğin diske gitmesi anlamına gelir ve bu durum G/Ç kullanımını önemli ölçüde artırır.
Durumu doğrulamak için ApsaraDB RDS konsolunun sol gezinme bölmesinde Autonomy Service > Dashboard şuraya gidin, Performance Trends sekmesini açın ve buffer pool isabet oranını kontrol edin.
Çözüm
Önbelleğe alma stratejinizi iş yükünüzün erişim desenlerine göre yeniden tasarlayın. Alternatif olarak, RDS örneğinizin kapasitesini artırın.
DDL deyimlerinden kaynaklanan yüksek G/Ç sorunlarını giderme
Belirti
DDL deyimleri tam bir tablespace yeniden oluşturmasını tetikler. InnoDB her satırı tarar, sıralama dizinleri oluşturur ve yeni tablo yapısı için kirli sayfaları boşaltır. Büyük tabloların silinmesi de önemli miktarda G/Ç üretir. Bu işlemler, hem disk kullanımında hem de IOPS değerlerinde ani artışlara neden olabilir.
Durumu doğrulamak için ApsaraDB RDS konsolunun sol gezinme bölmesinde Monitoring and Alerts şuraya gidin, Standard Monitoring sekmesinde Standard View tıklayın ve disk kullanımı ile IOPS değerlerini kontrol edin.
Çözüm
G/Ç işlemini engellemeden büyük dosyaları silmek için Purge Large File Asynchronously özelliğini kullanın. Bu özellik, Alibaba Cloud'un MySQL dalı olan AliSQL'in bir parçasıdır. Ayrıntılar için bkz. Purge Large File Asynchronously.
Büyük işlemlerden kaynaklanan ikili günlük yazmalarının yarattığı yüksek G/Ç sorunlarını giderme
Belirti
InnoDB, ikili günlük dosyalarına yalnızca işlem commit aşamasında yazar. Tek bir büyük işlem (örneğin, çok sayıda satırı silen bir DELETE deyimi) onlarca GB'lık ikili günlük verisi üretebilir. Bu kadar büyük bir verinin tek seferde diske boşaltılması, G/Ç kullanımında ani bir artışa neden olur.
Çözüm
Büyük işlemleri daha küçük toplu işlere bölün. Daha küçük commit'ler, ikili günlük boşaltmalarını zaman içinde dağıtarak kirli sayfaların diske boşaltılmasını azaltır ve tek bir büyük commit'in neden olduğu ani G/Ç artışını önler.