Throughput I/O yang tinggi menurunkan kinerja kueri pada instans ApsaraDB RDS for SQL Server. Kinerja I/O diatur oleh dua faktor: IOPS dan throughput I/O. Dalam kebanyakan kasus, IOPS jarang menjadi bottleneck kinerja — throughput I/O lebih mungkin menyebabkan masalah setelah mencapai batas atasnya. Topik ini menjelaskan cara mengidentifikasi akar penyebab dan menerapkan perbaikan yang tepat.
Batas throughput I/O
Throughput I/O maksimum bergantung pada tipe storage yang terhubung ke instans Anda.
Premium Local SSDs
Instans RDS yang menggunakan Premium Local SSDs berbagi storage host fisik dengan instans lain pada host tersebut. Setiap instans memiliki batas IOPS maksimum, tetapi throughput I/O tidak dibatasi per instans — throughput dapat melebihi 1 GB/s. Karena instans berbagi storage dasar, mereka mungkin bersaing untuk sumber daya I/O. Untuk alokasi sumber daya I/O eksklusif, gunakan keluarga instans dedicated host. Untuk informasi selengkapnya, lihat Tipe instans primary ApsaraDB RDS.
Cloud disks
Cloud disks didedikasikan untuk setiap instans, sehingga instans tidak saling bersaing untuk sumber daya I/O. Throughput I/O maksimum untuk instans yang menggunakan cloud disks bergantung pada dua faktor:
Sumber daya komputasi: Ditentukan oleh spesifikasi keluarga instans ECS g6.
Tipe dan kapasitas storage: RDS mendukung SSD standar dan ESSD. Throughput berbeda-beda tergantung tipe dan kapasitas storage.
Identifikasi tipe beban I/O
Beban I/O pada instans RDS terdiri dari dua komponen utama:
Data file reads: Pembacaan halaman data selama eksekusi kueri dan pencadangan.
Transaction log reads and writes: Pembacaan log sebagian besar berasal dari operasi pencadangan; penulisan log berasal dari operasi DML (data manipulation language) dan DDL (data definition language).
Untuk mengidentifikasi jenis beban yang menyebabkan throughput I/O tinggi, pantau metrik berikut di tab Performance Insight:
| Metrik | Tipe I/O | Deskripsi |
|---|---|---|
| Page_Reads | Read | Halaman data yang dibaca dari file data per detik yang tidak dapat dilayani dari cache |
| Page_Write | Write | Halaman data yang ditulis ke file data per detik |
| Log_Bytes_Flushed/sec | Write | Byte yang ditulis ke file log transaksi per detik |
| Backup_Restore_Throughput/sec | Read | Byte yang dibaca dari atau ditulis ke file data dan file log transaksi per detik selama operasi pencadangan dan pemulihan |
Setiap halaman data berukuran 8 KB.
Gunakan tabel berikut untuk mengidentifikasi akar penyebab dan langsung menuju bagian yang relevan:
| Metrik yang meningkat | Akar penyebab | Lanjut ke |
|---|---|---|
| Page_Reads | Cache tidak mencukupi (halaman data dibaca dari disk) | I/O tinggi akibat pembacaan halaman data |
| Page_Write, Log_Bytes_Flushed/sec | Beban kerja DML atau DDL yang berat | I/O tinggi akibat operasi tulis |
| Backup_Restore_Throughput/sec | Aktivitas pencadangan | I/O tinggi akibat pencadangan |
Lihat metrik throughput I/O
Prosedur ini tidak berlaku untuk instans yang menjalankan SQL Server 2008 R2 dengan cloud disks.
Buka halaman Instances. Di bilah navigasi atas, pilih wilayah tempat instans Anda berada. Temukan instans tersebut dan klik ID-nya.
Di panel navigasi kiri, pilih Autonomy Services > Performance Optimization. Pada halaman yang muncul, klik tab Performance Insight.
Di pojok kanan atas, klik Custom metric. Di kotak dialog, pilih I/O Throughput lalu klik OK. Memilih I/O Throughput akan menambahkan metrik berikut ke grafik:
IO_Throughput_Read_Kb: Throughput I/O per detik untuk operasi baca disk.
IO_Throughput_Write_kb: Throughput I/O per detik untuk operasi tulis disk.
IO_Throughput_Total_Kb: Gabungan throughput I/O baca dan tulis per detik.
Untuk menganalisis jenis beban tertentu, klik lagi Custom metric dan tambahkan metrik dari tabel di Identifikasi tipe beban I/O.
Analisis kasus
Contoh berikut menunjukkan cara menginterpretasikan data throughput I/O dalam rentang waktu berbeda.
Beban baca secara keseluruhan melebihi beban tulis. Throughput stabil dari pukul 08.00 hingga 22.00, dengan puncak pada pukul 01.00–03.00 dan 22.00–24.00.
Peak at ~01:00 — Lonjakan pembacaan halaman data mencapai sekitar 50.000 halaman/detik (~400 MB/detik), menunjukkan tekanan pada cache yang memicu pembacaan disk.
Puncak pukul 02.00–03.00 — Empat sumber bergabung mencapai puncak kumulatif sekitar 150 MB/s:
| Sumber | Throughput |
|---|---|
| Pembacaan halaman data | ~40 MB/s |
| Penulisan halaman data | ~40 MB/s |
| Penulisan log transaksi | ~30 MB/s |
| Cadangan log | ~50 MB/s |
Kondisi stabil pukul 08.00–22.00 — Tiga sumber diurutkan berdasarkan proporsi:
| Sumber | Throughput |
|---|---|
| Pembacaan halaman data | 80–100 MB/s |
| Penulisan halaman data | ~30 MB/s |
| Penulisan log transaksi | ~5 MB/s |
Puncak pukul 22.00–24.00 — Hanya aktivitas pencadangan, berlangsung stabil di atas 220 MB/s.
Pemecahan masalah I/O tinggi akibat pembacaan halaman data
Pembacaan halaman data berlebihan merupakan penyebab paling umum dari I/O tinggi pada instans ApsaraDB RDS for SQL Server. Ketika kolam buffer terlalu kecil untuk menampung data yang sering diakses, SQL Server harus membaca halaman data dari disk setiap kali terjadi cache miss.
Diagnosis tekanan cache menggunakan PLE
Page Life Expectancy (PLE) mengukur waktu rata-rata, dalam detik, suatu halaman data tetap berada di kolam buffer sebelum dikeluarkan. Penurunan PLE menunjukkan meningkatnya tekanan cache.
Ambang batas PLE sehat minimum adalah 300 detik. Untuk instans dengan memori lebih besar, hitung ambang batas yang direkomendasikan sebagai berikut:
Ambang batas PLE yang direkomendasikan = (Memori kolam buffer dalam GB / 4) × 300Contoh: Instans dengan RAM 16 GB mengalokasikan hingga 12 GB untuk kolam buffer.
Ambang batas PLE yang direkomendasikan = (12 / 4) × 300 = 900 detikJika PLE secara konsisten berada di bawah ambang batas Anda, kolam buffer terlalu kecil untuk beban kerja tersebut. Untuk latar belakang metrik ini, lihat Page Life Expectancy (PLE) in SQL Server.
Atasi I/O tinggi akibat pembacaan halaman data
Perbaikan utama adalah meningkatkan spesifikasi memori instans. Jangan meningkatkan tingkat kinerja disk (PL) untuk mengatasi I/O yang dominan membaca — kolam buffer yang lebih besar mengurangi pembacaan disk sejak awal.
Untuk lebih mengurangi jumlah total halaman data yang harus dibaca:
Arsipkan atau hapus data historis.
Aktifkan kompresi data pada tabel besar.
Hapus indeks bernilai rendah.
Defragmentasi indeks untuk mengurangi fragmentasi indeks.
Pemecahan masalah I/O tinggi akibat operasi tulis
I/O tulis tinggi disebabkan oleh operasi DML atau DDL. Gunakan Autonomy Services untuk memeriksa operasi mana yang sedang berjalan selama periode I/O tinggi.
Operasi DML yang menghasilkan I/O tulis meliputi INSERT, DELETE, UPDATE, dan MERGE. Operasi DDL meliputi CREATE INDEX dan ALTER INDEX.
I/O tinggi akibat operasi DML
Pertama, tentukan apakah aktivitas DML tersebut merupakan beban kerja rutin atau tugas sementara.
Beban kerja tidak rutin (misalnya, pengarsipan data massal atau pemrosesan data satu kali): Jadwalkan operasi ini selama jam sepi untuk menghindari persaingan dengan trafik produksi.
Beban kerja rutin: Tingkatkan tingkat kinerja disk (PL). Misalnya, tingkatkan ESSD dari PL1 ke PL2. Selain itu, tinjau struktur indeks dan hapus indeks nonclustered yang tidak lagi diperlukan, karena indeks yang tidak perlu meningkatkan amplifikasi tulis.
I/O tinggi akibat operasi DDL
Operasi DDL seperti pembuatan dan rebuild indeks biasanya merupakan tugas maintenance. Jadwalkan operasi tersebut selama jam sepi.
Saat menjalankan CREATE INDEX atau ALTER INDEX, tentukan tingkat paralelisme maksimum (MAXDOP) dalam pernyataan SQL. Menetapkan MAXDOP membatasi jumlah thread paralel yang digunakan, sehingga mengurangi throughput I/O puncak yang dihasilkan oleh operasi tersebut — dengan konsekuensi waktu eksekusi yang lebih lama.
Pemecahan masalah I/O tinggi akibat pencadangan
ApsaraDB RDS for SQL Server hanya menjalankan pencadangan pada instans primary, yang menambah beban I/O instans primary. Cadangan penuh memberikan dampak terbesar; cadangan log memberikan dampak terkecil.
Untuk melihat durasi pencadangan instans Anda, buka halaman Backup and Restoration di konsol ApsaraDB RDS.
Jadwalkan pencadangan agar tidak bertepatan dengan jam sibuk
Tetapkan waktu mulai dan siklus pencadangan untuk meminimalkan tumpang tindih dengan jam sibuk produksi. Untuk langkah-langkah konfigurasi detail, lihat Mencadangkan instans ApsaraDB RDS for SQL Server.
Contoh 1: Cadangan penuh membutuhkan waktu sekitar 6 jam. Jam sibuk bisnis berlangsung dari pukul 09.00 hingga 21.00, dan pekerjaan pemrosesan latar belakang berjalan dari pukul 22.00 hingga 01.00. Tetapkan waktu mulai pencadangan pada pukul 01.00–02.00. Setiap pencadangan selesai sebelum pukul 08.00. Atur siklus pencadangan setiap hari dalam seminggu agar garis dasar pemulihan tetap mutakhir, yang mempercepat pemulihan titik-waktu-tertentu.
Contoh 2: Cadangan penuh membutuhkan waktu sekitar 15 jam dan mengganggu beban kerja hari kerja setiap kali dijalankan. Atur siklus pencadangan hanya pada hari Sabtu dan Minggu. Perhatikan bahwa dengan frekuensi cadangan penuh yang lebih rendah, pemulihan titik-waktu-tertentu mungkin memerlukan waktu lebih lama karena lebih banyak cadangan log yang harus diputar ulang.
Ketika penjadwalan saja tidak cukup
Jika menyesuaikan jadwal pencadangan tidak menyelesaikan konflik dengan beban kerja Anda:
Tingkatkan tingkat kinerja disk (PL): PL disk yang lebih tinggi menyediakan throughput I/O lebih besar, memberikan ruang gerak lebih bagi pencadangan maupun beban kerja.
Pisahkan data Anda ke beberapa instans: Dataset yang lebih kecil per instans mengurangi durasi pencadangan sekaligus I/O yang dihasilkan per sesi pencadangan.