Câu hỏi đơn giản

Lượng tử máy chủ SQL (4 ms) được đồng bộ hóa với Lượng tử hệ điều hành máy chủ (thông thường: 187,5 ms) như thế nào?

Giải thích câu hỏi đơn giản

Sau 184 ms lượng tử hệ điều hành được sử dụng (tương ứng với 46 lượng tử SQL đầy đủ), lượng tử hệ điều hành có 3,5 ms thời gian trước khi nó sẽ phải bàn giao lịch trình cho một quy trình khác. Hệ điều hành SQL bắt đầu một lượng tử (4 ms) và sau 3,5 ms, lượng tử hệ điều hành đã quyết định dừng luồng SQL OS hiện tại vẫn còn 0,5 ms trước khi nó mang lại lịch trình. Chuyện gì xảy ra bây giờ?

---

Lặn sâu trên hệ điều hành Lượng tử

Trong vài phần tiếp theo tôi sẽ viết lên những gì tôi đã tìm thấy cho đến lượng tử hệ điều hành và cách tính thời lượng của một lượng tử. Thời lượng của "lượng tử" hệ điều hành dựa trên "tick" và thời lượng của "tick" dựa trên "khoảng thời gian" thường là 15.625000 ms. Nhưng hãy để tôi giải thích một chút ...

Đánh dấu

Trong bài viết trên Blog Biết Thy Tick , tác giả Jim giải thích những điều cơ bản về khoảng thời gian của đồng hồ (còn gọi là "tick") và chúng dùng để làm gì.

Khi tôi đọc một cái gì đó giống như thời gian xung nhịp, xung nhịp cho hầu hết các bộ xử lý đa nhân x86 là khoảng 15 mili giây. May mắn thay, cuốn sách tôi đọc trích dẫn này, Windows Internals Fourth Edition cung cấp một tài liệu tham khảo để giúp tôi với phiền não của tôi. ... Tác giả, Mark Russinovich, của cuốn sách nói trên đã ân cần cung cấp tiện ích ClockRes có sẵn trên trang web của mình. Chạy tiện ích này, tôi có thể xác định rằng khoảng thời gian đồng hồ trên PC đa bộ xử lý x86 của tôi là 15.625000 ms. Thú vị, nhưng tâm trí tò mò của tôi muốn biết nhiều hơn.

Lượng tử

Tác giả của bài báo tiếp tục giải thích trong bài viết thứ hai của mình cái đó...

Tất nhiên lý do thực sự tại sao khoảng thời gian đánh dấu là quan trọng là nó ảnh hưởng đến lập lịch luồng . Bộ lập lịch Windows cung cấp cho mỗi luồng một lượng tử thời gian thực hiện trước khi cho phép một tác vụ khác, ở cùng mức độ ưu tiên, chạy. Lượng tử mà bộ lập lịch gán cho một luồng là bội số của khoảng thời gian đánh dấu . Giá trị lượng tử cụ thể được chọn cho một chủ đề cụ thể vượt xa nơi tôi muốn đến với bài viết này.

Ok, vì vậy tôi biết lượng tử là gì, nhưng không biết lượng tử sẽ chạy trong bao lâu.

Hiện tại, chúng ta hãy kiểm tra giá trị lượng tử mặc định cho một luồng tiền cảnh trong XPe. Trong trường hợp này, bộ lập lịch Windows gán một lượng tử là 18 hoặc 6 lần đánh dấu. (Có, để chuyển đổi lượng tử thành các khoảng thời gian đánh dấu, người ta phải chia cho 3. ..., nhưng lý do cho bội số là cho phép người lập lịch khả năng để tính phí một luồng để thực hiện một thao tác khiến nó bị đình chỉ.)

Bây giờ chúng ta biết rằng khoảng thời gian đồng hồ (tick) nên vào khoảng 15.625000 ms và trên HĐH Windows Desktop với lượng tử mặc định là 18, điều này sẽ dẫn đến 6 tick hoặc 93.750000 ms (18/3 * 15.625000 ms).

Trên HĐH Windows Server, lượng tử mặc định là khác nhau. Cài đặt "Lập lịch xử lý" được đặt thành "Dịch vụ nền"

^{Có thể tìm thấy cài đặt này qua "Cài đặt hệ thống | Nâng cao (tab) | Hiệu suất (phần) | Cài đặt ..." sẽ mở "Tùy chọn Perofrmance | Nâng cao (tab) | Lập lịch xử lý"}

Các cài đặt lượng tử mặc định sau đó là 36 (Nền) đến 36 (Tiền cảnh). Lượng tử lớn hơn và do đó lâu hơn. Con số này gấp đôi số lượng 93.750000 ms của cài đặt tiền cảnh lượng tử 18 (6 tick) trên HĐH Windows Desktop, trên hệ điều hành máy chủ được thiết lập cho Dịch vụ nền là khoảng 187.500000 ms.

Quan sát / Giải thích

Khi bạn thay đổi cài đặt từ "Dịch vụ nền" thành "Applicaitons" trên máy chủ hoặc máy tính để bàn, thì HKLM \ HỆ THỐNG \ CurrentControlset \ Control \ PriorityControl \ Win32P WarrioritySpayation trong sổ đăng ký được thay đổi từ 0x18 thành 0x02. Giá trị lượng tử mặc định cho 0x02 là gì? Điều này có thể được tìm thấy trong một bình luận:

Giá trị 0x02 ngụ ý rằng các trường "Ngắn so với dài" và "Biến so với cố định" là mặc định cho HĐH.

Mặc định cho các trường này cho XPe & XP Pro là: Short & Var biến, giống như có các bit sau đây, các bit bổ sung được đặt: 0x24.

OR'ing giá trị này với 0x02 cung cấp cho bạn 0x26, mà bạn sẽ tìm thấy trong bảng trong bài viết.

^{Tham khảo: Nhận xét về "Làm chủ lượng tử của bạn" (Blog MSDN)}

Bảng giải thích các cài đặt lượng tử từ cùng một bài viết:

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

Tóm tắt ngắn gọn về lượng tử hệ điều hành

Dựa trên các thông tin và trích dẫn bài viết ở trên, chúng ta biết rằng lượng tử không phải là kích thước cố định, mà xuất phát từ cài đặt hệ điều hành trong Thuộc tính hệ thống. Một lượng tử thay đổi tùy thuộc vào Win32PrioritySeparationcài đặt trong sổ đăng ký thường tương ứng với một trong các cài đặt trong "Thuộc tính hệ thống" ("Dịch vụ nền" hoặc "Ứng dụng").

Một lượng tử ở cấp độ hệ điều hành là

• cho cài đặt "Ứng dụng"
  • 18 (là 6 tick) cho các ứng dụng nền trước (93,75 ms)
  • 6 (là 2 tick) cho các ứng dụng nền (31,25 ms)
• cho cài đặt "Dịch vụ nền"
  • 36 (là 18 tick) cho các ứng dụng nền trước (187,5 ms)
  • 36 (là 18 tick) cho các ứng dụng nền (187,5 ms)

Vì vậy, bây giờ chúng ta biết rằng một lượng tử hệ điều hành trên thiết lập Windows Server được tối ưu hóa cho Dịch vụ nền là ...

36 / 3 * 15.625000 ms = 187.5 ms

---

Lượng tử hệ điều hành SQL

Phần này liệt kê những gì tôi đã tìm thấy trên lượng tử hệ điều hành SQL ...

SOS_SCHEDULER_YIELD Loại chờ

Từ mô tả của Paul Randall về loại chờ đợi SOS_SCHEDULER_YIELD:

Kiểu chờ này là khi một luồng có thể thực thi cho lượng tử luồng đầy đủ của nó (4 mili giây trong tất cả các phiên bản của SQL Server, không thể thay đổi ) và do đó tự nguyện đưa ra lịch trình, di chuyển xuống dưới cùng của Hàng đợi có thể chạy trong trình lập lịch biểu của nó.

^{Tham khảo: SOS_SCHEDULER_YIELD (Các loại chờ của SQLSkills.com)}

Bộ lập lịch trong DMV SQL Server

Trong phần giải thích về các máy chủ DMV của SQL cho sys.dm_os_schedulers DMV.

[...] Windows sử dụng cơ chế lập lịch ưu tiên và gán một lượng tử thời gian CPU cho mỗi luồng, khi một luồng tiêu thụ lượng tử của nó, nó được gửi đến hàng đợi và các luồng khác được cấp thực thi.

Đối lập, SQL Server sử dụng cơ chế lập lịch hợp tác khi các luồng có thể tự nguyện mang lại lượng tử thời gian của nó (bạn có thể thấy hành vi này khi bạn có loại chờ đợi SOS_SCHEDULER_YIELD). Điều này cho phép SQL Server tối ưu hóa việc sử dụng CPU, bởi vì khi một luồng được báo hiệu để thực thi nhưng chưa sẵn sàng để chạy, nó có thể mang lại lượng thời gian có lợi cho các luồng khác .

^{Tham khảo: Tìm hiểu về Trình lập lịch, Công nhân và Nhiệm vụ của SQL Server (MSSQLTips.com)}

Phát hiện áp suất CPU của SQL Server

Đây là một phần rất nhỏ của một bài viết liên quan đến áp lực CPU trong SQL Server.

Xảy ra khi một nhiệm vụ tự nguyện mang lại lịch trình cho các nhiệm vụ khác để thực hiện. Trong thời gian chờ đợi này, nhiệm vụ đang chờ lượng tử của nó được đổi mới .

^{Tham khảo: Phát hiện áp suất CPU của SQL Server (MSSQLTips.com)}

sys.dm_os_schedulers (Tài liệu Microsoft)

Tôi đoán rằng trích dẫn sau đây là đoạn thông tin quan trọng nhất liên quan đến lượng tử hệ điều hành SQL mà tôi có thể tìm thấy:

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

^{Tham khảo: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)}

---

Câu hỏi hóc búa của tôi

Lượng tử hệ điều hành máy chủ quy định thời gian Dịch vụ máy chủ SQL được cấp để thực hiện "tác vụ". Lượng tử hệ điều hành SQL Server được định nghĩa là 4 ms. Nếu tôi chia 187,5 ms cho 4 ms thì tôi còn lại 3,5 ms.

Và chúng tôi thậm chí chưa bắt đầu cuộc thảo luận về thời điểm Đồng hồ được đặt thành một cái gì đó khác với mặc định là 15.625000 ms ....

Câu hỏi đơn giản

Lượng tử máy chủ SQL (4 ms) được đồng bộ hóa với Lượng tử hệ điều hành máy chủ (thông thường: 187,5 ms) như thế nào?

Giải thích câu hỏi đơn giản

Sau 184 ms lượng tử hệ điều hành được sử dụng (tương ứng với 46 lượng tử SQL đầy đủ), lượng tử hệ điều hành có 3,5 ms thời gian trước khi nó sẽ phải bàn giao lịch trình cho một quy trình khác. Hệ điều hành SQL bắt đầu một lượng tử (4 ms) và sau 3,5 ms, lượng tử hệ điều hành đã quyết định dừng luồng SQL OS hiện tại vẫn còn 0,5 ms trước khi nó mang lại lịch trình. Chuyện gì xảy ra bây giờ?

Mặc dù bộ lập lịch không được ưu tiên, bộ lập lịch SQL Server vẫn tuân thủ khái niệm lượng tử. Các tác vụ của máy chủ SQL hơn các hệ điều hành buộc phải từ bỏ CPU, chúng có thể yêu cầu được đưa vào hàng đợi chờ định kỳ và nếu chúng vượt quá lượng tử 4 mili giây được xác định bên trong và không ở giữa một hoạt động Không thể dừng lại, họ tự nguyện từ bỏ CPU.

- "Bộ phận Microsoft SQL Server 2012 ", Kalen Delaney et. al. Trang 38

-CHƯƠNG 2 "SQLOS" Jonathan Kehayias

Vì vậy, khái niệm "lượng tử" bên trong SQL Server giống như một "hướng dẫn" cho các nhiệm vụ lập trình. IE khi bạn viết một tác vụ, chẳng hạn như một tác vụ thực hiện quét bảng, nếu bạn không nhấn bất kỳ chốt trang nào, chốt IO hoặc khóa chờ một lúc, bạn nên dừng những gì bạn đang làm và yêu cầu đặt lại vào hàng đợi có thể chạy, trong trường hợp có các nhiệm vụ khác đang chờ.

Nhưng tùy thuộc vào lập trình viên thực hiện nhiệm vụ này và nó có thể không chính xác 4ms cho mỗi loại nhiệm vụ. Ví dụ, tác vụ quét bảng có thể sử dụng phương pháp phỏng đoán đơn giản dựa trên số lượng trang được quét để thực hiện các điểm lợi tức.

Vì thế

Hệ điều hành SQL bắt đầu một lượng tử (4 ms) và sau 3,5 ms, lượng tử hệ điều hành đã quyết định dừng luồng SQL OS hiện tại vẫn còn 0,5 ms trước khi nó mang lại lịch trình. Chuyện gì xảy ra bây giờ?

Nếu luồng SQL Server được Windows xử lý trước trong khi một tác vụ đang chạy, nó sẽ bị tạm dừng và khi luồng của nó được lên lịch tiếp theo trên CPU, nó sẽ tiếp tục ở nơi nó dừng lại. Có lẽ nó sẽ tiếp tục tiêu thụ sự cân bằng của lượng tử 4ms của nó, vì nó sẽ không biết bất kỳ sự khác biệt nào. Nhưng một lần nữa, hành vi năng suất là một chi tiết triển khai của nhiệm vụ, không phải là hành vi của SQLOS, vì vậy các nhiệm vụ khác nhau có thể hành xử khác nhau ở đây.

_{Trả lời đóng góp ban đầu để lại như ý kiến}

Lượng tử máy chủ SQL (4 ms) được đồng bộ hóa với Lượng tử hệ điều hành máy chủ (thông thường: 187,5 ms) như thế nào?

Không phải và SQL Server không sử dụng lập lịch ưu tiên. Các mục công việc dự kiến ​​sẽ đạt điểm năng suất và nếu không, bạn sẽ nhận được những thứ như NONYIELDINGlịch trình. Không có sự tương đương. SQL Server không phân phối thời gian. Nó làm cho một số chủ đề nhất định hấp dẫn để Windows lên lịch và Windows lên lịch cho chúng. Lượng tử chỉ là danh pháp cho một phần thời gian. Đó là nó. SQL Server không được ưu tiên, đó là trách nhiệm của bất cứ điều gì đang chạy để mang lại chính nó trong toàn bộ mã. - Sean Gallardy

Khi lượng tử hệ điều hành hết hạn, luồng sẽ bị giảm mạnh. Điều này là minh bạch đối với SQL Server. SQLOS không có cách nào để phát hiện khi điều này xảy ra. Không có API Win32 cho điều đó. Lập lịch là minh bạch cho chủ đề chế độ người dùng. Bộ lập lịch Windows không biết hoặc quan tâm chủ đề chế độ người dùng đang làm gì. Windows chỉ nhìn thấy các luồng có thể chạy được và cho phép chúng chạy cho đến hết lượng tử hệ điều hành hoặc cho đến khi chúng chặn. - usr

Trong Cách xử lý các giá trị loại chờ đợi SOS_SCHEDULER_YIELD quá mức trong SQL Server của Nikola Dimitrijevic, thuật ngữ "lượng tử" được sử dụng để chỉ về cơ bản là "thời gian một nhiệm vụ thực sự được giao cho một công nhân", nhưng đó không phải là ý nghĩa tương tự như một lượng tử Windows, đó là khoảng thời gian sau đó HĐH sẽ loại bỏ một luồng khỏi CPU. Chúng chỉ là những khái niệm khác nhau. Nếu HĐH buộc một luồng kết thúc thực thi vì lượng tử HĐH đã đạt được, một chuyển đổi ngữ cảnh sẽ xảy ra. Chủ đề của SQL Server bị treo, giống như bất kỳ chương trình nào khác. - David Browne - Microsoft và George.Palacios .

---

Trích xuất từ ​​tài liệu: Bên trong Bộ lập lịch chế độ người dùng SQL Server 2000 (được viết cho SQL Server 2000, nhưng vẫn có liên quan):

Nhiệm vụ ưu tiên so với hợp tác

Ngược lại, UMS dựa vào các chủ đề để mang lại tự nguyện. UMS sử dụng cách tiếp cận để tránh liên quan đến nhân Windows hơn là hoàn toàn cần thiết. Trong một hệ thống mà các luồng công nhân có thể được tính để mang lại khi họ cần, một bộ lập lịch hợp tác thực sự có thể hiệu quả hơn một quy tắc phòng ngừa bởi vì quy trình lập lịch có thể được điều chỉnh theo nhu cầu cụ thể của ứng dụng. Như tôi đã nói trước đó, UMS biết nhu cầu lập lịch trình của SQL Server tốt hơn hệ điều hành có thể được mong đợi.

Làm thế nào UMS vượt quá lịch trình

Nếu UMS là để xử lý các nhu cầu lập lịch của SQL Server thay vì cho phép Windows làm như vậy, thì UMS phải bằng cách nào đó ngăn HĐH thực hiện những gì nó làm với mọi quy trình khác: lên lịch các luồng xử lý của hệ thống khi nó thấy phù hợp. Làm thế nào để bạn làm điều đó trong một hệ điều hành phủ đầu? UMS thực hiện điều này thông qua một số thủ thuật thông minh với các đối tượng sự kiện Windows. Mỗi luồng trong UMS có một đối tượng sự kiện liên quan. Đối với mục đích lập lịch, Windows bỏ qua các luồng, nó không xem xét các luồng có thể hoạt động không thể chạy được vì chúng ở trạng thái chờ vô hạn. Biết được điều này, UMS đặt các luồng vào trạng thái ngủ mà nó không muốn được lên lịch bằng cách yêu cầu chúng gọi WaitForSingleObject trên đối tượng sự kiện tương ứng của chúng và truyền INFINITE cho giá trị thời gian chờ.

Để ngăn Windows lên lịch cho nhiều luồng trên cùng một bộ xử lý và do đó phát sinh chi phí và chi phí chuyển đổi ngữ cảnh, UMS cố gắng chỉ giữ một luồng khả thi mà không phải là trạng thái chờ đợi vô hạn trên mỗi bộ xử lý.