Apa sih DTU itu?

Penulis Tamu :Andy Mallon (@AMtwo)

Tidak, serius. Apa itu DTU?

Saat Anda menerapkan aplikasi apa pun, salah satu pertanyaan pertama yang muncul adalah "Berapa biayanya?" Sebagian besar dari kita telah melalui latihan semacam ini untuk mengukur instalasi SQL Server di beberapa titik, tetapi bagaimana jika Anda menggunakan cloud? Dengan penerapan Azure IaaS, tidak banyak yang berubah–Anda masih membangun server berdasarkan jumlah CPU, sejumlah memori, dan mengonfigurasi penyimpanan untuk memberi Anda IOPS yang cukup untuk beban kerja Anda. Namun, saat Anda melakukan lompatan ke PaaS, Azure SQL Database berukuran dengan tingkat layanan yang berbeda, di mana kinerja diukur dalam DTU. Apa itu DTU?

Saya tahu apa itu BTU. Mungkin DTU adalah singkatan dari Database Thermal Unit? Apakah ini jumlah daya pemrosesan yang dibutuhkan untuk menaikkan suhu pusat data satu derajat? Daripada menebak-nebak, mari periksa dokumentasinya, dan lihat apa yang dikatakan Microsoft:

Oke, itu tebakan kedua saya–tapi apa itu "ukuran campuran"? Bagaimana cara menerjemahkan apa yang saya ketahui tentang ukuran server menjadi ukuran Database Azure SQL? Sayangnya, tidak ada cara langsung untuk menerjemahkan "2 inti CPU, dan memori 4 GB" ke dalam pengukuran DTU.

Apakah tidak ada Kalkulator DTU?

Ya! Microsoft memberi kami Kalkulator DTU untuk memperkirakan tingkat layanan yang tepat dari Azure SQL Database. Untuk menggunakannya, Anda mengunduh dan menjalankan skrip PowerShell (sql-perfmon.ps1) di server saat menjalankan beban kerja di SQL Server. Skrip mengeluarkan CSV yang berisi empat penghitung kinerja:(1) total % waktu prosesor, (2) total pembacaan disk/detik, (3) total penulisan disk per detik, dan (4) total byte log yang dihapus/detik. Keluaran CSV ini kemudian diunggah ke Kalkulator DTU, yang memperkirakan tingkat layanan yang paling sesuai dengan kebutuhan Anda. Satu-satunya data yang diambil Kalkulator DTU selain CSV adalah jumlah inti CPU di server yang menghasilkan file. Kalkulator DTU masih berupa kotak hitam–tidak mudah untuk memetakan apa yang kami ketahui dari database lokal kami ke Azure.

Saya ingin menunjukkan bahwa definisi DTU adalah "ukuran campuran CPU, memori , dan data I/O dan log transaksi I/O..." Tak satu pun dari penghitung kinerja yang digunakan oleh Kalkulator DTU memperhitungkan memori, tetapi jelas tercantum dalam definisi sebagai bagian dari perhitungan. Ini belum tentu merupakan masalah, tetapi ini adalah bukti bahwa Kalkulator DTU tidak akan sempurna.

Saya akan mengunggah beberapa beban sintetis ke Kalkulator DTU, dan melihat apakah saya dapat mengetahui cara kerja kotak hitam itu. Sebenarnya, saya akan membuat CSV sepenuhnya sehingga saya benar-benar dapat mengontrol angka perfmon yang kami muat ke Kalkulator DTU. Mari kita melangkah melalui satu metrik pada satu waktu. Untuk setiap metrik, kami akan mengunggah data yang dibuat selama 25 menit (1500 detik–Saya suka angka bulat), dan melihat bagaimana data kinerja tersebut dikonversi ke DTU.

CPU

Saya akan membuat CSV yang mensimulasikan server 16-core, perlahan-lahan meningkatkan penggunaan CPU hingga dipatok 100%. Karena saya akan mensimulasikan ramp-up pada server 16-core, saya akan membuat CSV saya untuk meningkatkan 1/16 pada satu waktu-pada dasarnya mensimulasikan satu inti memaksimalkan, lalu yang kedua memaksimalkan, lalu yang ketiga, dll. Sementara itu, CSV akan menampilkan nol pembacaan, penulisan, dan log flush. Server tidak akan pernah benar-benar menghasilkan beban kerja seperti ini–tetapi itulah intinya. Saya mengisolasi penggunaan CPU sepenuhnya sehingga saya dapat melihat bagaimana CPU memengaruhi DTU.

Saya akan membuat file CSV yang memiliki satu baris per detik, dan setiap 94 detik, saya akan meningkatkan % penghitung waktu prosesor Total sebesar ~6%. Tiga penghitung lainnya akan menjadi nol dalam semua kasus. Sekarang, saya mengunggah file ini ke Kalkulator DTU (dan memberi tahu Kalkulator DTU untuk mempertimbangkan 16 inti), dan inilah hasilnya:

Tunggu? Bukankah saya meningkatkan penggunaan CPU dalam 16 langkah genap? Grafik DTU ini hanya menunjukkan lima langkah. Aku pasti sudah kacau. Tidak–CSV saya memiliki 16 langkah genap, tetapi itu (tampaknya) tidak diterjemahkan secara merata ke dalam DTU. Setidaknya tidak menurut Kalkulator DTU. Berdasarkan pengujian CPU maksimal kami, pemetaan Tingkat CPU-ke-DTU-ke-Layanan kami akan terlihat seperti ini:

Melihat data ini memberi tahu kita beberapa hal:

1. Satu inti CPU, 100% digunakan sama dengan 100 DTU.
2. DTU meningkat agak secara linier saat CPU meningkat, tetapi tampaknya cocok dan menyembur.
3. Tingkat layanan Dasar dan Standar sama dengan kurang dari satu inti CPU.
4. Server Multi-core mana pun akan diterjemahkan ke beberapa ukuran dalam tingkat layanan Premium.

Baca

Kali ini, saya akan menggunakan metodologi yang sama. Saya akan menghasilkan CSV dengan peningkatan angka untuk pembacaan/penghitung detik, dengan penghitung perfmon lainnya pada nol. Saya akan perlahan-lahan meningkatkan jumlah dari waktu ke waktu. Kali ini, mari kita tingkatkan dalam potongan 2000, setiap 100 detik, sampai kita mencapai 30000. Ini memberi kita total waktu 25 menit yang sama–namun, kali ini saya memiliki 15 langkah, bukan 16. (Saya suka angka bulat.)

Saat kami mengunggah CSV ini ke kalkulator DTU, ini memberi kami grafik DTU ini:

Tunggu sebentar ... yang terlihat sangat mirip dengan grafik pertama. Sekali lagi, ini meningkat dalam 5 peningkatan yang tidak merata, meskipun saya memiliki 15 langkah genap dalam file saya. Mari kita lihat dalam format tabel:

Sekali lagi, kita melihat bahwa tingkat Dasar &Standar melonjak cukup cepat (kurang dari 2000 pembacaan/dtk), tetapi kemudian tingkat Premium cukup lebar, berkisar 2000 hingga 30000 pembacaan per detik. Pada tabel di atas, "Baca/dtk" mungkin dapat dianggap sebagai "IOPS" ... Atau, secara teknis, hanya "OPS" karena tidak ada penulisan yang membentuk bagian "input" dari IOPS.

Menulis

Jika kita membuat CSV menggunakan rumus yang sama dengan yang kita gunakan untuk Bacaan, dan mengunggah CSV itu ke Kalkulator DTU, kita akan mendapatkan grafik yang identik dengan grafik untuk Bacaan:

IOPS adalah IOPS, jadi apakah itu membaca atau menulis, sepertinya perhitungan DTU menganggapnya sama. Segala sesuatu yang kita ketahui (atau pikir kita ketahui) tentang membaca tampaknya berlaku sama untuk menulis.

Byte log dihapus

Kami sampai dengan penghitung perfmon terakhir:log byte memerah per detik. Ini adalah ukuran lain dari IO, tetapi khusus untuk log transaksi SQL Server. Jika Anda belum mengetahuinya sekarang, saya membuat CSV ini sehingga nilai tinggi akan dihitung sebagai P15 Azure DB, lalu cukup bagi nilai untuk memecahnya menjadi langkah genap. Kali ini, kita akan melangkah dari 5 juta menjadi 75 juta, dalam langkah 5 juta. Seperti yang kami lakukan pada semua pengujian sebelumnya, penghitung kinerja lainnya akan menjadi nol. Karena penghitung perfmon ini dalam byte per detik, dan kami mengukur dalam jutaan, kami dapat memikirkan ini dalam unit yang lebih nyaman bagi kami:Megabyte per detik.

Kami mengunggah CSV ini ke kalkulator DTU, dan kami mendapatkan grafik berikut:

Bentuk grafik ini semakin mudah ditebak. Kecuali kali ini, kami melangkah melalui tingkatan sedikit lebih cepat, mencapai P15 setelah hanya 8 langkah (dibandingkan dengan 11 untuk IO dan 12 untuk CPU). Ini mungkin membuat Anda berpikir, "Ini akan menjadi hambatan tersempit saya!" tapi aku tidak akan begitu yakin akan hal itu. Seberapa sering Anda menghasilkan 75MB log dalam sedetik ? Itu 4,5 GB per menit . Itu banyak aktivitas database. Beban kerja sintetis saya belum tentu merupakan beban kerja yang realistis.

Menggabungkan semuanya

Oke, sekarang kita telah melihat di mana beberapa batas atas berada dalam isolasi, saya akan menggabungkan data dan melihat bagaimana mereka membandingkan ketika CPU, I/O, dan log transaksi IO semua terjadi sekaligus–setelah semua , bukankah itu yang sebenarnya terjadi?

Untuk membangun CSV ini, saya cukup mengambil nilai yang ada yang kami gunakan untuk setiap pengujian individu di atas, dan menggabungkan nilai-nilai tersebut menjadi satu CSV, yang menghasilkan grafik yang indah ini:

Itu juga menghasilkan pesan:

Jika Anda melihat pada sumbu Y, Anda akan melihat bahwa kita mencapai "1.000k" (yaitu 1 juta) DTU pada 1200 detik. Itu sepertinya…uhh…salah? Jika kita melihat pengujian di atas, tanda 1200 detik adalah ketika keempat metrik individu mencapai sasaran untuk 4000 DTU, tingkat P15. Masuk akal bahwa kita akan berada di luar jangkauan, tetapi bentuk grafiknya tidak cukup masuk akal bagi saya – saya pikir kalkulator DTU hanya mengangkat tangannya dan berkata, "Terserah, Andy. Banyak sekali. banyak. Ini adalah bajillion DTU. Beban kerja ini tidak cocok untuk Azure SQL Database."

Oke, jadi apa yang terjadi sebelum tanda 1200 detik? Mari kita kurangi CSV dan kirimkan kembali ke kalkulator hanya dengan 1200 detik pertama. Nilai maksimum untuk setiap kolom adalah:81% CPU (atau apx 13 core pada 100%), 24000 baca/dtk, 24000 tulis/dtk, dan 60MB log flushed/dtk.

Halo, teman lama… Bentuk yang familiar itu kembali lagi. Berikut ringkasan data dari CSV, dan perkiraan Kalkulator DTU untuk total Penggunaan DTU dan tingkat layanan.

Sekarang, mari kita lihat bagaimana perhitungan DTU individu (saat kita mengevaluasinya secara terpisah) dibandingkan dengan perhitungan DTU dari pemeriksaan terbaru ini:

Anda akan melihat bahwa penghitungan DTU tidak sesederhana menjumlahkan DTU terpisah. Seperti definisi yang saya kutip di awal, ini adalah "ukuran campuran" dari metrik terpisah tersebut. Rumus yang digunakan untuk "memadukan" itu rumit, dan kami sebenarnya tidak memiliki rumus itu. Apa yang dapat kita lihat adalah perkiraan Kalkulator DTU lebih rendah daripada jumlah perhitungan DTU yang terpisah.

Memetakan DTU ke perangkat keras tradisional

Mari ambil data dari Kalkulator DTU, dan coba kumpulkan beberapa tebakan tentang bagaimana perangkat keras tradisional dapat dipetakan ke beberapa tingkatan Database Azure SQL.

Pertama, mari kita asumsikan bahwa "reads/sec" dan "writes/sec" diterjemahkan ke IOPS secara langsung, tanpa perlu terjemahan. Kedua, mari kita asumsikan bahwa menambahkan dua penghitung ini akan memberi kita total IOPS. Ketiga, mari kita akui bahwa kita tidak tahu apa itu penggunaan memori, dan kita tidak punya cara untuk membuat kesimpulan apa pun tentang hal itu.

Sementara saya memperkirakan spesifikasi perangkat keras, saya juga akan memilih kemungkinan ukuran Azure VM yang sesuai dengan setiap konfigurasi perangkat keras. Ada banyak ukuran Azure VM yang serupa, masing-masing dioptimalkan untuk metrik kinerja yang berbeda, tetapi saya telah melanjutkan dan membatasi pilihan saya pada Seri-A dan Seri-DSv2.

Tingkat Dasar sangat terbatas. Ini bagus untuk penggunaan sesekali/santai, dan ini adalah cara murah untuk "memarkir" database Anda saat Anda tidak menggunakannya. Tetapi jika Anda menjalankan aplikasi nyata apa pun, tingkat Dasar tidak akan berfungsi untuk Anda.

Tingkat Standar juga cukup terbatas, tetapi untuk aplikasi kecil, tingkat ini mampu memenuhi kebutuhan Anda. Jika Anda memiliki server 2-inti yang menjalankan beberapa database, maka database tersebut secara individual mungkin cocok dengan tingkat Standar. Demikian pula, jika Anda memiliki server dengan hanya satu database, menjalankan 1 inti CPU pada 100% (atau 2 inti berjalan pada 50%), mungkin tenaga kuda cukup untuk meningkatkan skala ke tingkat layanan Premium-P1.

Jika Anda akan menggunakan server multi-core di lokal (atau IaaS), maka Anda akan mencari di dalam tingkat layanan Premium di Azure SQL Database. Ini hanya masalah menentukan berapa banyak tenaga kuda CPU &I/O yang Anda butuhkan untuk beban kerja Anda. Server 2-inti, 4GB Anda mungkin membawa Anda ke suatu tempat di sekitar P6 Azure SQL DB. Dalam beban kerja CPU murni (dengan nol I/O), database P15 dapat menangani pemrosesan senilai 16 core, tetapi setelah Anda menambahkan IO ke dalam campuran, apa pun yang lebih besar dari ~12 core tidak akan masuk ke Azure SQL Database.

Lain kali, saya akan mengambil beberapa beban kerja yang sebenarnya, dan membandingkan kinerja di seluruh tingkatan layanan. Akankah perkiraan Kalkulator DTU akurat? Kami akan mencari tahu.

Tentang Penulis