Pertanyaan sederhana

Bagaimana SQL Server Quantum (4 ms) disinkronkan dengan Server OS Quantum (biasanya: 187,5 ms)?

Pertanyaan Sederhana Dijelaskan

Setelah 184 ms kuantum OS digunakan (yang sesuai dengan 46 kuantum SQL penuh), kuantum OS memiliki 3,5 ms waktu sebelum harus menyerahkan jadwal ke proses yang berbeda. SQL OS memulai kuantum (4 ms) dan setelah 3,5 ms, kuantum OS telah memutuskan untuk menghentikan utas SQL OS saat ini yang masih memiliki 0,5 ms sebelum akan menghasilkan jadwal. Apa yang terjadi sekarang?

---

Menyelam dalam pada OS Quantum

Dalam beberapa bagian berikutnya saya akan menulis apa yang telah saya temukan sejauh ini mengenai kuantum OS dan bagaimana durasi kuantum dapat dihitung. Durasi "kuantum" OS didasarkan pada "kutu" dan durasi "kutu" itu sendiri didasarkan pada "interval jam" yang biasanya 15,625000 ms. Tapi izinkan saya menguraikan sedikit ...

Kutu

Dalam artikel Blog Know Thy Tick Anda , Jim menjelaskan dasar-dasar interval jam (alias "ticks") dan untuk apa mereka.

Ketika saya membaca sesuatu seperti "interval jam ... untuk sebagian besar multiprosesor x86 adalah sekitar 15 milidetik", saya terdorong untuk menentukan nilai jam saya, atau "centang", interval. Untungnya, buku yang saya baca kutipan ini, Windows Internals Fourth Edition memberikan referensi untuk membantu saya dengan kesengsaraan saya. ... Penulis, Mark Russinovich, dari buku yang disebutkan di atas telah dengan ramah membuat utilitas ClockRes tersedia di situs web-nya. Menjalankan utilitas ini, saya dapat menentukan bahwa interval jam pada PC multiprosesor x86 saya adalah 15,625000 ms. Menarik, tetapi pikiran penasaran saya ingin tahu lebih banyak.

Kuantum

Penulis artikel selanjutnya menjelaskan dalam artikel keduanya bahwa...

Tentu saja alasan sebenarnya mengapa interval tick penting adalah karena ia mempengaruhi penjadwalan thread . Penjadwal Windows memberi setiap untaian "kuantum" waktu untuk dieksekusi sebelum mengizinkan tugas lain, pada tingkat prioritas yang sama, dijalankan. Kuantum yang ditetapkan penjadwal ke utas adalah kelipatan dari interval centang . Nilai kuantum spesifik yang dipilih untuk utas tertentu sedikit melampaui tempat saya ingin pergi dengan artikel ini.

Oke, jadi saya tahu apa itu kuantum, tapi tidak berapa lama kuantum akan berjalan.

Untuk saat ini, mari kita periksa nilai kuantum default untuk foreground thread di XPe. Dalam hal ini penjadwal Windows memberikan kuantum interval 18 atau 6 tick. (Ya, untuk mengonversi interval kuantum ke tick, seseorang harus membaginya dengan 3. ..., tetapi alasan multipel adalah untuk memungkinkan penjadwal kemampuan untuk "mengisi" utas untuk melakukan operasi yang menyebabkannya ditangguhkan.)

Kita sekarang tahu bahwa interval jam (centang) harus sekitar 15.625000 ms dan pada OS Desktop Windows di mana kuantum default adalah 18 bahwa ini akan menghasilkan 6 ticks atau 93.750000 ms (18/3 * 15.625000 ms).

Pada OS Windows Server, kuantum default berbeda. Pengaturan "Penjadwalan prosesor" diatur ke "Layanan Latar Belakang"

^{Pengaturan ini dapat ditemukan melalui "Pengaturan Sistem | Tingkat Lanjut (tab) | Kinerja (bagian) | Pengaturan ..." yang akan membuka "Opsi Pengaturan Tingkat Lanjut | Tingkat Lanjut (tab) | Penjadwalan Prosesor"}

Pengaturan kuantum default adalah 36 (Latar Belakang) hingga 36 (Latar Depan). Kuantum lebih besar dan karenanya lebih lama. Ini dua kali lipat jumlah 93.750000 ms dari pengaturan forumround kuantum 18 (6 tick) pada OS Windows Desktop, yang pada OS server yang diatur untuk Layanan Latar Belakang adalah sekitar 187.500000 ms.

Observasi / Penjelasan

Ketika Anda mengubah pengaturan dari "Layanan latar belakang" ke "Aplikasi" pada server atau desktop, maka HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation kunci dalam registri diubah dari 0x18 ke 0x02. Berapa nilai kuantum default untuk 0x02? Ini dapat ditemukan di komentar:

Nilai 0x02 menyiratkan bahwa bidang "Pendek vs. Panjang" dan "Variabel vs. Tetap" adalah default untuk OS.

Default untuk bidang-bidang ini untuk XPe & XP Pro adalah: Pendek & Variabel yang sama dengan memiliki bit-bit tambahan berikut yang ditetapkan: 0x24.

ATAU nilai ini dengan 0x02 memberi Anda 0x26, yang akan Anda temukan di tabel di artikel.

^{Referensi: Komentar untuk "Kuasai Kuantum Anda" (Blog MSDN)}

Tabel yang menjelaskan pengaturan kuantum dari artikel yang sama:

Win32PrioritySeparation   Foreground   Background
0x28, 0x29, 0x2A                  18           18
0x18, 0x19, 0x1A                  36           36
0x24                               6            6
0x25, 0x14                        12            6
0x26                              18            6
0x15                              24            6
0x16                              36            6

Ringkasan Singkat OS Quantum

Berdasarkan informasi dan kutipan artikel di atas, kita tahu bahwa kuantum bukan ukuran tetap, melainkan berasal dari pengaturan OS di System Properties. Kuantum bervariasi tergantung pada Win32PrioritySeparationpengaturan di registri yang biasanya sesuai dengan salah satu pengaturan di "Properti Sistem" (baik "Layanan latar belakang" atau "Aplikasi").

Sebuah kuantum di level OS adalah

• untuk pengaturan "Aplikasi"
  • 18 (yaitu 6 ticks) untuk aplikasi latar depan (93,75 ms)
  • 6 (yaitu 2 ticks) untuk aplikasi latar belakang (31,25 ms)
• untuk pengaturan "Layanan Latar Belakang"
  • 36 (18 kutu) untuk aplikasi latar depan (187,5 ms)
  • 36 (18 kutu) untuk aplikasi latar belakang (187,5 ms)

Jadi sekarang kita tahu bahwa kuantum OS pada pengaturan Windows Server yang akan dioptimalkan untuk Layanan Latar Belakang ...

36 / 3 * 15.625000 ms = 187.5 ms

---

SQL OS Quantum

Bagian ini mencantumkan apa yang saya temukan pada SQL OS ...

SOS_SCHEDULER_YIELD Jenis Tunggu

Dari uraian Paul Randall tentang jenis tunggu SOS_SCHEDULER_YIELD:

Jenis menunggu ini adalah ketika utas dapat mengeksekusi untuk utas utas penuh (4 milidetik di semua versi SQL Server, tidak dapat diubah ), dan dengan sukarela menghasilkan penjadwal, bergerak ke bagian bawah Antrian Runnable di penjadwalnya.

^{Referensi: SOS_SCHEDULER_YIELD (Jenis Tunggu SQLSkills.com)}

Penjadwal dalam DMV SQL Server

Dalam penjelasan tentang DMV SQL Server untuk sys.dm_os_schedulers DMV.

[...] Windows menggunakan mekanisme penjadwalan preemptive dan menetapkan jumlah waktu CPU untuk setiap utas, ketika utas mengkonsumsi kuantumnya, ia dikirim ke antrian dan utas lainnya diberikan eksekusi.

Sebaliknya, SQL Server menggunakan mekanisme penjadwalan kooperatif ketika utas dapat secara sukarela menghasilkan jumlah waktunya (Anda dapat melihat perilaku ini saat Anda memiliki jenis tunggu SOS_SCHEDULER_YIELD). Hal ini memungkinkan SQL Server untuk mengoptimalkan pemanfaatan CPU, karena ketika sebuah thread diisyaratkan untuk dieksekusi tetapi tidak siap untuk dijalankan, ia dapat menghasilkan kuantum waktu yang mendukung thread lain .

^{Referensi: Memahami Penjadwal, Pekerja, dan Tugas SQL Server (MSSQLTips.com)}

Mendeteksi Tekanan CPU SQL Server

Ini adalah bagian yang sangat kecil dari artikel tentang tekanan CPU di SQL Server.

Terjadi ketika tugas secara sukarela menghasilkan penjadwal untuk tugas-tugas lain untuk dieksekusi. Selama menunggu ini, tugas sedang menunggu kuantumnya diperbarui .

^{Referensi: Mendeteksi Tekanan CPU SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft Documents)

Saya kira kutipan berikut adalah potongan informasi terpenting tentang SQL OS quantum yang bisa saya temukan:

quantum_length_us bigint  Identified for informational purposes only. 
                          Not supported. Future compatibility is not guaranteed. 
                          Exposes the scheduler quantum used by SQLOS.

^{Referensi: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Documents)}

---

Teka-teki saya

Server OS Quantum mengatur berapa lama Layanan SQL Server diberikan untuk menjalankan "tugas". SQL Server OS Quantum didefinisikan sebagai 4 ms. Jika saya membagi 187,5 ms dengan 4 ms maka saya dibiarkan dengan 3,5 ms.

Dan kami bahkan belum memulai diskusi tentang kapan Interval Jam diatur ke sesuatu selain dari standar 15,625000 ms ....

Pertanyaan sederhana

Bagaimana SQL Server Quantum (4 ms) disinkronkan dengan Server OS Quantum (biasanya: 187,5 ms)?

Pertanyaan Sederhana Dijelaskan

Setelah 184 ms kuantum OS digunakan (yang sesuai dengan 46 kuantum SQL penuh), kuantum OS memiliki 3,5 ms waktu sebelum harus menyerahkan jadwal ke proses yang berbeda. SQL OS memulai kuantum (4 ms) dan setelah 3,5 ms, kuantum OS telah memutuskan untuk menghentikan utas SQL OS saat ini yang masih memiliki 0,5 ms sebelum akan menghasilkan jadwal. Apa yang terjadi sekarang?

Meskipun penjadwal tidak preemptive, penjadwal SQL Server masih menganut konsep kuantum. Lebih buruk daripada tugas-tugas SQL Server dipaksa untuk menyerahkan CPU oleh sistem operasi, mereka dapat meminta untuk ditempatkan pada antrian tunggu secara berkala, dan jika mereka telah melampaui kuantum 4 milidetik yang ditentukan secara internal dan tidak berada di tengah operasi yang tidak bisa dihentikan, mereka secara sukarela melepaskan CPU.

- " Microsoft SQL Server 2012 Internal ", Kalen Delaney et. Al. pp38

-Bab 2 "The SQLOS" Jonathan Kehayias

Jadi gagasan "kuantum" di dalam SQL Server lebih dari "pedoman" untuk tugas pemrograman. Yaitu ketika Anda menulis tugas, seperti katakanlah, tugas yang melakukan pemindaian tabel, jika Anda tidak menekan kait halaman, kait IO, atau kunci menunggu sebentar, Anda harus menghentikan apa yang Anda lakukan dan meminta untuk menjadi masukkan kembali ke antrian runnable, kalau-kalau ada tugas lain menunggu.

Tapi terserah tugas programmer untuk mengimplementasikan ini, dan mungkin tidak tepat 4 ms untuk setiap jenis tugas. Misalnya tugas pemindaian tabel mungkin menggunakan heuristik sederhana berdasarkan jumlah halaman yang dipindai untuk mengimplementasikan titik hasil.

Begitu

SQL OS memulai kuantum (4 ms) dan setelah 3,5 ms, kuantum OS telah memutuskan untuk menghentikan utas SQL OS saat ini yang masih memiliki 0,5 ms sebelum akan menghasilkan jadwal. Apa yang terjadi sekarang?

Jika utas SQL Server sudah ditentukan sebelumnya oleh Windows saat tugas sedang berjalan, itu akan dijeda, dan ketika utas berikutnya dijadwalkan pada CPU, ia akan melanjutkan di mana ia tinggalkan. Agaknya ia akan terus mengonsumsi keseimbangan 4ms kuantumnya, karena ia tidak akan tahu perbedaannya. Tetapi sekali lagi, perilaku hasil adalah detail implementasi tugas, bukan perilaku SQLOS, sehingga tugas yang berbeda mungkin berperilaku berbeda di sini.

_{Kontribusi jawaban yang semula ditinggalkan sebagai komentar}

Bagaimana SQL Server Quantum (4 ms) disinkronkan dengan Server OS Quantum (biasanya: 187,5 ms)?

Tidak dan SQL Server tidak menggunakan penjadwalan preemptive. Item pekerjaan diharapkan mencapai titik hasil dan jika tidak, Anda mendapatkan hal-hal seperti NONYIELDINGpenjadwal. Tidak ada paritas. SQL Server tidak mendistribusikan waktu. Itu membuat utas tertentu menarik bagi Windows untuk menjadwalkan dan Windows menjadwalkannya. Quantum hanyalah nomenklatur untuk sepotong waktu. Itu dia. SQL Server bukan preemptive, itu adalah tanggung jawab apa pun yang berjalan untuk menghasilkan sendiri seluruh kode. - Sean Gallardy

Ketika kuantum OS kedaluwarsa, utas dijadwalkan secara paksa. Ini transparan untuk SQL Server. SQLOS tidak memiliki cara untuk mendeteksi kapan ini terjadi. Tidak ada Win32 API untuk itu. Penjadwalan transparan untuk utas mode pengguna. Penjadwal Windows tidak tahu atau tidak peduli apa yang dilakukan mode pengguna. Windows hanya melihat utas yang dapat dijalankan dan memungkinkan mereka berjalan sampai akhir kuantum OS mereka atau sampai mereka memblokir. - usr

Dalam Cara menangani nilai tipe tunggu SOS_SCHEDULER_YIELD berlebihan di SQL Server oleh Nikola Dimitrijevic, istilah "kuantum" pada dasarnya berarti "waktu tugas yang sebenarnya dihabiskan untuk pekerja", tapi itu tidak sama dengan kuantum Windows, yang merupakan periode waktu di mana OS akan menghapus utas dari CPU. Mereka hanya konsep yang berbeda. Jika OS memaksa utas untuk mengakhiri eksekusi karena kuantum OS telah tercapai, terjadi perubahan konteks. Utas SQL Server ditangguhkan, sama seperti program lainnya. - David Browne - Microsoft dan George.Palacios .

---

Ekstrak dari dokumentasi: Di dalam Penjadwal Mode Pengguna SQL Server 2000 (ditulis untuk SQL Server 2000, tetapi masih relevan):

Tugas Preemptive vs. Cooperative

UMS, sebaliknya, bergantung pada utas untuk menghasilkan secara sukarela. UMS mengambil pendekatan yang dilakukannya agar tidak melibatkan kernel Windows lebih dari yang diperlukan. Dalam sistem di mana utas pekerja dapat diandalkan untuk menghasilkan sebagaimana mestinya, penjadwal kooperatif sebenarnya bisa lebih efisien daripada yang preemptive karena proses penjadwalan dapat disesuaikan dengan kebutuhan spesifik aplikasi. Seperti yang saya katakan sebelumnya, UMS tahu kebutuhan penjadwalan SQL Server lebih baik daripada sistem operasi dapat diharapkan.

Bagaimana UMS Mengambil Penjadwalan

Jika UMS menangani kebutuhan penjadwalan SQL Server alih-alih membiarkan Windows melakukannya, UMS entah bagaimana harus mencegah OS melakukan apa yang dilakukannya dengan setiap proses lainnya: menjadwalkan utas dan mematikan prosesor sistem sesuai dengan keinginan. Bagaimana Anda melakukannya di OS preemptive? UMS melakukan ini melalui beberapa trik pintar dengan objek acara Windows. Setiap utas di bawah UMS memiliki objek acara terkait. Untuk tujuan penjadwalan, Windows mengabaikan utas yang tidak dianggap layak - utas yang tidak dapat berjalan karena mereka dalam kondisi tunggu yang tak terbatas. Mengetahui hal ini, UMS menempatkan utas untuk tidur bahwa ia tidak ingin dijadwalkan dengan meminta mereka memanggil WaitForSingleObject pada objek acara yang sesuai dan melewati INFINITE untuk nilai batas waktu.

Untuk mencegah Windows dari menjadwalkan banyak utas pada prosesor yang sama dan dengan demikian mengeluarkan biaya overhead dan biaya dari sakelar konteks, UMS berusaha untuk menjaga agar hanya satu utas yang layak — yaitu, bukan dalam kondisi tunggu yang tak terbatas — per prosesor.