Bagikan melalui

Diagnostik pemecahan masalah performa SQL Hyperscale

Berlaku untuk:Azure SQL Database

Untuk memecahkan masalah performa dalam database Hyperscale, metodologi penyetelan performa SQL umum adalah titik awal penyelidikan performa apa pun. Namun, mengingat arsitektur Hyperscale yang didistribusikan, data diagnostik tambahan mungkin perlu dipertimbangkan. Artikel ini mendeskripsikan data diagnostik khusus Hyperscale.

Mengurangi waktu tunggu laju pencatatan

Setiap database dan kumpulan elastis di Azure SQL Database mengelola laju pembuatan log melalui tata kelola laju log . Batas laju log ditampilkan dalam primary_max_log_rate kolom pada sys.dm_user_db_resource_governance.

Terkadang, laju pembuatan log pada replika komputasi utama harus dikurangi untuk mempertahankan perjanjian tingkat layanan (SLA) pemulihan. Misalnya, ini dapat terjadi ketika server halaman atau replika komputasi lain tertinggal secara signifikan dalam mengaplikasikan rekaman log baru dari layanan log. Jika tidak ada komponen Hyperscale di belakang, mekanisme tata kelola laju log memungkinkan laju pembuatan log mencapai 150 MiB/dtk per database untuk perangkat keras seri premium dan perangkat keras yang dioptimalkan memori seri premium. Untuk perangkat keras seri standar, laju log maksimum adalah 100 MiB/dtk per database. Untuk kumpulan elastis, laju log maksimum adalah 150 MiB/dtk per kumpulan untuk perangkat keras yang dioptimalkan memori seri premium dan premium, dan 125 MiB/dtk per kumpulan untuk perangkat keras lainnya.

Jenis tunggu berikut muncul di sys.dm_os_wait_stats saat laju log berkurang:

Jenis tunggu Alasan
RBIO_RG_STORAGE Penggunaan log yang tertunda oleh server halaman
RBIO_RG_DESTAGE Penundaan pemrosesan log karena penyimpanan log jangka panjang
RBIO_RG_REPLICA Konsumsi log tertunda oleh replika sekunder HA atau replika bernama
RBIO_RG_GEOREPLICA Keterlambatan konsumsi log oleh replika sekunder-geografis
RBIO_RG_DESTAGE Konsumsi log yang tertunda oleh layanan log
RBIO_RG_LOCALDESTAGE Konsumsi log yang tertunda oleh layanan log
RBIO_RG_STORAGE_CHECKPOINT Konsumsi log tertunda oleh server penyajian karena titik pemeriksaan database yang lambat
RBIO_RG_MIGRATION_TARGET Konsumsi log tertunda oleh database non-Hyperscale selama migrasi terbalik

Fungsi manajemen dinamis (DMF ) sys.dm_hs_database_log_rate( ) memberikan detail selengkapnya untuk membantu Anda memahami pengurangan laju log, jika ada. Misalnya, ini dapat memberi tahu Anda replika sekunder tertentu mana yang berada di belakang penerapan rekaman log, dan berapa ukuran total log transaksi yang belum diterapkan.

Bacaan server halaman

Replika komputasi tidak menyimpan salinan lengkap database secara lokal. Data lokal untuk replika komputasi disimpan di kumpulan buffer (dalam memori) dan di cache ekstensi kumpulan buffer tangguh lokal (RBPEX) yang berisi subset halaman data yang paling sering diakses. Cache SSD lokal ini berukuran proporsional dengan ukuran komputasi. Di sisi lain, setiap server halaman memiliki cache SSD lengkap untuk bagian database yang dikelolanya.

Ketika permintaan IO baca diajukan pada replika komputasi, jika data tidak ada di kumpulan buffer atau di cache SSD lokal, halaman pada Nomor Urutan Log (LSN) yang diminta dengan diambil dari server halaman yang sesuai. Bacaan dari server halaman bersifat jarak jauh dan lebih lambat daripada bacaan dari cache SSD lokal. Saat memecahkan masalah performa terkait I/O, kita harus dapat mengetahui berapa banyak IO yang dilakukan melalui pembacaan server halaman 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. Query Store juga menangkap pembacaan server halaman dalam statistik waktu nyata kueri.

  • Kolom untuk melaporkan pembacaan server halaman tersedia dalam DMV eksekusi dan tampilan katalog:

  • Bidang baca server halaman ada dalam peristiwa yang diperluas berikut ini:

    • sql_statement_completed
    • sp_statement_completed
    • sql_batch_completed
    • rpc_completed
    • scan_stopped
    • query_store_begin_persist_runtime_stat
    • query_store_execution_runtime_info

  • ActualPageServerReads / ActualPageServerReadAheads atribut-atribut ada dalam rencana kueri XML untuk rencana yang menyertakan statistik runtime. Contohnya:

    <RunTimeCountersPerThread Thread="8" ActualRows="90466461" [...] ActualPageServerReads="0" ActualPageServerReadAheads="5687297" ActualLobPageServerReads="0" ActualLobPageServerReadAheads="0" />

    Saran

    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 salah satu cara untuk memantau statistik I/O database seperti IOPS, throughput, dan latensi. Karakteristik I/O dalam Hyperscale berbeda karena arsitektur terdistribusi . Di bagian ini, kami fokus pada I/O baca dan tulis seperti yang terlihat di DMF ini.

Untuk Hyperscale, data yang relevan adalah sys.dm_io_virtual_file_stats() sebagai berikut:

  • Baris-baris di mana nilai database_id cocok dengan nilai yang dikembalikan oleh fungsi DB_ID dan nilai file_id tidak sama dengan 2, sesuai dengan server halaman. Biasanya, setiap baris sesuai dengan satu server halaman web. Namun, untuk file yang lebih besar, beberapa server halaman digunakan.

    • Baris dengan file_id 2 sesuai dengan log transaksi.

  • Baris di mana nilai dalam kolom database_id adalah 0 sesuai dengan cache SSD lokal pada replika komputasi.

Penggunaan cache SSD lokal

Karena cache SSD lokal ada pada replika komputasi yang sama di mana mesin database memproses kueri, I/O terhadap cache ini lebih cepat daripada I/O terhadap server halaman. Dalam database Hyperscale atau kumpulan elastis, sys.dm_io_virtual_file_stats() memiliki baris khusus yang melaporkan statistik I/O untuk cache SSD lokal. Baris ini memiliki nilai 0 untuk kolom database_id. Misalnya, kueri berikut mengembalikan statistik I/O cache SSD lokal sejak memulai database.

SELECT *
FROM sys.dm_io_virtual_file_stats(0, NULL);

Rasio keberhasilan akses dari pembacaan agregat file cache SSD lokal terhadap pembacaan agregat dari semua file data lainnya adalah rasio keberhasilan akses cache SSD lokal. Metrik ini disediakan oleh penghitung kinerja RBPEX cache hit ratio dan RBPEX cache hit ratio base, yang tersedia di DMV sys.dm_os_performance_counters.

Bacaan data

  • Ketika pembacaan dikeluarkan oleh mesin database pada replika komputasi, mereka mungkin dilayani baik oleh cache SSD lokal, atau oleh server halaman, atau dengan kombinasi keduanya jika membaca beberapa halaman.

  • Ketika replika komputasi membaca beberapa halaman dari file data tertentu (misalnya, file dengan file_id 1), jika data ini hanya berada di cache SSD lokal, semua IO untuk bacaan ini diperhitungkan terhadap file cache SSD lokal di mana database_id 0. Jika beberapa bagian dari data tersebut berada di cache SSD lokal, dan beberapa bagian ada di server halaman, maka IO diperhitungkan sebagian terhadap file cache SSD lokal dan sebagian terhadap file data yang sesuai dengan server halaman.

  • Ketika replika komputasi meminta halaman di LSN tertentu dari server halaman, jika server halaman belum mencapai LSN yang diminta, operasi baca pada replika komputasi akan menunggu hingga server halaman mencapai LSN tersebut sebelum halaman dikembalikan. Untuk setiap pembacaan dari page server di replika komputasi, Anda akan melihat jenis tunggu PAGEIOLATCH_* jika IO tersebut sedang ditunggu. 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 read-ahead sering dilakukan menggunakan bacaan scatter-gather. Ini memungkinkan pembacaan data hingga 4 MB dalam satu operasi input/output baca. Namun, ketika data yang dibaca ada di cache SSD lokal, bacaan ini diperhitungkan sebagai beberapa pembacaan 8 KB individu, karena kumpulan buffer dan cache SSD lokal selalu menggunakan halaman 8-KB. Akibatnya, jumlah IO baca yang terpantau terhadap cache SSD lokal mungkin lebih besar dari jumlah aktual IO yang dieksekusi oleh mesin.

Penulisan data

  • Replika komputasi utama tidak menulis langsung ke server halaman. Sebagai gantinya, rekaman log dari layanan log diputar ulang di server halaman yang sesuai.

  • Penulisan pada replika komputasi sebagian besar ditulis ke cache SSD lokal (database_id 0). Untuk tulisan yang lebih besar dari 8 KB, yaitu yang dilakukan menggunakan gather-write, setiap operasi tulis diubah menjadi beberapa tulisan individu 8-KB ke cache SSD lokal karena kumpulan buffer dan cache SSD lokal selalu menggunakan halaman 8-KB. Akibatnya, jumlah IO tulis yang dilihat terhadap cache SSD lokal mungkin lebih besar dari jumlah IO aktual yang dilakukan oleh mesin.

  • File data lain selain database_id 0 yang terkait dengan server halaman mungkin juga menunjukkan penulisan data. Di Hyperscale, penulisan ini disimulasikan, karena replika komputasi tidak pernah menulis langsung ke server halaman. Statistik I/O diperhitungkan saat terjadi pada replika komputer. IOPS, throughput, dan latensi yang terlihat pada replika komputasi untuk file data selain database_id 0 tidak mencerminkan statistik I/O aktual dari penulisan yang terjadi pada server halaman.

Penulisan log

  • Pada replika komputasi utama, penulisan log diperhitungkan di sys.dm_io_virtual_file_stats() bawah file_id 2.

  • Tidak seperti dalam grup ketersediaan, ketika transaksi dilakukan pada replika komputasi utama, rekaman log tidak diperkuat pada replika sekunder. Di Hyperscale, log diperkuat dalam layanan log, dan diterapkan ke replika sekunder secara asinkron. Karena penulisan log tidak benar-benar terjadi pada replika sekunder, penghitungan IO log pada sys.dm_io_virtual_file_stats() dalam replika sekunder tidak boleh dipertimbangkan sebagai statistik I/O log transaksi.

IO Data dalam statistik pemanfaatan sumber daya

Dalam database non-Hyperscale, IOPS gabungan baca dan tulis terhadap file data relatif terhadap batas IO data tata kelola sumber daya, dilaporkan dalam tampilan sys.dm_db_resource_stats dan sys.resource_stats, pada kolom avg_data_io_percent. DMV yang sesuai untuk pool elastis adalah sys.dm_elastic_pool_resource_stats dan sys.elastic_pool_resource_stats. Nilai yang sama dilaporkan sebagai metrik Azure Monitor Persentase IO Data untuk database dan kumpulan elastis.

Dalam database Hyperscale, kolom dan metrik ini melaporkan pemanfaatan IO data relatif terhadap batas penyimpanan SSD lokal pada replika komputasi saja, yang mencakup I/O terhadap cache SSD lokal dan tempdb database. Nilai 100% dalam kolom ini menunjukkan bahwa pemerintahan sumber daya membatasi IOPS penyimpanan lokal. Jika ini berkorelasi dengan masalah performa, sesuaikan beban kerja untuk menghasilkan IO yang lebih sedikit, atau tingkatkan ukuran komputasi untuk meningkatkan pengelolaan sumber daya dan batas IOPS Data Maks. Untuk tata kelola sumber daya pembacaan dan penulisan cache SSD lokal, sistem menghitung IO 8-KB individual, daripada IO yang lebih besar yang mungkin dikeluarkan oleh mesin database.

IO data dari server halaman tidak dilaporkan dalam tampilan pemanfaatan sumber daya atau melalui metrik Azure Monitor, tetapi dilaporkan di sys.dm_io_virtual_file_stats() seperti yang dijelaskan sebelumnya.

Konten terkait

  • Last updated on