Quantum ของ Windows OS เทียบกับ Quantum ของ SQL OS

คำถามง่าย ๆ

SQL Server Quantum (4 ms) มีการซิงโครไนซ์กับ Quantum Server OS อย่างไร (ปกติ: 187.5 ms)

อธิบายคำถามง่าย ๆ

หลังจากที่ใช้ควอนตัม OS 184 ms (ซึ่งสอดคล้องกับควอนตัม SQL แบบเต็ม 46) ควอนตัม OS นั้นมีเวลา 3.5 มิลลิวินาทีก่อนที่มันจะต้องส่งมอบตารางเวลาให้กับกระบวนการอื่น SQL OS เริ่มต้นควอนตัม (4 ms) และหลังจาก 3.5 ms, ควอนตัม OS ได้ตัดสินใจที่จะหยุดเธรด SQL OS ปัจจุบันซึ่งยังคงมี 0.5 มิลลิวินาทีก่อนที่มันจะให้ผลตามกำหนดเวลา เกิดอะไรขึ้น?

Dive Deep บน OS Quantum

ในสองส่วนถัดไปฉันจะเขียนสิ่งที่ฉันได้พบเกี่ยวกับควอนตัม OS และวิธีคำนวณระยะเวลาของควอนตัม ระยะเวลาของ "ควอนตัม" ของระบบปฏิบัติการขึ้นอยู่กับ "เห็บ" และระยะเวลาของ "เห็บ" นั้นขึ้นอยู่กับ "ช่วงเวลาของนาฬิกา" ซึ่งโดยปกติคือ 15.625000 มิลลิวินาที แต่ขอผมอธิบายหน่อย ...

เห็บ

ในบทความบล็อกรู้จักเจ้าติ๊กผู้เขียนจิมอธิบายพื้นฐานของช่วงเวลาของนาฬิกา (aka "เห็บ") และสิ่งที่พวกเขามีไว้เพื่อ

เมื่อฉันอ่านบางสิ่งเช่น“ ช่วงเวลาของนาฬิกา…สำหรับตัวประมวลผลหลายตัว x86 ส่วนใหญ่คือประมาณ 15 มิลลิวินาที” ฉันถูกบังคับให้กำหนดค่าของนาฬิกาของฉันหรือ“ ขีด” ช่วงเวลา โชคดีที่หนังสือที่ฉันอ่านอ้างถึงนี้ Windows Internals Fourth Edition มีข้อมูลอ้างอิงสำหรับช่วยเหลือฉันด้วยความทุกข์ ... ผู้เขียน Mark Russinovich จากหนังสือดังกล่าวได้ทำClockResยูทิลิตี้ที่มีอยู่บนเว็บไซต์ของเขา ใช้ยูทิลิตี้นี้ฉันสามารถตรวจสอบว่าช่วงเวลาสัญญาณนาฬิกาบนพีซีแบบมัลติโปรเซสเซอร์ x86 ของฉันคือ 15.625000 ms น่าสนใจ แต่ใจที่อยากรู้อยากเห็นอยากรู้มากขึ้น

ควอนตัม

ผู้เขียนบทความอธิบายต่อไปในบทความที่สองของเขา ที่...

แน่นอนเหตุผลที่แท้จริงว่าทำไมช่วงเห็บเป็นสิ่งที่สำคัญก็คือว่ามันมีผลกระทบต่อการจัดตารางเวลาด้าย ตัวกำหนดตารางเวลาของ Windows จะให้ "เวลา" ของเธรดเพื่อดำเนินการก่อนที่จะอนุญาตให้งานอื่นที่มีระดับความสำคัญเท่ากันทำงานได้ ควอนตัมที่ตัวกำหนดตารางเวลากำหนดให้กับเธรดคือช่วงเวลาหลายช่วงเวลาของเห็บ ค่าควอนตัมเฉพาะที่เลือกสำหรับเธรดที่ระบุนั้นค่อนข้างเกินกว่าที่ฉันต้องการจะไปกับบทความนี้

ตกลงดังนั้นฉันรู้ว่าควอนตัมคืออะไร แต่ไม่นานว่าควอนตัมจะทำงาน

ตอนนี้เรามาดูค่าควอนตัมเริ่มต้นสำหรับเธรดเบื้องหน้าใน XPe ในกรณีนี้ตัวกำหนดตารางเวลาของ Windows จะกำหนดช่วงเวลา 18 หรือ 6 ขีด (ใช่ในการแปลงควอนตัมเพื่อทำเครื่องหมายช่วงเวลาหนึ่งจะต้องหารด้วย 3 ... แต่เหตุผลสำหรับการคูณคือการอนุญาตให้ตัวกำหนดตารางเวลาความสามารถในการ "คิดค่าใช้จ่าย" เธรดสำหรับการดำเนินการที่ทำให้หยุดชั่วคราว)

ตอนนี้เรารู้ว่าช่วงเวลาของนาฬิกา (ติ๊ก) ควรอยู่ที่ประมาณ 15.625000 ms และในระบบปฏิบัติการ Windows Desktop ที่ควอนตัมเริ่มต้นคือ 18 ซึ่งจะส่งผลให้มี 6 เห็บหรือ 93.750000 ms (18/3 * 15.625000 ms)

บน Windows Server OS ควอนตัมเริ่มต้นนั้นแตกต่างกัน การตั้งค่า "การตั้งเวลาตัวประมวลผล" ถูกตั้งค่าเป็น "บริการพื้นหลัง"

^{การตั้งค่านี้สามารถพบได้ผ่าน "การตั้งค่าระบบ | ขั้นสูง (แท็บ) | ประสิทธิภาพ (ส่วน) | การตั้งค่า ... " ซึ่งจะเปิด "ตัวเลือก Perofrmance | ขั้นสูง (แท็บ) | การตั้งเวลาตัวประมวลผล"}

การตั้งค่าควอนตัมเริ่มต้นคือ 36 (พื้นหลัง) ถึง 36 (เบื้องหน้า) ควอนตัมมีขนาดใหญ่กว่าและนานกว่านี้ นี่เป็นสองเท่าของ 93.750000 ms ของการตั้งค่าเบื้องหน้าควอนตัม 18 (6 ขีด) บน Windows Desktop OS ซึ่งบนระบบปฏิบัติการเซิร์ฟเวอร์ที่ติดตั้งสำหรับบริการพื้นหลังอยู่ที่ประมาณ 187.500000 มิลลิวินาที

การสังเกต / คำอธิบาย

เมื่อคุณเปลี่ยนการตั้งค่าจาก "บริการพื้นหลัง" เป็น "Applicaitons" บนเซิร์ฟเวอร์หรือเดสก์ท็อปดังนั้นคีย์ HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparationในรีจิสทรีจะเปลี่ยนจาก 0x18 เป็น 0x02 ค่าควอนตัมเริ่มต้นสำหรับ 0x02 คืออะไร สามารถพบได้ในความคิดเห็น:

ค่า 0x02 แสดงว่าเขตข้อมูล "สั้นกับยาว" และ "ตัวแปรเทียบกับคงที่" เป็นค่าเริ่มต้นสำหรับระบบปฏิบัติการ

ค่าเริ่มต้นสำหรับฟิลด์เหล่านี้สำหรับ XPe & XP Pro คือ: Short & Variable ซึ่งเหมือนกับการตั้งค่าบิตเพิ่มเติมบิตต่อไปนี้: 0x24

หรือการใช้ค่านี้ด้วย 0x02 จะให้ 0x26 ซึ่งคุณจะพบในตารางในบทความ

^{การอ้างอิง: ความคิดเห็นที่ "Master Quantum ของคุณ" (บล็อก MSDN)}

ตารางอธิบายการตั้งค่าควอนตัมจากบทความเดียวกัน:

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

สรุปสั้น ๆ ของ Quantum OS

จากข้อมูลข้างต้นและคำพูดของบทความเรารู้ว่าควอนตัมไม่ใช่ขนาดคงที่ แต่ได้มาจากการตั้งค่าระบบปฏิบัติการในคุณสมบัติของระบบ ควอนตัมจะแตกต่างกันไปขึ้นอยู่กับการWin32PrioritySeparationตั้งค่าในรีจิสทรีซึ่งโดยทั่วไปจะสอดคล้องกับการตั้งค่าหนึ่งใน "คุณสมบัติของระบบ" ("บริการพื้นหลัง" หรือ "แอปพลิเคชัน")

ควอนตัมที่ระดับ OS คือ

สำหรับการตั้งค่า "แอปพลิเคชัน"
- 18 (ซึ่งคือ 6 เห็บ) สำหรับแอปพลิเคชันเบื้องหน้า (93.75 ms)
- 6 (ซึ่งคือ 2 เห็บ) สำหรับแอปพลิเคชันพื้นหลัง (31.25 มิลลิวินาที)
สำหรับการตั้งค่า "บริการพื้นหลัง"
- 36 (ซึ่งเท่ากับ 18 เห็บ) สำหรับแอปพลิเคชันเบื้องหน้า (187.5 มิลลิวินาที)
- 36 (ซึ่งคือ 18 เห็บ) สำหรับแอปพลิเคชันพื้นหลัง (187.5 มิลลิวินาที)

ดังนั้นตอนนี้เราจึงรู้ว่าระบบควอนตัม OS บนการตั้งค่า Windows Server ที่จะปรับให้เหมาะกับBackground Servicesคือ ...

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS Quantum

ส่วนนี้แสดงรายการสิ่งที่ฉันพบบนควอนตัม SQL OS ...

SOS_SCHEDULER_YIELD รอประเภท

จากคำอธิบายของ Paul Randall เกี่ยวกับประเภทรอ SOS_SCHEDULER_YIELD:

ประเภทการรอนี้คือเมื่อเธรดสามารถดำเนินการสำหรับควอนตัมเธรดแบบเต็ม(4 มิลลิวินาทีในทุกเวอร์ชันของ SQL Server ไม่สามารถเปลี่ยนได้ ) และให้ผลตอบแทนที่กำหนดโดยสมัครใจย้ายไปที่ด้านล่างของ Runnable Queue ในกำหนดการ

^{การอ้างอิง: SOS_SCHEDULER_YIELD (SQLSkills.com Wait Type)}

Schedulers ใน SQL Server DMVs

ในคำอธิบายเกี่ยวกับ SQL Server DMVs สำหรับ sys.dm_os_schedulers DMV

[... ] Windows ใช้กลไกการกำหนดตารางเวลาไว้ล่วงหน้าและกำหนดควอนตัมของเวลา CPU ให้กับทุกเธรดเมื่อเธรดใช้ปริมาณของมันจะถูกส่งไปยังคิวและเธรดอื่น ๆ จะได้รับการดำเนินการ

ในทางตรงกันข้าม SQL Server ใช้กลไกการจัดตารางเวลาแบบมีส่วนร่วมเมื่อเธรดสามารถสร้างปริมาณเวลาได้โดยสมัครใจ (คุณสามารถเห็นพฤติกรรมนี้เมื่อคุณมีประเภทรอ SOS_SCHEDULER_YIELD) สิ่งนี้ช่วยให้ SQL Server ปรับการใช้ CPU ให้เกิดประโยชน์สูงสุดเนื่องจากเมื่อเธรดส่งสัญญาณสำหรับการดำเนินการ แต่ไม่พร้อมที่จะเรียกใช้สามารถส่งผลให้เวลาของควอนตัมแก่เธรดอื่น ๆได้

^{การอ้างอิง: การทำความเข้าใจเกี่ยวกับตัวกำหนดเวลาของเซิร์ฟเวอร์ SQL คนงานและงาน (MSSQLTips.com)}

ตรวจจับแรงกดดันซีพียูเซิร์ฟเวอร์ SQL

นี่เป็นส่วนเล็ก ๆ ของบทความเกี่ยวกับแรงดัน CPU ใน SQL Server

เกิดขึ้นเมื่องานโดยสมัครใจทำให้ตัวจัดตารางเวลาสำหรับงานอื่น ๆ เพื่อดำเนินการ ในช่วงการรอคอยนี้งานที่กำลังรอให้ควอนตัมที่จะได้รับการต่ออายุ

^{การอ้างอิง: ตรวจจับแรงดัน CPU ของเซิร์ฟเวอร์ SQL (MSSQLTips.com)}

sys.dm_os_schedulers (Microsoft เอกสาร)

ฉันเดาว่าข้อความต่อไปนี้เป็นตัวอย่างข้อมูลที่สำคัญที่สุดเกี่ยวกับควอนตัม SQL OS ที่ฉันสามารถหาได้:

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

^{การอ้างอิง: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

ปริศนาของฉัน

Quantum Server OS ควบคุมปริมาณเวลาของ SQL Server Service ที่อนุญาตให้เรียกใช้งาน "task" Quantum OS ของ SQL Server ถูกกำหนดเป็น 4 ms ถ้าฉันหาร 187.5 ms ด้วย 4 ms ฉันจะเหลือ 3.5 ms

และเรายังไม่ได้เริ่มการสนทนาเมื่อตั้งค่าช่วงเวลาของนาฬิกาเป็นอย่างอื่นที่ไม่ใช่ค่าเริ่มต้นคือ 15.625000 ms ....

คำถามง่าย ๆ

SQL Server Quantum (4 ms) มีการซิงโครไนซ์กับ Quantum Server OS อย่างไร (ปกติ: 187.5 ms)

อธิบายคำถามง่าย ๆ

sql-server

— John aka hot2use
แหล่งที่มา

คำตอบ:

แม้ว่าตัวกำหนดตารางเวลาจะไม่ได้มาก่อน แต่ตัวจัดตารางเวลาของ SQL Server ยังคงยึดตามแนวคิดของควอนตัม Rahter กว่างานของ SQL Server ถูกบังคับให้เลิกใช้ CPU โดยระบบปฏิบัติการพวกเขาสามารถร้องขอให้รอคิวเป็นระยะและหากพวกเขามีปริมาณเกินกว่า 4 มิลลิวินาทีที่กำหนดไว้ภายในและไม่ได้อยู่ในระหว่างการดำเนินการ ที่ไม่สามารถหยุดพวกเขาสมัครใจปล่อยซีพียู

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney และ อัล pp38

- บทที่ 2 "The SQLOS" Jonathan Kehayias

ดังนั้นแนวคิดของ "ควอนตัม" ใน SQL Server จึงเป็น "แนวทาง" มากกว่าสำหรับการเขียนโปรแกรมงาน IE เมื่อคุณเขียนงานเช่นงานที่สแกนตารางหากคุณไม่ได้กด latch หน้าใด ๆ , IO latch หรือ lock รอสักครู่คุณควรหยุดสิ่งที่คุณกำลังทำและขอให้เป็น นำกลับมาใช้ในคิวที่รันได้ในกรณีที่มีงานอื่นรออยู่

แต่มันก็ขึ้นอยู่กับโปรแกรมเมอร์ที่จะใช้สิ่งนี้และมันอาจจะไม่ตรงกับ 4ms สำหรับงานแต่ละประเภท ตัวอย่างเช่นงานสแกนตารางอาจใช้ฮิวริสติกแบบง่ายตามจำนวนหน้าที่สแกนเพื่อนำคะแนนไปใช้

ดังนั้น

SQL OS เริ่มต้นควอนตัม (4 ms) และหลังจาก 3.5 ms, ควอนตัม OS ได้ตัดสินใจที่จะหยุดเธรด SQL OS ปัจจุบันซึ่งยังคงมี 0.5 มิลลิวินาทีก่อนที่มันจะให้ผลตามกำหนดเวลา เกิดอะไรขึ้น?

ถ้าเธรด SQL Server ถูก pre-empted โดย Windows ในขณะที่งานกำลังทำงานอยู่เธรดนั้นจะถูกหยุดชั่วคราวและเมื่อเธรดนั้นถูกกำหนดเวลาไว้ในซีพียูครั้งต่อไปจะดำเนินการต่อจากที่ค้างไว้ สันนิษฐานว่ามันจะยังคงใช้สมดุลของควอนตัม 4ms ของมันต่อไปเนื่องจากมันจะไม่ทราบความแตกต่างใด ๆ แต่อีกครั้งพฤติกรรมผลตอบแทนเป็นรายละเอียดการใช้งานไม่ใช่พฤติกรรมของ SQLOS ดังนั้นงานที่แตกต่างกันอาจทำงานแตกต่างกันที่นี่

— David Browne - Microsoft
แหล่งที่มา

_{คำตอบการมีส่วนร่วมเดิมทิ้งไว้เป็นความคิดเห็น}

SQL Server Quantum (4 ms) มีการซิงโครไนซ์กับ Quantum Server OS อย่างไร (ปกติ: 187.5 ms)

ไม่ใช่และ SQL Server ไม่ได้ใช้การกำหนดตารางเวลาไว้ล่วงหน้า ไอเท็มงานคาดว่าจะได้รับคะแนนผลตอบแทนและหากไม่ได้รับคุณจะได้รับสิ่งต่าง ๆ เช่นตัวNONYIELDINGกำหนดเวลา ไม่มีความเท่าเทียมกัน SQL Server ไม่กระจายเวลา มันทำให้เธรดบางอย่างดึงดูดใจ Windows เพื่อกำหนดตารางเวลาและ Windows กำหนดเวลาให้เธรด Quantum เป็นศัพท์เพียงระยะเวลาหนึ่ง แค่นั้นแหละ. SQL Server ไม่ได้ถูกจองไว้ล่วงหน้ามันเป็นความรับผิดชอบของทุกสิ่งที่กำลังทำงานเพื่อให้ตัวมันเองตลอดทั้งรหัส - ฌอน Gallardy

เมื่อควอนตัม OS หมดอายุเธรดจะถูกยกเลิกการจัดกำหนดการอย่างเข้มงวด นี่คือโปร่งใสไปยัง SQL Server SQLOS ไม่มีวิธีการตรวจจับเมื่อเกิดเหตุการณ์นี้ ไม่มี Win32 API สำหรับสิ่งนั้น การกำหนดเวลาจะโปร่งใสสำหรับเธรดโหมดผู้ใช้ ตัวกำหนดตารางเวลาของ Windows ไม่ทราบหรือสนใจสิ่งที่เธรดโหมดผู้ใช้กำลังทำ Windows จะเห็นเฉพาะเธรดที่สามารถเรียกใช้งานได้และอนุญาตให้เธรดทำงานจนสิ้นสุดควอนตัม OS หรือจนกว่าจะปิดกั้น - usr

ในการจัดการ SOS_SCHEDULER_YIELD มากเกินไปให้รอค่าประเภทใน SQL Serverโดย Nikola Dimitrijevic คำว่า "quantum" ถูกใช้เพื่อหมายถึงเป็นหลัก "เวลาที่งานมอบหมายให้ผู้ปฏิบัติงานจริง" แต่นั่นไม่ใช่ความรู้สึกเดียวกับควอนตัมของ Windows ซึ่งเป็นช่วงเวลาหลังจากนั้นระบบปฏิบัติการจะลบเธรดออกจาก CPU มันเป็นแค่แนวคิดที่แตกต่าง หากระบบปฏิบัติการบังคับให้เธรดหยุดการประมวลผลเนื่องจากถึงควอนตัมของระบบปฏิบัติการแล้วจะเกิดการสลับบริบท เธรดของ SQL Server ถูกระงับเช่นเดียวกับโปรแกรมอื่น ๆ - เดวิดบราวน์ - ไมโครซอฟท์และGeorge.Palacios

แยกจากเอกสารประกอบ: ภายใน SQL Server 2000 User Mode Scheduler (เขียนขึ้นสำหรับ SQL Server 2000 แต่ยังคงเกี่ยวข้อง):

Preemptive vs. Cooperative Tasking

ในทางตรงกันข้าม UMS จะอาศัยเธรดเพื่อให้ผลลัพธ์โดยสมัครใจ UMS ใช้แนวทางที่ทำเพื่อป้องกันมิให้เคอร์เนล Windows เกี่ยวข้องเกินกว่าที่จำเป็นอย่างยิ่ง ในระบบที่สามารถนับเธรดของผู้ปฏิบัติงานเพื่อให้ได้ตามที่ควรจริง ๆ ตัวจัดกำหนดการแบบมีส่วนร่วมจะมีประสิทธิภาพมากกว่าการยึดเอาเสียก่อนเนื่องจากกระบวนการกำหนดเวลาสามารถปรับให้เหมาะกับความต้องการเฉพาะของแอปพลิเคชันได้ ดังที่ฉันได้กล่าวไปแล้ว UMS รู้ถึงความต้องการการจัดตารางเวลาของ SQL Server ดีกว่าระบบปฏิบัติการที่คาดไว้

UMS ใช้เวลามากกว่าการจัดตารางเวลาอย่างไร

หาก UMS คือการจัดการกับความต้องการการตั้งเวลาของ SQL Server แทนที่จะปล่อยให้ Windows ทำเช่นนั้น UMS จะต้องป้องกันไม่ให้ระบบปฏิบัติการทำสิ่งที่มันทำกับกระบวนการอื่น ๆ ทั้งหมด: กำหนดเวลาเธรดเปิดและปิดตัวประมวลผลของระบบตามที่เห็นสมควร คุณจะทำเช่นนั้นในระบบปฏิบัติการที่ถูกยึดครองได้อย่างไร? UMS ดึงสิ่งนี้ออกด้วยกลอุบายฉลาด ๆ กับวัตถุเหตุการณ์ Windows แต่ละเธรดภายใต้ UMS มีวัตถุเหตุการณ์ที่เกี่ยวข้อง สำหรับวัตถุประสงค์ในการจัดตารางเวลา Windows จะละเว้นเธรดที่ไม่พิจารณาว่าทำงานได้จริงเธรดที่ไม่สามารถทำงานได้เนื่องจากเธรดอยู่ในสถานะรอไม่สิ้นสุด เมื่อทราบสิ่งนี้ UMS จะทำให้เธรดเข้าสู่โหมดสลีปซึ่งไม่ต้องการกำหนดเวลาโดยให้มีการเรียกใช้WaitForSingleObjectบนวัตถุเหตุการณ์ที่เกี่ยวข้องและส่งINFINITEสำหรับค่าการหมดเวลา

เพื่อป้องกันไม่ให้ Windows จัดตารางเวลาหลายเธรดในตัวประมวลผลเดียวกันและทำให้เกิดค่าใช้จ่ายและค่าใช้จ่ายของสวิทช์บริบท UMS พยายามที่จะรักษาเธรดที่ทำงานได้เพียงหนึ่งเธรดนั่นคือไม่ได้อยู่ในสถานะรอไม่สิ้นสุดต่อโปรเซสเซอร์

— user126897
แหล่งที่มา