Diagnostik pemecahan masalah performa SQL Hyperscale

  • Artikel

Berlaku untuk:Azure SQL Database

Untuk memecahkan masalah performa dalam database Hyperscale, metodologi penyetelan performa umum pada simpul komputasi Azure SQL Database adalah titik awal penyelidikan performa. Namun, mengingat arsitektur Hyperscale yang didistribusikan, diagnostik tambahan telah ditambahkan untuk membantu. Artikel ini mendeskripsikan data diagnostik khusus Hyperscale.

Penantian pembatasan laju log

Setiap tujuan layanan Azure SQL Database memiliki batas laju pembuatan log yang diberlakukan melalui tata kelola laju log. Di Hyperscale, batas tata kelola log diatur ke 105 MB/detik, terlepas dari tingkat layanan. Nilai ini diekspos dalam primary_max_log_rate kolom di sys.dm_user_db_resource_governance.

Namun, ada kalanya tingkat pembuatan log pada replika komputasi utama harus dibatasi untuk memelihara SLA pemulihan. Pembatasan ini terjadi ketika server halaman atau replika komputasi lain secara signifikan di belakang penerapan baris log baru dari layanan log. Jika tidak ada server halaman atau replika yang tertinggal, mekanisme pembatasan memungkinkan laju pembuatan log mencapai 100 MB/dtk. Ini adalah tingkat pembuatan log maksimum yang efektif di semua tujuan layanan Hyperscale.

Jenis tunggu berikut (di sys.dm_os_wait_stats) menjelaskan alasan mengapa laju log dapat dibatasi pada replika komputasi utama:

Jenis Tunggu Deskripsi
RBIO_RG_STORAGE Terjadi ketika laju pembuatan log simpul komputasi utama database Hyperscale sedang dibatasi karena konsumsi log tertunda di server halaman.
RBIO_RG_DESTAGE Terjadi ketika laju pembuatan log simpul komputasi database Hyperscale sedang dibatasi karena konsumsi log tertunda oleh penyimpanan log jangka panjang.
RBIO_RG_REPLICA Terjadi ketika laju pembuatan log simpul komputasi database Hyperscale sedang dibatasi karena konsumsi log tertunda oleh replika sekunder yang dapat dibaca.
RBIO_RG_GEOREPLICA Terjadi ketika laju pembuatan log simpul komputasi database Hyperscale sedang dibatasi karena konsumsi log tertunda oleh replika Geo-sekunder.
RBIO_RG_LOCALDESTAGE Terjadi ketika laju pembuatan log simpul komputasi database Hyperscale sedang dibatasi karena konsumsi log tertunda oleh layanan log.

Bacaan server halaman

Replika komputasi tidak men-cache salinan lengkap database secara lokal. Data lokal untuk replika komputasi disimpan di kumpulan buffer (dalam memori) dan di cache ekstensi kumpulan buffer tangguh (RBPEX) lokal yang merupakan cache parsial (tidak mencakup) halaman data. Cache RBPEX lokal ini berukuran proporsional dengan ukuran komputasi dan tiga kali memori tingkat komputasi. RBPEX mirip dengan kumpulan buffer karena memiliki data yang paling sering diakses. Setiap server halaman, di sisi lain, memiliki cache RBPEX yang mencakup untuk bagian database yang dipeliharanya.

Ketika baca dikeluarkan pada replika komputasi, jika data tidak ada di kumpulan buffer atau cache RBPEX lokal, panggilan fungsi getPage(pageId, Nomor Urutan Log) dikeluarkan, dan halaman diambil dari server halaman yang sesuai. Bacaan dari server halaman bacaan jarak jauh dan dengan demikian lebih lambat dari bacaan dari RBPEX lokal. Saat memecahkan masalah performa terkait IO, kita harus dapat mengetahui berapa banyak IO yang dilakukan melalui bacaan server halaman jarak jauh yang relatif lebih lambat.

Beberapa tampilan terkelola dinamis (DMV) dan peristiwa yang diperluas memiliki kolom dan bidang yang menentukan jumlah bacaan jarak jauh dari server halaman, yang dapat dibandingkan dengan total bacaan. Penyimpanan kueri juga mengambil bacaan jarak jauh sebagai bagian dari statistik durasi kueri.

<RunTimeCountersPerThread Thread="8" ActualRows="90466461" ActualRowsRead="90466461" Batches="0" ActualEndOfScans="1" ActualExecutions="1" ActualExecutionMode="Row" ActualElapsedms="133645" ActualCPUms="85105" ActualScans="1" ActualLogicalReads="6032256" ActualPhysicalReads="0" ActualPageServerReads="0" ActualReadAheads="6027814" ActualPageServerReadAheads="5687297" ActualLobLogicalReads="0" ActualLobPhysicalReads="0" ActualLobPageServerReads="0" ActualLobReadAheads="0" ActualLobPageServerReadAheads="0" />

Catatan

Untuk melihat atribut ini di jendela properti rencana kueri, diperlukan SQL Server Management Studio 18.3 atau yang lebih baru.

Statistik file virtual dan akuntansi IO

Di Azure SQL Database, sys.dm_io_virtual_file_stats() DMF adalah cara utama untuk memantau SQL Database IO. Karakteristik IO dalam Hyperscale berbeda karena arsitekturnya yang didistribusikan. Di bagian ini, kami fokus pada IO (baca dan tulis) ke file data seperti yang terlihat di DMF ini. Di Hyperscale, setiap file data yang terlihat di DMF ini sesuai dengan server halaman jarak jauh. Cache RBPEX yang disebutkan di sini adalah cache berbasis SSD lokal, yang merupakan cache yang tidak mencakup pada replika komputasi.

Penggunaan cache RBPEX lokal

Cache RBPEX lokal ada pada replika komputasi, pada penyimpanan SSD lokal. Dengan demikian, IO terhadap cache ini lebih cepat daripada IO terhadap server halaman jarak jauh. Saat ini, sys.dm_io_virtual_file_stats() dalam database Hyperscale memiliki baris khusus yang melaporkan IO terhadap cache RBPEX lokal pada replika komputasi. Baris ini memiliki nilai 0 untuk kedua kolom database_id dan file_id. Misalnya, kueri di bawah ini mengembalikan statistik penggunaan RBPEX sejak startup database.

select * from sys.dm_io_virtual_file_stats(0,NULL);

Rasio bacaan yang dilakukan pada RBPEX terhadap bacaan teragregat yang dilakukan pada semua file data lainnya menyediakan rasio hit cache RBPEX. Penghitung RBPEX cache hit ratio juga diekspos dalam penghitung kinerja DMV sys.dm_os_performance_counters.

Bacaan data

  • Ketika bacaan dikeluarkan oleh mesin database SQL Server pada replika komputasi, bacaan dapat dilayani baik oleh cache RBPEX lokal, atau oleh server halaman jarak jauh, atau dengan kombinasi keduanya jika membaca beberapa halaman.
  • Ketika replika komputasi membaca beberapa halaman dari file tertentu, misalnya file_id 1, jika data ini hanya berada di cache RBPEX lokal, semua IO untuk bacaan ini diperhitungkan terhadap file_id 0 (RBPEX). Jika beberapa bagian dari data tersebut ada di cache RBPEX lokal, dan beberapa bagian berada di server halaman jarak jauh, maka IO diperhitungkan menuju file_id 0 untuk bagian yang dilayani dari RBPEX, dan bagian yang dilayani dari server halaman jarak jauh diperhitungkan menuju file_id 1.
  • Ketika replika komputasi meminta halaman di Nomor Urutan Log tertentu dari server halaman, jika server halaman belum menangkap Nomor Urutan Log yang diminta, baca pada replika komputasi akan menunggu sampai server halaman mengejar ketinggalan sebelum halaman dikembalikan ke replika komputasi. Untuk setiap baca dari server halaman pada replika komputasi, Anda akan melihat jenis tunggu PAGEIOLATCH_ * jika menunggu di IO tersebut. Di Hyperscale, waktu tunggu ini mencakup waktu untuk mengejar halaman yang diminta di server halaman ke Nomor Urutan Log yang diperlukan, dan waktu yang diperlukan untuk mentransfer halaman dari server halaman ke replika komputasi.
  • Bacaan besar seperti baca dulu sering dilakukan menggunakan Bacaan "Scatter-Gather". Ini memungkinkan membaca hingga 4 MB halaman sekaligus, dianggap sebagai bacaan tunggal di mesin database SQL Server. Namun, ketika data yang dibaca ada di RBPEX, bacaan ini diperhitungkan sebagai beberapa bacaan 8-KB individu, karena kumpulan buffer dan RBPEX selalu menggunakan halaman 8-KB. Akibatnya, jumlah baca IO yang terlihat terhadap RBPEX mungkin lebih besar dari jumlah IO aktual yang dilakukan oleh mesin.

Penulisan data

  • Replika komputasi utama tidak menulis langsung ke server halaman. Sebagai gantinya, catatan log dari layanan log diputar ulang di server halaman terkait.
  • Tulisan yang terjadi pada replika komputasi sebagian besar ditulis ke RBPEX lokal (file_id 0). Untuk menulis pada file logis yang lebih besar dari 8 KB, dengan kata lain yang dilakukan menggunakan Kumpulkan-tulis, setiap operasi penulisan diterjemahkan ke dalam beberapa penulisan individu 8-KB ke RBPEX karena kumpulan buffer dan RBPEX selalu menggunakan halaman 8-KB. Akibatnya, jumlah tulis IO yang terlihat terhadap RBPEX mungkin lebih besar dari jumlah IO aktual yang dilakukan oleh mesin.
  • File non-RBPEX, atau file data selain file_id 0 yang sesuai dengan server halaman, juga menunjukkan tulisan. Dalam tingkat layanan Hyperscale, tulisan-tulisan ini disimulasikan, karena replika komputasi tidak pernah menulis langsung ke server halaman. Tulis IOPS dan throughput diperhitungkan saat terjadi pada replika komputasi, tetapi latensi untuk file data selain file_id 0 tidak mencerminkan latensi aktual penulisan server halaman.

Penulisan log

  • Pada komputasi utama, tulis log diperhitungkan dalam file_id 2 sys.dm_io_virtual_file_stats. Log yang ditulis pada komputasi utama adalah tulis ke Zona Pendaratan log.
  • Baris log tidak diperkeras pada replika sekunder pada penerapan. Di Hyperscale, log diterapkan oleh layanan log ke replika sekunder secara asinkron. Karena penulisan log tidak benar-benar terjadi pada replika sekunder, akuntansi log IOs pada replika sekunder hanya untuk tujuan pelacakan.

IO Data dalam statistik pemanfaatan sumber daya

Dalam database non-Hyperscale, gabungan baca dan tulis IOPS terhadap file data, relatif ke batas IOPS data pemerintahan sumber daya, dilaporkan dalam tampilan sys.dm_db_resource_stats dan sys.resource_stats, di avg_data_io_percent kolom. Nilai yang sama dilaporkan di portal Microsoft Azure sebagai Persentase IO Data.

Dalam database Hyperscale, kolom ini melaporkan penggunaan IOPS data relatif terhadap batas penyimpanan lokal hanya pada replika komputasi, khususnya IO terhadap RBPEX dan tempdb. Nilai 100% dalam kolom ini menunjukkan bahwa pemerintahan sumber daya membatasi IOPS penyimpanan lokal. Jika nilai ini berkorelasi dengan masalah performa, sesuaikan beban kerja untuk menghasilkan lebih sedikit IO, atau tingkatkan tujuan layanan database untuk meningkatkan batas Max Data IOPS tata kelola sumber daya. Untuk bacaan dan tulisan pemerintahan sumber daya RBPEX, sistem menghitung IO 8-KB individu, daripada IO yang lebih besar yang mungkin dikeluarkan oleh mesin database SQL Server.

IO data terhadap server halaman jarak jauh tidak dilaporkan dalam tampilan pemanfaatan sumber daya atau di portal, tetapi dilaporkan dalam DMF sys.dm_io_virtual_file_stats(), seperti yang disebutkan sebelumnya.

Sumber daya tambahan