Penyelingan kueri

Berlaku untuk: SQL Server Analysis Services Azure Analysis Services Fabric/Power BI Premium

Interleaving kueri adalah konfigurasi sistem mode tabular yang dapat meningkatkan performa kueri dalam skenario konkurensi tinggi. Secara default, mesin tabular Analysis Services bekerja dengan cara first-in, first-out (FIFO) sehubungan dengan CPU. Dengan FIFO, misalnya, jika satu sumber daya mahal dan mungkin lambat kueri mesin penyimpanan diterima, dan kemudian diikuti oleh dua kueri cepat lainnya, kueri cepat berpotensi diblokir menunggu kueri mahal selesai. Perilaku ini ditampilkan dalam diagram berikut, yang menunjukkan Q1, Q2 dan Q3 sebagai kueri masing-masing, durasinya, dan waktu CPU.

Pertama masuk, pertama keluar

Interleaving kueri dengan bias kueri singkat memungkinkan kueri bersamaan untuk berbagi sumber daya CPU, yang berarti kueri cepat tidak diblokir di belakang kueri lambat. Waktu yang diperlukan untuk menyelesaikan ketiga kueri masih hampir sama, tetapi dalam contoh kami Q2 dan Q3 tidak diblokir hingga akhir. Bias kueri pendek berarti kueri cepat, yang ditentukan oleh berapa banyak CPU yang telah digunakan setiap kueri pada titik waktu tertentu dapat dialokasikan proporsi sumber daya yang lebih tinggi daripada kueri yang berjalan lama. Dalam diagram berikut, kueri Q2 dan Q3 dianggap cepat dan dialokasikan lebih banyak CPU daripada Q1.

Bias kueri pendek

Interleaving kueri dimaksudkan untuk memiliki sedikit atau tanpa dampak performa pada kueri yang berjalan dalam isolasi; satu kueri masih dapat menggunakan CPU sebanyak yang dilakukannya dengan model FIFO.

Pertimbangan penting

Sebelum menentukan apakah interleaving kueri tepat untuk skenario Anda, ingatlah hal berikut:

  • Interleaving kueri hanya berlaku untuk model impor. Ini tidak memengaruhi model DirectQuery.
  • Interleaving kueri hanya mempertimbangkan CPU yang digunakan oleh kueri mesin penyimpanan VertiPaq. Ini tidak berlaku untuk operasi mesin rumus.
  • Satu kueri DAX dapat menghasilkan beberapa kueri mesin penyimpanan VertiPaq. Kueri DAX dianggap cepat atau lambat berdasarkan CPU yang digunakan oleh kueri mesin penyimpanannya. Kueri DAX adalah unit pengukuran.
  • Operasi refresh secara default dilindungi dari interleaving kueri. Operasi refresh jangka panjang dikategorikan secara berbeda untuk kueri yang berjalan lama.

Konfigurasikan

Untuk mengonfigurasi interleaving kueri, atur properti Threadpool\SchedulingBehavior . Properti ini dapat ditentukan dengan nilai berikut:

Nilai Deskripsi
-1 Otomatis. Mesin akan memilih jenis antrean.
0 (default untuk SSAS 2019) Pertama, keluar pertama (FIFO).
1 Bias kueri pendek. Mesin secara bertahap membatasi kueri yang berjalan lama ketika berada di bawah tekanan demi kueri cepat.
3 (default untuk Azure AS, Power BI, SSAS 2022 dan yang lebih baru) Bias kueri pendek dengan pembatalan cepat. Meningkatkan waktu respons kueri pengguna dalam skenario konkurensi tinggi. Berlaku untuk Azure AS, Power BI, SSAS 2022 dan yang lebih baru saja.

Saat ini, properti PenjadwalanBehavior hanya dapat diatur dengan menggunakan XMLA. Dalam SQL Server Management Studio, cuplikan XMLA berikut mengatur properti PenjadwalanBehavior ke 1, bias kueri singkat.

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ThreadPool\SchedulingBehavior</Name>
          <Value>1</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Penting

Menghidupkan ulang instans server diperlukan. Di Azure Analysis Services, Anda harus menjeda lalu melanjutkan server, memulai ulang secara efektif.

Properti tambahan

Dalam kebanyakan kasus, PenjadwalanBehavior adalah satu-satunya properti yang perlu Anda atur. Properti tambahan berikut ini memiliki default yang harus berfungsi dalam sebagian besar skenario dengan bias kueri singkat, namun properti tersebut dapat diubah jika diperlukan. Properti berikut ini tidak berpengaruh kecuali interleaving kueri diaktifkan dengan mengatur properti PenjadwalanBehavior.

ReservedComputeForFastQueries - Mengatur jumlah inti logis yang dipesan untuk kueri cepat . Semua kueri dianggap cepat sampai membusuk karena telah menggunakan sejumlah CPU. ReservedComputeForFastQueries adalah bilangan bulat antara 0 dan 100. Nilai defaultnya adalah 75.

Satuan ukuran untuk ReservedComputeForFastQueries adalah persentase inti. Misalnya, nilai 80 di server dengan 20 inti mencoba memesan 16 inti untuk kueri cepat (sementara tidak ada operasi refresh yang dilakukan). ReservedComputeForFastQueries membulatkan ke atas ke seluruh jumlah inti terdekat. Disarankan agar Anda tidak mengatur nilai properti ini di bawah 50. Ini karena kueri cepat dapat dicabut dan berlawanan dengan desain keseluruhan fitur.

DecayIntervalCPUTime - Bilangan bulat yang mewakili waktu CPU dalam milidetik yang dihabiskan kueri sebelum membusuk. Jika sistem berada di bawah tekanan CPU, kueri yang membusuk terbatas pada inti yang tersisa yang tidak dicadangkan untuk kueri cepat. Nilai defaultnya adalah 60.000. Ini mewakili 1 menit waktu CPU, bukan waktu kalender yang berlalu.

ReservedComputeForProcessing - Mengatur jumlah inti logis yang dipesan untuk setiap operasi pemrosesan (refresh data). Nilai properti adalah bilangan bulat antara 0 dan 100, dengan nilai default 75 dinyatakan. Nilai mewakili persentase inti yang ditentukan oleh properti ReservedComputeForFastQueries. Nilai 0 (nol) berarti operasi pemrosesan tunduk pada logika interleaving kueri yang sama dengan kueri, sehingga dapat dirusak.

Meskipun tidak ada operasi pemrosesan yang dilakukan, ReservedComputeForProcessing tidak berpengaruh. Misalnya, dengan nilai 80, ReservedComputeForFastQueries di server dengan 20 core mencadangkan 16 core untuk kueri cepat. Dengan nilai 75, ReservedComputeForProcessing kemudian akan memesan 12 dari 16 inti untuk operasi refresh, meninggalkan 4 untuk kueri cepat saat operasi pemrosesan berjalan dan menggunakan CPU. Seperti yang dijelaskan di bagian Kueri yang di-decayed di bawah ini, 4 core yang tersisa (tidak dicadangkan untuk kueri cepat atau operasi pemrosesan) masih akan digunakan untuk kueri dan pemrosesan cepat jika menganggur.

Properti tambahan ini terletak di bawah simpul properti ResourceGovernance . Dalam SQL Server Management Studio, contoh cuplikan XMLA berikut mengatur properti DecayIntervalCPUTime ke nilai yang lebih rendah dari default:

<Alter AllowCreate="true" ObjectExpansion="ObjectProperties" xmlns="http://schemas.microsoft.com/analysisservices/2003/engine">
  <Object />
  <ObjectDefinition>
    <Server xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:ddl2="http://schemas.microsoft.com/analysisservices/2003/engine/2" xmlns:ddl2_2="http://schemas.microsoft.com/analysisservices/2003/engine/2/2" xmlns:ddl100_100="http://schemas.microsoft.com/analysisservices/2008/engine/100/100" xmlns:ddl200="http://schemas.microsoft.com/analysisservices/2010/engine/200" xmlns:ddl200_200="http://schemas.microsoft.com/analysisservices/2010/engine/200/200" xmlns:ddl300="http://schemas.microsoft.com/analysisservices/2011/engine/300" xmlns:ddl300_300="http://schemas.microsoft.com/analysisservices/2011/engine/300/300" xmlns:ddl400="http://schemas.microsoft.com/analysisservices/2012/engine/400" xmlns:ddl400_400="http://schemas.microsoft.com/analysisservices/2012/engine/400/400" xmlns:ddl500="http://schemas.microsoft.com/analysisservices/2013/engine/500" xmlns:ddl500_500="http://schemas.microsoft.com/analysisservices/2013/engine/500/500">
      <ID>myserver</ID>
      <Name>myserver</Name>
      <ServerProperties>
        <ServerProperty>
          <Name>ResourceGovernance\DecayIntervalCPUTime</Name>
          <Value>15000</Value>
        </ServerProperty>
      </ServerProperties>
    </Server>
  </ObjectDefinition>
</Alter>

Kueri yang di-decay

Batasan yang dijelaskan di bagian ini hanya berlaku jika sistem berada di bawah tekanan CPU. Misalnya, satu kueri, jika itu satu-satunya yang berjalan dalam sistem pada waktu tertentu, dapat menggunakan semua inti yang tersedia terlepas dari apakah itu telah membusuk atau tidak.

Setiap kueri mungkin memerlukan banyak pekerjaan mesin penyimpanan. Ketika inti dalam kumpulan untuk kueri yang membusuk tersedia, penjadwal akan memeriksa kueri terlama yang berjalan berdasarkan waktu kalender yang berlalu untuk melihat apakah kueri tersebut telah menggunakan Pemberian Entitas Inti Maksimum (MCE). Jika tidak, pekerjaan berikutnya dijalankan. Jika ya, kueri terlama berikutnya dievaluasi. MCE kueri ditentukan oleh berapa banyak interval pembusukan yang telah digunakannya. Untuk setiap interval pembusukan yang digunakan, MCE dikurangi berdasarkan algoritma yang ditunjukkan pada tabel di bawah ini. Ini berlanjut hingga kueri selesai, waktu habis, atau MCE dikurangi menjadi satu inti.

Dalam contoh berikut, sistem memiliki 32 core, dan CPU sistem berada di bawah tekanan.

ReservedComputeForFastQueries adalah 60 (60%).

  • 20 core (19,2 dibulatkan ke atas) dicadangkan untuk kueri cepat.
  • 12 core yang tersisa dialokasikan untuk kueri yang membusuk.

DecayIntervalCPUTime adalah 60.000 (1 menit waktu CPU).

Siklus hidup kueri mungkin sebagai berikut, selama tidak habis atau selesai:

Tahap Status Eksekusi/penjadwalan MCE
0 Cepat MCE adalah 20 core (disediakan untuk kueri cepat).
Kueri dijalankan dengan cara FIFO sehubungan dengan kueri cepat lainnya di 20 inti yang dipesan.
Interval pembusukan 1 menit waktu CPU habis.
20 =
MIN(32/2˄0, 20)
1 Membusuk MCE diatur ke 12 core (12 core yang tersisa tidak dicadangkan untuk kueri cepat).
Pekerjaan dijalankan berdasarkan ketersediaan hingga MCE.
Interval pembusukan 1 menit waktu CPU habis.
12 =
MIN(32/2˄1, 12)
2 Membusuk MCE diatur ke 8 core (kuartal dari 32 total core).
Pekerjaan dijalankan berdasarkan ketersediaan hingga MCE.
Interval pembusukan 1 menit waktu CPU habis.
8 =
MIN(32/2˄2, 12)
3 Membusuk MCE diatur ke 4 core.
Pekerjaan dijalankan berdasarkan ketersediaan hingga MCE.
Interval pembusukan 1 menit waktu CPU habis.
4 =
MIN(32/2˄3, 12)
4 Membusuk MCE diatur ke 2 core.
Pekerjaan dijalankan berdasarkan ketersediaan hingga MCE.
Interval pembusukan 1 menit waktu CPU habis.
2 =
MIN(32/2˄4, 12)
5 Membusuk MCE diatur ke 1 core.
Pekerjaan dijalankan berdasarkan ketersediaan hingga MCE.
Interval pembusukan tidak berlaku karena kueri telah terbawah.
Tidak ada pembusuan lebih lanjut karena minimal 1 inti tercapai.
1 =
MIN(32/2˄5, 12)

Jika sistem berada di bawah tekanan CPU, setiap kueri akan ditetapkan tidak lebih banyak inti daripada MCE-nya. Jika semua inti saat ini digunakan oleh kueri dalam MCEs masing-masing, maka kueri lain menunggu hingga inti tersedia. Saat inti tersedia, kueri terlama yang berhak berdasarkan waktu kalender yang berlalu diambil. MCE adalah topi di bawah tekanan; itu tidak menjamin jumlah inti kapan saja.

Lihat juga

Properti server di Analysis Services