Windows İşletim Sistemi Quantum ve SQL İşletim Sistemi Quantum


19

Basit soru

SQL Server Quantum (4 ms), Sunucu İşletim Sistemi Kuantumu ile nasıl senkronize edilir (normalde: 187,5 ms)?

Basit Soru Açıklaması

184 ms OS kuantum kullanıldıktan sonra (46 tam SQL kuantumuna karşılık gelir), OS kuantumunun programın farklı bir sürece aktarılması gerekmeden önce 3.5 ms süresine sahiptir. SQL OS bir kuantum (4 ms) başlatır ve 3.5 ms sonra, OS kuantumu, zamanlamayı vermeden önce hala 0,5 ms olan geçerli SQL OS iş parçacığını durdurmaya karar verir. Şimdi ne olacak?


OS Quantum'da Derin Dalış

Sonraki birkaç bölümde, OS kuantumuyla ilgili şimdiye kadar bulduğum şeyi ve bir kuantum süresinin nasıl hesaplanabileceğini yazacağım. Bir OS "kuantum" süresi "keneler" ve "kenenin" süresi normalde 15.625000 ms olan "saat aralığı" na dayanır. Ama biraz ayrıntıya gireyim ...

kene

Know Thy Tick adlı blog makalesinde yazar Jim saat aralıklarının ("kene" olarak da bilinir) temellerini ve ne için olduklarını açıklıyor.

“Çoğu x86 çok işlemcili için saat aralığı… gibi yaklaşık 15 milisaniye” gibi bir şey okuduğumda, saatimin veya “onay” aralığının değerini belirlemek zorunda kalıyorum. Neyse ki, bu alıntıyı okuduğum kitap, Windows Internals Fourth Edition rahatsızlığım için bana bir referans sunuyor. ... Yukarıda adı geçen kitabın yazarı Mark Russinovich, ClockRes yardımcı programını nezaketle web sitesinde yayınladı. Bu yardımcı programı kullanarak, x86 çok işlemcili bilgisayarımdaki saat aralığının 15.625000 ms olduğunu belirleyebildim. İlginç, ama meraklı zihnim daha fazlasını bilmek istiyor.

Kuantum

Makalenin yazarı ikinci makalesinde açıklamaya devam ediyor O ...

Tabii ki, kene aralığının önemli olmasının gerçek nedeni, iplik zamanlamasını etkilemesidir . Windows zamanlayıcı, aynı öncelik düzeyinde başka bir görevin çalışmasına izin vermeden önce her iş parçacığının yürütülmesi için bir "kuantum" süresi verir. Zamanlayıcının bir iş parçacığına atadığı kuantum, tik aralığının bir katıdır . Belirli bir iş parçacığı için seçilen belirli kuantum değeri, bu makaleye gitmek istediğim yerden biraz daha fazla.

Tamam, bu yüzden bir kuantumun ne olduğunu biliyorum, ama bir kuantumun ne kadar süreceğini bilmiyorum.

Şimdilik, XPe'de bir ön plan iş parçacığı için varsayılan kuantum değerini inceleyelim. Bu durumda, Windows zamanlayıcı 18 veya 6 kene aralıklarıyla kuantum atar. (Evet, kuantumu kene aralıklarına dönüştürmek için 3'e bölünmek gerekir, ancak çoğunun nedeni, programlayıcının bir iş parçacığını askıya almasına neden olan bir işlem için “şarj etme” yeteneğine izin vermesidir.)

Artık bir saat aralığının (kene) 15.625000 ms civarında ve varsayılan kuantumun 18 olduğu bir Windows Masaüstü İşletim Sisteminde olması gerektiğini biliyoruz, bunun 6 keneyle veya 93.750000 ms (18/3 * 15.625000 ms) ile sonuçlanacağı.

Windows Server işletim sisteminde varsayılan kuantum farklıdır. "İşlemci zamanlaması" ayarı "Arka Plan Hizmetleri" olarak ayarlandı

Bu ayar "Sistem Ayarları | Gelişmiş (sekme) | Performans (bölüm) | Ayarlar ..." aracılığıyla "Perofrmance Seçenekleri | Gelişmiş (sekme) | İşlemci zamanlaması" açılır

Varsayılan kuantum ayarları 36 (Arka Plan) ila 36 (Ön Plan) şeklindedir. Kuantum daha büyük ve dolayısıyla daha uzun. Bu, Windows Masaüstü İşletim Sistemindeki 18 (6 onaylı) kuantum ön plan ayarının 93.750000 ms'lik miktarının iki katıdır ve Arka Plan Hizmetleri için ayarlanan bir sunucu işletim sisteminde 187.500000 ms'dir.

Gözlem / Açıklama

Bir sunucuda veya masaüstünde ayarı "Arka plan hizmetleri" olarak " Uygulayıcılar" olarak değiştirdiğinizde, kayıt defterindeki HKLM \ SYSTEM \ CurrentControlSet \ Control \ PriorityControl \ Win32PrioritySeparation anahtarı 0x18'den 0x02 olarak değiştirilir. 0x02 için varsayılan kuantum değeri nedir? Bu bir yorumda bulunabilir:

0x02 değeri işletim sistemi için "Kısa - Uzun" ve "Değişken - Sabit" alanlarının varsayılan değer olduğunu belirtir.

XPe ve XP Pro için bu alanlar için varsayılan değer şudur: Aşağıdaki bit ek bitlerinin ayarlanmasıyla aynı olan Kısa ve Değişken: 0x24.

VEYA, bu değeri 0x02 ile girdiğinizde makaledeki tabloda bulacağınız 0x26 değerini elde edersiniz.

Referans: "Kuantumunuzda Ustalaşın" için yorum yapın (MSDN Blogs)

Aynı makaledeki kuantum ayarlarını açıklayan tablo:

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

OS Quantum'un Kısa Özeti

Yukarıdaki bilgilere ve makale alıntılarına dayanarak, kuantumun sabit bir boyut olmadığını, aksine Sistem Özellikleri'ndeki bir OS ayarından türetildiğini biliyoruz. Kuantum Win32PrioritySeparation, kayıt defterindeki normalde "Sistem Özellikleri" ("Arka plan hizmetleri" veya "Uygulamalar") ayarlarından birine karşılık gelen ayara bağlı olarak değişir .

İşletim sistemi düzeyinde bir kuantum

  • "Uygulamalar" ayarı için
    • Ön plan uygulamaları için 18 (6 kenedir) (93.75 ms)
    • 6 (2 keneler olan) arka plan uygulamaları için (31,25 ms)
  • "Arka Plan Hizmetleri" ayarı için
    • Ön plan uygulamaları için 36 (18 kene) (187.5 ms)
    • Arka plan uygulamaları için 36 (18 kene) (187.5 ms)

Artık Biliyoruz ki, Windows Server kurulumunda Arka Plan Hizmetleri için optimize edilecek bir işletim sistemi kuantumu ...

36 / 3 * 15.625000 ms = 187.5 ms

SQL OS Quantum

Bu bölümde SQL OS kuantumunda bulduğum ...

SOS_SCHEDULER_YIELD Bekleme Türü

Paul Randall'ın SOS_SCHEDULER_YIELD bekleme tipindeki açıklamasından:

Bu bekleme türü, bir iş parçacığının tam iş parçacığı kuantumunu (SQL Server'ın tüm sürümlerinde 4 milisaniye, değiştirilemez ) çalıştırabilmesidir ve bu nedenle gönüllü olarak zamanlayıcıyı, zamanlayıcısında Runnable Kuyruğunun altına doğru hareket ettirir.

Başvuru: SOS_SCHEDULER_YIELD (SQLSkills.com Bekleme Türleri)

SQL Server DMV'lerinde Zamanlayıcılar

Sys.dm_os_schedulers DMV için SQL Server DMV'lerine ilişkin bir açıklamada.

[...] Windows, önleyici bir programlama mekanizması kullanır ve her iş parçacığına bir kuantum CPU zamanı atar, bir iş parçacığı kuantumunu tükettiğinde bir kuyruğa gönderilir ve diğer iş parçacıklarına yürütme verilir.

Buna karşılık, SQL Server iş parçacıklarının zamanını gönüllü olarak verebildiği zaman bir kooperatif zamanlama mekanizması kullanır (SOS_SCHEDULER_YIELD bekleme türünüz olduğunda bu davranışı görebilirsiniz). Bu, SQL Server'ın CPU kullanımını optimize etmesini sağlar, çünkü bir iş parçacığı yürütme için sinyal verildiğinde ancak çalışmaya hazır olmadığında, diğer iş parçacıkları lehine onun kuantum zamanını verebilir .

Başvuru: SQL Server Zamanlayıcıları, Çalışanları ve Görevleri Anlama (MSSQLTips.com)

SQL Server CPU Basıncını Algılama

Bu, SQL Server'daki CPU basıncıyla ilgili bir makalenin çok küçük bir bölümüdür.

Bir görev gönüllü olarak diğer görevlerin yürütmesi için zamanlayıcıyı verdiğinde oluşur. Bu bekleme sırasında görev kuantumun yenilenmesini bekliyor .

Başvuru: SQL Server CPU Basıncını Algılama (MSSQLTips.com)

sys.dm_os_schedulers (Microsoft Belgeleri)

Aşağıdaki alıntı, bulabildiğim SQL OS kuantum ile ilgili bilgilerin en önemli snippet'i olduğunu tahmin ediyorum:

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

Başvuru: sys.dm_os_schedulers (Transact-SQL) (Microsoft | Docs)


Bilmem

Sunucu İşletim Sistemi Kuantumu, SQL Server Hizmetinin "görevleri" yürütmesi için ne kadar zaman verileceğini düzenler. SQL Server OS Quantum 4 ms olarak tanımlanır. 187,5 ms'yi 4 ms'ye bölersem 3,5 ms kaldı.

Ve Saat Aralığı'nın varsayılan 15.625000 ms'den başka bir şeye ayarlandığı zaman bile tartışmaya başlamamıştık ....

Basit soru

SQL Server Quantum (4 ms), Sunucu İşletim Sistemi Kuantumu ile nasıl senkronize edilir (normalde: 187,5 ms)?

Basit Soru Açıklaması

184 ms OS kuantum kullanıldıktan sonra (46 tam SQL kuantumuna karşılık gelir), OS kuantumunun programın farklı bir sürece aktarılması gerekmeden önce 3.5 ms süresine sahiptir. SQL OS bir kuantum (4 ms) başlatır ve 3.5 ms sonra, OS kuantumu, zamanlamayı vermeden önce hala 0,5 ms olan geçerli SQL OS iş parçacığını durdurmaya karar verir. Şimdi ne olacak?

Yanıtlar:


13

Zamanlayıcı önleyici olmasa da, SQL Server zamanlayıcı yine de bir kuantum kavramına bağlı. SQL Server görevlerinden daha çok, işletim sistemi tarafından CPU'dan vazgeçmek zorunda kalırlar, periyodik olarak bir bekleme kuyruğuna konulmasını isteyebilirler ve dahili olarak tanımlanan 4 milisaniyelik kuantumu aşmışlarsa ve bir işlemin ortasında değilse durdurulamaz, isteyerek CPU'dan vazgeçerler.

- " Microsoft SQL Server 2012 Internals ", Kalen Delaney ve ark. ark. PP38

-Bölüm 2 "SQLOS" Jonathan Kehayias

Yani SQL Server içindeki bir "kuantum" kavramı programlama görevleri için bir "kılavuz" daha fazladır. IE, bir tablo yazdığınızda, bir tablo taraması gerçekleştiren bir görev yazdığınızda, herhangi bir sayfa mandalına, IO mandalına veya kilide bir süre beklemezseniz, yaptığınız işi durdurmalı ve olmasını istemelisiniz bekleyen başka görevler olması durumunda çalıştırılabilir kuyruğa geri koyun.

Ancak bunu uygulamak görev programcısına bağlıdır ve her bir görev için tam olarak 4 ms olmayabilir . Örneğin, tablo tarama görevi, verim noktalarını uygulamak için taranan sayfa sayısına bağlı olarak basit bir sezgisel tarama kullanabilir.

Yani

SQL OS bir kuantum (4 ms) başlatır ve 3.5 ms sonra, OS kuantumu, zamanlamayı vermeden önce hala 0,5 ms olan geçerli SQL OS iş parçacığını durdurmaya karar verir. Şimdi ne olacak?

SQL Server iş parçacığı, bir görev çalışırken Windows tarafından önceden tüketilirse, duraklatılır ve iş parçacığı bir CPU'da bir sonraki programlandığında, kaldığı yerden devam eder. Muhtemelen herhangi bir fark bilmeyeceği için 4ms kuantum dengesini tüketmeye devam edecektir. Fakat yine de, verim davranışı, SQLOS'un bir davranışı değil, görevin bir uygulama detayıdır, bu nedenle farklı görevler burada farklı davranabilir.


4

Başlangıçta yorum olarak bırakılan cevap katkıları

SQL Server Quantum (4 ms), Sunucu İşletim Sistemi Kuantumu ile nasıl senkronize edilir (normalde: 187,5 ms)?

Değil ve SQL Server önleyici zamanlama kullanmaz. İş kalemlerinin akma noktalarına ulaşması bekleniyor ve eğer almazlarsa, NONYIELDINGzamanlayıcılar gibi şeyler alırsınız . Eşlik yok. SQL Server zamanı dağıtmaz. Belirli iş parçacıklarını zamanlamak ve Windows zamanlamak için Windows için çekici hale getirir. Kuantum sadece bir süre için isimlendirmedir. Bu kadar. SQL Server önleyici değildir, kod boyunca kendini sağlamak için çalışanların sorumluluğundadır. - Sean Gallardy

OS kuantumunun süresi dolduğunda, iplik zorla deschedüle edilir. Bu SQL Server için şeffaftır. SQLOS bunun ne zaman gerçekleştiğini algılamanın bir yolu yoktur. Bunun için Win32 API yok. Zamanlama, kullanıcı modu iş parçacığı için şeffaftır. Windows zamanlayıcı, kullanıcı modu iş parçacıklarının ne yaptığını bilmiyor veya önemsemiyor. Windows yalnızca çalıştırılabilir iş parçacıklarını görür ve işletim sisteminin kuantumunun sonuna kadar veya engellenene kadar çalışmasına izin verir. - usr

Gelen SQL Server aşırı SOS_SCHEDULER_YIELD bekleme türü değerlerini işlemek nasıl Nikola Dimitriyeviç tarafından, dönem "kuantum" esasen "bir görev aslında bir çalışana atanır harcadığı zamanı" anlamında kullanılmaktadır, ancak bu Windows kuantum aynı anlamda değil edilir, Bu, işletim sisteminin bir iş parçacığını CPU'dan kaldıracağı bir süredir. Onlar sadece farklı kavramlar. İşletim sistemi kuantumuna ulaşıldığı için işletim sistemi bir iş parçacığını yürütmeyi sonlandırmaya zorlarsa, bir bağlam anahtarı oluşur. SQL Server'ın iş parçacığı, diğer tüm programlar gibi askıya alınır. - David Browne - Microsoft ve George.Palacios .


Belgelerden alıntılar: SQL Server 2000 Kullanıcı Modu Zamanlayıcı'nın içinde (SQL Server 2000 için yazılmıştır, ancak yine de önemlidir):

Önleyici ve İşbirlikçi Görev

Buna karşılık UMS, gönüllü olarak verim elde etmek için dişlere dayanır. UMS, Windows çekirdeğini kesinlikle gerekenden daha fazla dahil etmemek için yaptığı yaklaşımı benimser. İşçi iş parçacıklarının gerektiğinde verim elde edebileceği bir sistemde, bir kooperatif zamanlayıcı aslında önleyici olandan daha verimli olabilir çünkü zamanlama işlemi uygulamanın özel ihtiyaçlarına göre uyarlanabilir. Daha önce de söylediğim gibi UMS, SQL Server'ın programlama gereksinimlerini işletim sisteminin beklenenden daha iyi biliyor.

UMS Zamanlamayı Nasıl Ele Alır

UMS, Windows'un bunu yapmasına izin vermek yerine SQL Server'ın zamanlama gereksinimlerini karşılayacaksa, UMS'nin işletim sisteminin diğer tüm işlemlerle yaptıklarını yapmasını bir şekilde engellemesi gerekir: iş parçacıklarını sistem işlemcisini / işlemelerini uygun gördüğü şekilde açma ve kapatma. Bunu önleyici bir işletim sisteminde nasıl yaparsınız? UMS, bunu Windows olay nesneleriyle bazı akıllı numaralardan çıkarır. UMS altındaki her iş parçacığının ilişkili bir olay nesnesi vardır. Zamanlama amacıyla, Windows, geçerli olarak görmediği iş parçacıklarını yoksayar; sonsuz bekleme durumunda oldukları için çalışamayan iş parçacıkları. Bunu bilerek, UMS, iş parçacıklarını karşılık gelen olay nesnesinde WaitForSingleObject'i çağırıp zaman aşımı değeri için INFINITE ileterek zamanlamak istemediği şekilde uyutur .

Windows'un aynı işlemcide birden çok iş parçacığı zamanlamasını ve böylece bağlam anahtarlarının ek yükünü ve masrafını üstlenmesini önlemek için UMS, işlemci başına yalnızca bir iş parçacığını (yani, sonsuz bir bekleme durumunda değil) uygulanabilir tutmaya çalışır.

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.