Bagikan melalui

Mendiagnosis dan memecahkan masalah CPU tinggi di Azure SQL Database

  • Artikel

Berlaku untuk: Azure SQL Database

Azure SQL Database menyediakan alat bawaan untuk mengidentifikasi penyebab penggunaan CPU tinggi dan untuk mengoptimalkan performa beban kerja. Anda dapat menggunakan alat ini untuk memecahkan masalah penggunaan CPU tinggi saat terjadi, atau secara reaktif setelah insiden selesai. Anda juga dapat mengaktifkan penyetelan otomatis untuk mengurangi penggunaan CPU secara proaktif seiring berjalannya waktu untuk database Anda. Artikel ini mengajari Anda cara mendiagnosis dan memecahkan masalah CPU tinggi dengan alat bawaan di Azure SQL Database dan menjelaskan kapan menambahkan sumber daya CPU.

Memahami jumlah vCore

Sangat membantu untuk memahami jumlah inti virtual (vCore) yang tersedia untuk database Anda saat mendiagnosis insiden CPU tinggi. VCore setara dengan CPU logis. Jumlah vCore membantu Anda memahami sumber daya CPU yang tersedia untuk database Anda.

Mengidentifikasi jumlah vCore di portal Microsoft Azure

Anda dapat dengan cepat mengidentifikasi jumlah vCore untuk database di portal Microsoft Azure jika Anda menggunakan tingkat layanan berbasis vCore dengan tingkat komputasi yang diprovisikan. Dalam kasus ini, tingkat harga yang tercantum untuk database tersebut di halaman Gambaran Umum akan berisi jumlah vCore. Misalnya, tingkat harga database mungkin 'Tujuan Umum: Seri standar (Gen5), 16 vCore'.

Untuk database di tingkat komputasi tanpa server, jumlah vCore akan selalu setara dengan pengaturan vCore maksimal untuk database. Jumlah vCore akan ditampilkan di tingkat harga yang dicantumkan untuk database di halaman Gambaran Umum. Misalnya, tingkat harga database mungkin 'Tujuan Umum: Tanpa Server, seri standar (Gen5), 16 vCore'.

Jika Anda menggunakan database pada model pembelian berbasis DTU, Anda perlu menggunakan T-SQL untuk mengkueri jumlah vCore database.

Mengidentifikasi jumlah vCore dengan Transact-SQL

Anda dapat mengidentifikasi jumlah vCore saat ini untuk database mana pun dengan Transact-SQL. Anda dapat menjalankan Transact-SQL terhadap Azure SQL Database dengan SQL Server Management Studio (SSMS), Azure Data Studio, atau editor kueri portal Azure.

Sambungkan ke database Anda dan jalankan kueri berikut:

SELECT 
    COUNT(*) as vCores
FROM sys.dm_os_schedulers
WHERE status = N'VISIBLE ONLINE';
GO

Mengidentifikasi penyebab CPU tinggi

Anda dapat mengukur dan menganalisis penggunaan CPU menggunakan portal Microsoft Azure, alat interaktif Query Store di SSMS, dan kueri Transact-SQL di SSMS dan Azure Data Studio.

Portal Microsoft Azure dan Query Store menampilkan statistik eksekusi, seperti metrik CPU, untuk kueri yang diselesaikan. Jika Anda mengalami insiden CPU tinggi saat ini yang mungkin disebabkan oleh satu atau beberapa kueri jangka panjang yang sedang berlangsung, identifikasi kueri yang sedang berjalan dengan Transact-SQL.

Penyebab umum penggunaan CPU tinggi yang baru dan tidak biasa adalah:

  • Kueri baru dalam beban kerja yang menggunakan CPU dalam jumlah besar.
  • Peningkatan frekuensi kueri yang berjalan secara rutin.
  • Regresi rencana kueri, termasuk regresi akibat masalah rencana sensitif parameter (PSP), yang menyebabkan satu atau lebih kueri menghabiskan CPU yangg lebih besar.
  • Peningkatan signifikan dalam kompilasi atau kompilasi ulang rencana kueri.
  • Database tempat kueri menggunakan paralelisme yang berlebihan.

Untuk memahami penyebab insiden CPU tinggi, identifikasi kapan penggunaan CPU tinggi terjadi terhadap database dan kueri teratas yang menggunakan CPU pada saat itu.

Periksa:

Catatan

Azure SQL Database memerlukan sumber daya komputasi untuk menerapkan fitur layanan inti seperti ketersediaan tinggi dan pemulihan bencana, pencadangan dan pemulihan database, pemantauan, Penyimpanan Kueri, penyetelan otomatis, dll. Penggunaan sumber daya komputasi ini mungkin sangat terlihat pada database dengan jumlah vCore atau database rendah di kumpulan elastis yang padat. Pelajari selengkapnya di Manajemen sumber daya di Azure SQL Database.

Gunakan portal Microsoft Azure untuk melacak berbagai metrik CPU, termasuk persentase CPU yang tersedia yang digunakan oleh database Anda seiring waktu. Portal Microsoft Azure mengombinasikan metrik CPU dengan informasi dari Query Store database Anda, yang memungkinkan Anda mengidentifikasi kueri mana yang menggunakan CPU dalam database pada waktu tertentu.

Ikuti langkah-langkah ini untuk menemukan metrik persentase CPU.

  1. Arahkan ke database di portal Microsoft Azure.
  2. Pada Performa Cerdas di menu sebelah kiri, pilih Wawasan Performa Kueri.

Tampilan default Wawasan Performa Kueri menampilkan data 24 jam. Penggunaan CPU ditampilkan sebagai persentase total CPU yang tersedia yang digunakan untuk database.

Lima kueri teratas yang berjalan dalam periode tersebut ditampilkan dalam bilah vertikal di atas grafik penggunaan CPU. Pilih pita waktu pada bagan atau gunakan menu Kustomisasi untuk menjelajahi periode waktu tertentu. Anda juga dapat meningkatkan jumlah kueri yang ditampilkan.

Cuplikan layar memperlihatkan Wawasan Performa Kueri di portal Azure.

Pilih setiap ID kueri yang menunjukkan CPU tinggi untuk membuka detail kueri tersebut. Detail menyertakan teks kueri beserta riwayat performa untuk kueri tersebut. Periksa apakah CPU telah meningkat untuk kueri baru-baru ini.

Catat ID kueri untuk menyelidiki lebih lanjut rencana kueri menggunakan Query Store di bagian berikut ini.

Meninjau rencana kueri untuk kueri teratas yang diidentifikasi dalam portal Microsoft Azure

Ikuti langkah-langkah ini untuk menggunakan ID kueri di alat Query Store interaktif SSMS untuk memeriksa rencana eksekusi kueri seiring waktu.

  1. Buka SQL Server Management Studio.
  2. Sambungkan ke Azure SQL Database di Object Explorer.
  3. Perluas simpul database di Object Explorer.
  4. Luaskan folder Query Store.
  5. Buka panel Kueri yang Dilacak.
  6. Masukkan ID kueri di kotak Melacak kueri di bagian kiri atas layar dan tekan enter.
  7. Jika perlu, pilih Konfigurasikan untuk menyesuaikan interval waktu untuk mencocokkan dengan waktu saat penggunaan CPU tinggi terjadi.

Halaman akan menampilkan rencana eksekusi dan metrik terkait untuk kueri tersebut selama 24 jam terakhir.

Mengidentifikasi kueri yang saat ini berjalan dengan Transact-SQL

Transact-SQL memungkinkan Anda untuk mengidentifikasi kueri yang saat ini berjalan dengan waktu CPU yang telah digunakan selama ini. Anda juga dapat menggunakan Transact-SQL untuk mengkueri penggunaan CPU terbaru dalam database, kueri teratas berdasarkan CPU, dan kueri yang paling sering dikompilasi.

Anda dapat mengkueri metrik CPU dengan SQL Server Management Studio (SSMS), Azure Data Studio, atau editor kueri portal Azure. Saat menggunakan SQL Server Management Studio atau Azure Data Studio, buka jendela kueri baru dan sambungkan ke database Anda (bukan master database).

Temukan kueri yang saat ini berjalan dengan penggunaan CPU dan rencana eksekusi dengan menjalankan kueri berikut. Waktu CPU ditampilkan dalam milidetik.

SELECT
    req.session_id,
    req.status,
    req.start_time,
    req.cpu_time AS 'cpu_time_ms',
    req.logical_reads,
    req.dop,
    s.login_name,
    s.host_name,
    s.program_name,
    object_name(st.objectid,st.dbid) 'ObjectName',
    REPLACE (REPLACE (SUBSTRING (st.text,(req.statement_start_offset/2) + 1,
        ((CASE req.statement_end_offset    WHEN -1    THEN DATALENGTH(st.text) 
        ELSE req.statement_end_offset END - req.statement_start_offset)/2) + 1),
        CHAR(10), ' '), CHAR(13), ' ') AS statement_text,
    qp.query_plan,
    qsx.query_plan as query_plan_with_in_flight_statistics
FROM sys.dm_exec_requests as req  
JOIN sys.dm_exec_sessions as s on req.session_id=s.session_id
CROSS APPLY sys.dm_exec_sql_text(req.sql_handle) as st
OUTER APPLY sys.dm_exec_query_plan(req.plan_handle) as qp
OUTER APPLY sys.dm_exec_query_statistics_xml(req.session_id) as qsx
ORDER BY req.cpu_time desc;
GO

Kueri ini menampilkan dua salinan rencana eksekusi. Kolom query_plan berisi rencana eksekusi dari sys.dm_exec_query_plan. Versi rencana kueri ini hanya berisi perkiraan jumlah baris dan tidak berisi statistik eksekusi apa pun.

Jika kolom query_plan_with_in_flight_statistics menampilkan rencana eksekusi, rencana ini menyediakan lebih banyak informasi. Kolom query_plan_with_in_flight_statistics mengembalikan data dari sys.dm_exec_query_statistics_xml, yang mencakup statistik eksekusi "dalam penerbangan" seperti jumlah baris aktual yang dikembalikan sejauh ini oleh kueri yang sedang berjalan.

Meninjau metrik penggunaan CPU selama satu jam terakhir

Kueri berikut terhadap sys.dm_db_resource_stats menampilkan penggunaan CPU rata-rata selama interval 15 detik untuk kira-kira satu jam terakhir.

SELECT
    end_time,
    avg_cpu_percent,
    avg_instance_cpu_percent
FROM sys.dm_db_resource_stats
ORDER BY end_time DESC; 
GO

Penting untuk tidak hanya fokus pada kolom avg_cpu_percent. Kolom avg_instance_cpu_percent meliputi CPU yang digunakan oleh kedua pengguna dan beban kerja internal. Jika avg_instance_cpu_percent mendekati 100%, sumber daya CPU menjadi jenuh. Dalam hal ini, Anda harus memecahkan masalah CPU tinggi jika throughput aplikasi tidak cukup atau latensi kueri tinggi.

Pelajari selengkapnya di Manajemen sumber daya di Azure SQL Database.

Tinjau contoh dalam sys.dm_db_resource_stats untuk kueri lainnya.

Mengkueri 15 kueri terkini teratas berdasarkan penggunaan CPU

Query Store melacak statistik eksekusi, termasuk penggunaan CPU, untuk kueri. Kueri berikut menampilkan 15 kueri teratas yang telah berjalan dalam 2 jam terakhir, yang diurutkan menurut penggunaan CPU. Waktu CPU ditampilkan dalam milidetik.

WITH AggregatedCPU AS 
    (SELECT
        q.query_hash, 
        SUM(count_executions * avg_cpu_time / 1000.0) AS total_cpu_ms, 
        SUM(count_executions * avg_cpu_time / 1000.0)/ SUM(count_executions) AS avg_cpu_ms, 
        MAX(rs.max_cpu_time / 1000.00) AS max_cpu_ms, 
        MAX(max_logical_io_reads) max_logical_reads, 
        COUNT(DISTINCT p.plan_id) AS number_of_distinct_plans, 
        COUNT(DISTINCT p.query_id) AS number_of_distinct_query_ids, 
        SUM(CASE WHEN rs.execution_type_desc='Aborted' THEN count_executions ELSE 0 END) AS aborted_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Regular' THEN count_executions ELSE 0 END) AS regular_execution_count, 
        SUM(CASE WHEN rs.execution_type_desc='Exception' THEN count_executions ELSE 0 END) AS exception_execution_count, 
        SUM(count_executions) AS total_executions, 
        MIN(qt.query_sql_text) AS sampled_query_text
    FROM sys.query_store_query_text AS qt
    JOIN sys.query_store_query AS q ON qt.query_text_id=q.query_text_id
    JOIN sys.query_store_plan AS p ON q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats AS rs ON rs.plan_id=p.plan_id
    JOIN sys.query_store_runtime_stats_interval AS rsi ON rsi.runtime_stats_interval_id=rs.runtime_stats_interval_id
    WHERE 
            rs.execution_type_desc IN ('Regular', 'Aborted', 'Exception') AND 
        rsi.start_time>=DATEADD(HOUR, -2, GETUTCDATE())
     GROUP BY q.query_hash), 
OrderedCPU AS 
    (SELECT *, 
    ROW_NUMBER() OVER (ORDER BY total_cpu_ms DESC, query_hash ASC) AS RN
    FROM AggregatedCPU)
SELECT *
FROM OrderedCPU AS OD
WHERE OD.RN<=15
ORDER BY total_cpu_ms DESC;
GO

Kueri ini mengelompokkan berdasarkan nilai hashed kueri. Jika Anda menemukan nilai yang tinggi pada kolom number_of_distinct_query_ids, selidiki apakah kueri yang sering dijalankan tidak diberi parameter dengan benar. Kueri non-parameter mungkin dikompilasi pada setiap eksekusi, yang menggunakan CPU yang signifikan dan memengaruhi performa Penyimpanan Kueri.

Untuk mempelajari selengkapnya kueri individual, catat hash kueri dan gunakan hash tersebut untuk Mengidentifikasi penggunaan CPU dan rencana kueri untuk hash kueri yang ditentukan.

Mengkuerikan kueri yang paling sering dikompilasi berdasarkan hash kueri

Menyusun rencana kueri merupakan proses yang menggunakan CPU secara intensif. Rencana cache Azure SQL Database dalam memori untuk digunakan kembali. Beberapa kueri mungkin sering dikompilasi jika tidak diparameterkan atau jika petunjuk RECOMPILE memaksa kompilasi ulang.

Query Store melacak berapa kali kueri dikompilasi. Jalankan kueri berikut untuk mengidentifikasi 20 kueri teratas di Query Store berdasarkan jumlah kompilasi, beserta jumlah kompilasi rata-rata per menit:

SELECT TOP (20)
    query_hash,
    MIN(initial_compile_start_time) as initial_compile_start_time,
    MAX(last_compile_start_time) as last_compile_start_time,
    CASE WHEN DATEDIFF(mi,MIN(initial_compile_start_time), MAX(last_compile_start_time)) > 0
        THEN 1.* SUM(count_compiles) / DATEDIFF(mi,MIN(initial_compile_start_time), 
            MAX(last_compile_start_time)) 
        ELSE 0 
        END as avg_compiles_minute,
    SUM(count_compiles) as count_compiles
FROM sys.query_store_query AS q
GROUP BY query_hash
ORDER BY count_compiles DESC;
GO

Untuk mempelajari selengkapnya kueri individual, catat hash kueri dan gunakan hash tersebut untuk Mengidentifikasi penggunaan CPU dan rencana kueri untuk hash kueri yang ditentukan.

Mengidentifikasi penggunaan CPU dan rencana kueri untuk hash kueri tertentu

Jalankan kueri berikut untuk menemukan ID kueri individu, teks kueri, dan rencana eksekusi kueri untuk query_hash tertentu. Waktu CPU ditampilkan dalam milidetik.

Ganti nilai untuk variabel @query_hash dengan query_hash yang valid untuk beban kerja Anda.

declare @query_hash binary(8);

SET @query_hash = 0x6557BE7936AA2E91;

with query_ids as (
    SELECT
        q.query_hash,
        q.query_id,
        p.query_plan_hash,
        SUM(qrs.count_executions) * AVG(qrs.avg_cpu_time)/1000. as total_cpu_time_ms,
        SUM(qrs.count_executions) AS sum_executions,
        AVG(qrs.avg_cpu_time)/1000. AS avg_cpu_time_ms
    FROM sys.query_store_query q
    JOIN sys.query_store_plan p on q.query_id=p.query_id
    JOIN sys.query_store_runtime_stats qrs on p.plan_id = qrs.plan_id
    WHERE q.query_hash = @query_hash
    GROUP BY q.query_id, q.query_hash, p.query_plan_hash)
SELECT qid.*,
    qt.query_sql_text,
    p.count_compiles,
    TRY_CAST(p.query_plan as XML) as query_plan
FROM query_ids as qid
JOIN sys.query_store_query AS q ON qid.query_id=q.query_id
JOIN sys.query_store_query_text AS qt on q.query_text_id = qt.query_text_id
JOIN sys.query_store_plan AS p ON qid.query_id=p.query_id and qid.query_plan_hash=p.query_plan_hash
ORDER BY total_cpu_time_ms DESC;
GO

Kueri ini menampilkan satu baris untuk setiap variasi rencana eksekusi untuk query_hash di seluruh riwayat Query Store Anda. Hasil diurutkan berdasarkan total waktu CPU.

Menggunakan alat Query Store interaktif untuk melacak penggunaan CPU historis

Jika Anda lebih memilih untuk menggunakan alat grafis, ikuti langkah-langkah ini untuk menggunakan alat Query Store interaktif di SSMS.

  1. Buka SSMS dan sambungkan ke database Anda di Object Explorer.
  2. Memperluas node database di Object Explorer
  3. Luaskan folder Query Store.
  4. Buka panel Konsumsi Sumber Daya Keseluruhan.

Total waktu CPU untuk database Anda selama satu bulan terakhir dalam milidetik ditampilkan di bagian kiri bawah panel. Dalam tampilan default, waktu CPU diagregatkan berdasarkan hari.

Cuplikan layar memperlihatkan tampilan Konsumsi Sumber Daya Keseluruhan Penyimpanan Kueri di SSMS.

Pilih Konfigurasikan di bagian kanan atas panel untuk memilih periode waktu yang berbeda. Anda juga dapat mengubah unit agregasi. Misalnya, Anda dapat memilih untuk melihat data untuk rentang tanggal tertentu dan mengagregasikan data berdasarkan jam.

Menggunakan alat Query Store interaktif untuk mengidentifikasi kueri teratas berdasarkan waktu CPU

Pilih bilah dalam bagan untuk menelusuri dan melihat kueri yang berjalan dalam periode waktu tertentu. Panel Kueri Teratas dalam Mengonsumsi Sumber Daya akan terbuka. Selain itu, Anda dapat membuka Kueri Teratas dalam Mengonsumsi Sumber Daya dari node Query Store pada database di Object Explorer secara langsung.

Cuplikan layar memperlihatkan panel Kueri Penggunaan Sumber Daya Teratas untuk Penyimpanan Kueri di S S M S.

Pada tampilan default, panel Kueri Teratas dalam Mengonsumsi Sumber Daya menampilkan kueri berdasarkan Durasi (md). Durasi terkadang mungkin lebih rendah daripada waktu CPU: kueri yang menggunakan paralelisme mungkin menggunakan lebih banyak waktu CPU daripada durasi keseluruhannya. Durasi mungkin juga lebih tinggi daripada waktu CPU jika waktu tunggu signifikan. Untuk melihat kueri berdasarkan waktu CPU, pilih drop-down Metrik di bagian kiri atas panel dan pilih Waktu CPU (md).

Setiap bilah dalam kuadran kiri atas mewakili kueri. Pilih bilah untuk melihat detail kueri tersebut. Kuadran kanan atas layar menampilkan berapa banyak rencana eksekusi di Query Store untuk kueri tersebut dan memetakannya menurut waktu eksekusi dan berapa banyak metrik pilihan Anda yang digunakan. Pilih setiap ID Rencana untuk mengontrol rencana eksekusi kueri mana yang ditampilkan di bagian bawah layar.

Catatan

Untuk panduan menginterpretasikan tampilan Query Store dan bentuk yang muncul di tampilan Pengonsumsi Sumber Daya Teratas, lihat Praktik terbaik dengan Query Store

Mengurangi penggunaan CPU

Sebagian pemecahan masalah Anda harus mencakup mempelajari selengkapnya kueri yang diidentifikasi pada bagian sebelumnya. Anda dapat mengurangi penggunaan CPU dengan menyetel indeks, memodifikasi pola aplikasi, menyetel kueri, dan menyesuaikan pengaturan terkait CPU untuk database Anda.

Pertimbangkan strategi berikut pada bagian ini.

Mengurangi penggunaan CPU dengan penyetelan indeks otomatis

Penyetelan indeks yang efektif mengurangi penggunaan CPU untuk berbagai kueri. Indeks yang dioptimalkan mengurangi pembacaan logis dan fisik untuk kueri, yang sering kali menghasilkan kueri dengan pekerjaan yang lebih sedikit.

Azure SQL Database menawarkan manajemen indeks otomatis untuk beban kerja di replika utama. Manajemen indeks otomatis menggunakan pembelajaran mesin untuk memantau beban kerja Anda dan mengoptimalkan indeks non-kluster berbasis disk penyimpanan baris untuk database Anda.

Tinjau rekomendasi performa, termasuk rekomendasi indeks, di portal Microsoft Azure. Anda dapat menerapkan rekomendasi ini secara manual atau mengaktifkan opsi penyetelan otomatis CREATE INDEX untuk membuat dan memverifikasi performa indeks baru di database.

Mengurangi penggunaan CPU dengan koreksi rencana otomatis (paksa rencana)

Penyebab umum insiden CPU tinggi lainnya adalah regresi pilihan rencana eksekusi. Azure SQL Database menawarkan opsi penyetelan otomatis paksa rencana untuk mengidentifikasi regresi pada rencana eksekusi kueri dalam beban kerja di replika utama. Dengan diaktifkannya fitur penyetelan otomatis ini, Azure SQL Database akan menguji apakah memaksa rencana eksekusi kueri menghasilkan performa yang meningkat dan dapat diandalkan untuk kueri dengan regresi rencana eksekusi.

Jika database Anda dibuat setelah bulan Maret 2020, opsi penyetelan otomatis paksa rencana diaktifkan secara otomatis. Jika database Anda dibuat sebelum waktu ini, Anda mungkin ingin mengaktifkan opsi penyetelan otomatis paket paksa.

Menyetel indeks secara manual

Gunakan metode yang dijabarkan dalam Mengidentifikasi penyebab CPU tinggi guna mengidentifikasi rencana kueri untuk kueri teratas yang menggunakan CPU. Rencana eksekusi ini akan membantu Anda dalam mengindentifikasi dan menambahkan indeks non-kluster untuk mempercepat kueri Anda.

Setiap indeks non-kluster berbasis disk di database Anda memerlukan ruang penyimpanan dan harus dikelola oleh mesin SQL. Modifikasi indeks yang ada alih-alih menambahkan indeks baru jika memungkinkan dan pastikan bahwa indeks baru berhasil mengurangi penggunaan CPU. Untuk gambaran umum indeks non-kluster, lihat Panduan Desain Indeks Non-Kluster.

Untuk beberapa beban kerja, indeks penyimpan kolom mungkin menjadi pilihan terbaik untuk mengurangi CPU kueri baca yang sering dibaca. Lihat Indeks penyimpan kolom - Panduan desain untuk rekomendasi tingkat tinggi tentang skenario saat indeks penyimpan kolom mungkin sesuai.

Menyetel aplikasi, kueri, dan pengaturan database Anda

Dalam memeriksa kueri teratas, Anda mungkin menemukan antipattern aplikasi seperti perilaku "cerewet", beban kerja yang akan mendapat manfaat dari sharding, dan desain akses database suboptimal. Untuk beban kerja intensif-baca, pertimbangkan replika baca-saja untuk memindahkan beban kerja kueri baca-saja dan caching tingkat-aplikasi sebagai strategi jangka panjang untuk meluaskan skala data yang sering dibaca.

Anda juga dapat memilih untuk menyetel CPU teratas secara manual menggunakan kueri yang diidentifikasi dalam beban kerja Anda. Opsi penyetelan manual mencakup menulis ulang pernyataan Transact-SQL, memaksa rencana di Query Store, dan menerapkan petunjuk kueri.

Jika Anda mengidentifikasi kasus di mana kueri terkadang menggunakan rencana eksekusi yang tidak optimal untuk performa, tinjau solusi dalam kueri yang masalah rencana sensitif parameter (PSP)

Jika Anda mengidentifikasi kueri non-parameter dengan rencana dalam jumlah besar, pertimbangkan untuk menerapkan parameterisasi pada kueri ini, pastikan untuk mendeklarasikan jenis data parameter sepenuhnya, termasuk panjang dan presisi. Ini mungkin dilakukan dengan memodifikasi kueri, membuat panduan rencana untuk memaksa parameterisasi kueri tertentu, atau dengan mengaktifkan parameterisasi paksa di tingkat database.

Jika Anda mengidentifikasi kueri dengan tingkat kompilasi yang tinggi, identifikasi penyebab seringnya terjadi kompilasi. Penyebab paling umum kompilasi yang sering terjadi adalah petunjuk RECOMPILE. Jika memungkinkan, identifikasi kapan petunjuk RECOMPILE ditambahkan dan apa masalah yang seharusnya dipecahkan. Selidiki apakah solusi penyetelan performa alternatif dapat diterapkan untuk memberikan performa yang konsisten untuk kueri yang sering berjalan tanpa petunjuk RECOMPILE.

Mengurangi penggunaan CPU dengan menyetel derajat paralelisme maksimum

Pengaturan derajat paralelisme maksimum (MAXDOP) mengontrol paralelisme intra-kueri dalam mesin database. Nilai MAXDOP yang lebih tinggi umumnya menghasilkan lebih banyak utas paralel per kueri, dan eksekusi kueri yang lebih cepat.

Dalam beberapa kasus, sejumlah besar kueri paralel yang berjalan bersamaan dapat memperlambat beban kerja dan menyebabkan penggunaan CPU tinggi. Paralelisme yang berlebihan kemungkinan besar terjadi pada database dengan vCore dalam jumlah besar tempat MAXDOP diatur ke angka tinggi atau ke nol. Saat MAXDOP diatur ke nol, mesin database mengatur jumlah penjadwal yang akan digunakan oleh rangkaian paralel ke jumlah total inti logis atau 64, tergantung mana yang lebih kecil.

Anda dapat mengidentifikasi pengaturan derajat paralelisme maksimum untuk database Anda dengan Transact-SQL. Sambungkan ke database Anda dengan SSMS atau Azure Data Studio dan jalankan kueri berikut:

SELECT 
    name, 
    value, 
    value_for_secondary, 
    is_value_default 
FROM sys.database_scoped_configurations
WHERE name=N'MAXDOP';
GO

Pertimbangkan untuk bereksperimen dengan perubahan kecil dalam konfigurasi MAXDOP di tingkat database, atau memodifikasi kueri bermasalah individual untuk menggunakan MAXDOP yang tidak terdefault menggunakan petunjuk kueri. Untuk informasi selengkapnya, lihat contoh dalam mengonfigurasi derajat paralelisme maksimum.

Kapan harus menambahkan sumber daya CPU

Anda mungkin menemukan bahwa kueri dan indeks beban kerja Anda disetel dengan benar, atau penyetelan performa memerlukan perubahan yang tidak dapat Anda buat dalam jangka pendek karena proses internal atau alasan lain. Menambahkan lebih banyak sumber daya CPU mungkin bermanfaat untuk database ini. Anda dapat menskalakan sumber daya database dengan waktu henti minimal.

Anda dapat menambahkan lebih banyak sumber daya CPU pada Azure SQL Database dengan mengonfigurasi jumlah vCore atau konfigurasi perangkat keras untuk database menggunakan model pembelian vCore.

Pada model pembelian berbasis DTU, Anda dapat meningkatkan tingkat layanan dan meningkatkan jumlah unit transaksi database (DTU). DTU mewakili ukuran campuran CPU, memori, baca, dan tulis. Salah satu manfaat model pembelian vCore adalah model ini memungkinkan kontrol yang lebih rinci atas perangkat keras yang digunakan serta jumlah vCore. Anda dapat memigrasikan Azure SQL Database dari model berbasis DTU ke model berbasis vCore untuk transisi antar model pembelian.

Konten terkait

Pelajari selengkapnya pemantauan dan penyetelan performa Azure SQL Database dalam artikel berikut: