CPU kullanımı yabancı NUMA erişiminin maliyetini etkiler mi?


21

senaryo

Her 1 NUMA düğümü ile 4 soketli bir SQL Server'ım olduğunu varsayalım. Her soketin 4 adet fiziksel çekirdeği vardır. Toplam 512 GB bellek vardır, böylece her NUMA düğümü 128 GB RAM'e sahiptir.

İlk NUMA düğümüne bir anahtar tablosu yüklenir.

Soru

Bu tablodan çok fazla trafik okuduğumuzu varsayalım. NUMA düğümüne sahip olan soketin tüm fiziksel çekirdeklerinin yüzde 100 CPU kullanımı varsa, bu, diğer soketlerden gelen yerel olmayan NUMA erişiminin maliyetini olumsuz yönde etkiler mi? Veya diğer yandan yerel olmayan NUMA erişiminin maliyeti, soketin ne kadar meşgul olduğuna bakılmaksızın mı?

Umarım sorum mantıklı. Açıklığa kavuşturmaya çalışmayacaksam lütfen bana bildirin.

Arka fon

Geçtiğimiz hafta üretim sunucumuzda bir veritabanı sorunu vardı ve işlenen işlerimizden bazıları diğerlerinden daha fazla etkilendi. 1 dakikadan fazla süren birkaç mantıksal okuma içeren sorgular vardı. Yüzde 60 civarında olan toplam CPU kullanımına baktık. Sokete özgü CPU ölçümlerine bakmadık. G / Ç ölçümleri ortalama idi.


Kin'in bahsettiği gibi bir şey üretebiliyorsanız faydalı olacaktır. Ayrıca, MAXDOP'u neye ayarladınız?
user41207

Yanıtlar:


18

Ağır bir soru :-) Ben dahil bazı faktörlerin ana hatlarını. Herhangi bir bağlamda, bu faktörler ve diğerleri değişken olabilir ve ilginç bir sonuç üretebilir.

Üzgünüm, bunu daha kısa hale getiremedim ...

  1. Birikmiş CPU ms vs mantıksal IO
  2. Fiziksel NUMA düğümleriyle SQL Server mantıksal bellek düğümü hizalaması
  3. Sorgu çalışma alanı bellek tahsisinde Spinlock çekişmesi
  4. Zamanlayıcılara görev atama
  5. Tampon havuzunda alakalı veri yerleşimi
  6. Fiziksel bellek yerleştirme

  1. Birikmiş CPU ms vs mantıksal IO

    İş yüklerinin cpu verimliliğini ölçmek ve spinlock eğilimli vakaları araştırmak için, CPU kullanımına karşı mantıksal IO grafiklerini (veya perfmon terminolojisinde "tampon havuz sayfası aramaları") çok sık kullanıyorum.

    Ancak SQL Server, CPU arama zamanını sayfa aramaları ve spinlock'lar dışında çok fazla etkinlikle biriktirir:

    • Planlar derlendi ve yeniden derlendi.
    • CLR kodu yürütülür.
    • İşlevler gerçekleştirildi.

    Diğer pek çok etkinlik, sayfa aramalarına yansıtılmadan önemli CPU zamanını azaltacaktır.

    Gözlemlediğim iş yüklerinde, bu "mantıksal olmayan, yoğun ama CPU-kargaşası" aktiviteleri arasında en önemli olanı sıralama / karmalaştırma aktivitesidir.

    Sebep durur: Topaklanamayan indeksleri olmayan bir karma tabloya karşı iki sorgudan oluşan tartışmalı bir örnek düşünün. İki sorgu aynı sonuçlara sahiptir, ancak sonuç kümelerinden biri tamamen sıralanmamıştır ve ikinci sonuç kümesi seçilen sütunlardan bir tanesi tarafından sıralanmıştır. İkinci sorgunun, tampon havuzunda aynı sayıda sayfaya referans vermesine rağmen daha fazla CPU zamanı harcaması beklenir.

    Bu yazılarda çalışma alanı belleği ve verilen çalışma alanının ne kadarının kullanıldığı hakkında daha fazlası:


  1. Fiziksel NUMA düğümleriyle SQL Server mantıksal bellek düğümü hizalaması

    SQL Server (NUMA ile uyumlu stratejilerini içerdiğinden beri) varsayılan olarak sunucudaki her NUMA düğümü için bir SQLOS bellek düğümü oluşturur. Bellek tahsisleri büyüdükçe, her tahsis SQLOS bellek düğümlerinden biri tarafından kontrol edilir.

    İdeal olarak, SQLOS bellek düğümleri fiziksel NUMA düğümleriyle tamamen aynı hizadadır. Başka bir deyişle, her SQLOS bellek düğümü, aynı NUMA düğümünden bellek içeren başka bir SQLOS bellek düğümü olmayan tek bir NUMA düğümünden bellek içerir.

    Ancak, bu ideal durum her zaman böyle değildir.

    Aşağıdaki CSS SQL Server Mühendisleri blog yazısı (Kin'in cevabına da dahil), SQLOS bellek düğümleri için kalıcı NUMA çapraz düğüm bellek ayırmalarına yol açabilecek davranış detaylarını vermektedir. Bu olduğunda, performansın etkisi yıkıcı olabilir.

    Özellikle ağrılı kalıcı çapraz NUMA düğümü referansı vakası için birkaç düzeltme yapılmıştır. Muhtemelen bu ikisine ek olarak diğerleri:


  1. Çalışma alanı hafızasının tahsisi sırasında spinlock çekişmesi

    Burası eğlenmeye başladığı yer. Çalışma alanı belleğindeki sıralama ve karma çalışmaların CPU harcadığını ancak bpool arama numaralarına yansıtılmadığını zaten tarif etmiştim.

    Spinlock çekişmesi bu özel eğlence için başka bir katmandır. Bellek arabellek havuzundan çalındığında ve sorgu belleği verilmesine karşı kullanılmak üzere tahsis edildiğinde, bellek erişimi bir döndürme kilidi ile serileştirilir. Varsayılan olarak, bu NUMA düğümü düzeyinde bölümlenmiş bir kaynakla gerçekleşir. Bu nedenle, çalışma alanı belleği kullanan aynı NUMA düğümündeki her sorgu, belleği hibelere karşı çalarken potansiyel olarak spinlock çekişmesi yaşayabilir. Unutulmaması gereken çok önemli: bu, "sorgu başına bir kez" çekişme riski değildir, çekişme noktası gerçek hibe zamanında olsaydı olduğu gibi. Aksine, hafızanın hibeye karşı çalınması durumunda - çok büyük bir hafıza hibesine sahip bir sorgu, hibesinin çoğunu kullanıyorsa, spinlock çekişmesi için birçok fırsata sahip olacaktır.

    İz bayrağı 8048, kaynağı temel düzeyde daha da bölümlere ayırarak bu çekişmeyi gidermek için harika bir iş çıkarmaktadır.

    Microsoft, "soket başına 8 veya daha fazla çekirdek varsa, izleme bayrağı 8048'i düşünün" diyor. Ama ... bu gerçekten yuva başına kaç tane çekirdek (çoklu olduğu sürece) değil, tek bir NUMA düğümü üzerinde çalışmalarda çekişme için kaç tane fırsat var.

    Yapıştırılmış AMD işlemcilerinde (soket başına 12 çekirdek, soket başına 2 NUMA düğüm), NUMA düğümü başına 6 çekirdek vardı. İzleme bayrağı 8048 etkinleştirilinceye kadar spinlock konvoyunda sıkışan bu CPU'lardan 4'ünün (yani sekiz NUMA düğümü, her biri 6 çekirdekli) bir sistemi gördüm.

    Bu spinlock çekişmesinin, VM'lerdeki performansı 4 vCPU kadar küçük düşürdüğünü gördüm. İz bayrağı 8048, bu sistemlerde etkinleştirildiğinde olması gerekeni yaptı.

    Dışarıda hala 4 çekirdek frekans optimize edilmiş işlemcisi olduğu göz önüne alındığında, doğru iş yüküyle birlikte 8048 iz bayrağından da faydalanacaklardı.

    CMEMTHREAD, izleme bayrağı 8048'in rahatlattığı spinlock çekişmesi tipine eşlik ediyor. Ancak dikkatli olunacak bir kelime: CMEMTHREAD beklemeleri, bu özel sorunun kök nedeni değil, destekleyici bir semptomdur. CMEMTHREAD yüksek "bekleme başlangıcı" olan sistemler gördüm, burada 8048 ve / veya 9024 izleme bayrağı dağıtımda ertelendi, çünkü biriken CMEMTHREAD bekleme süresi oldukça düşüktü. Döndürme kilitlerinde, biriktirilmiş bekleme süresi genellikle bakmak için yanlış bir şeydir. Daha ziyade, boşa harcanan CPU zamanına bakmak istersiniz - öncelikli olarak dönüşlerin kendileri tarafından temsil edilir, ikincil olarak potansiyel olarak gereksiz bağlam anahtarlarını temsil eden ilişkili beklemeler tarafından temsil edilir.


  1. Zamanlayıcılara görev atama

    NUMA sistemlerinde, belirli NUMA düğümleriyle ilişkili bağlantı bitiş noktaları olmadığı varsayılarak, NUMA düğümlerine (aslında - bunlarla ilişkilendirilmiş SQLOS zamanlayıcı gruplarına) yuvarlak robin dağıtılır. Bir oturum paralel bir sorgu yürütürse, çalışanları tek bir NUMA düğümünden kullanma konusunda güçlü bir tercih vardır. Hmmm ... 4 yola bölünmüş karmaşık bir sorgu ile 4 NUMA düğüm sunucusu ve varsayılan 0 MAXDOP olarak düşünün. Sorgu yalnızca MAXDOP çalışan iş parçacığı kullansa bile, NUMA düğümündeki her bir mantıksal CPU için 4 çalışan iş parçacığı olacaktır. Ancak karmaşık planda 4 yol var - NUMA düğümündeki her bir mantıksal CPU'nun üzerinde 16 işçi olabilir - hepsi tek bir sorgu için!

    Bu nedenle, bazen birileri NUMA düğümünün diğerleri çalışırken sıkıştığını görürsünüz.

    Görev atamanın birkaç nüansı var. Ancak, ana paket şu ki, meşgul CPU mutlaka NUMA düğümleri arasında eşit olarak dağıtılmayacak. (Ayrıca, bpool sayfa eklerinin (okur veya ilk sayfa yazanların) çalışanın üzerinde bulunduğu zamanlayıcı ile ilişkili SQLOS bellek düğümündeki bpool'a gireceğini fark etmek iyi. Ve çalınan sayfalar tercihen "yerel" SQLOS bellekten gelecek düğüm de.

    Maxdop'u 0'dan en fazla 8'e getirmenin faydalı olduğunu gördüm. İş yükü profiline bağlı olarak (öncelikle eşzamanlı olarak beklenen potansiyel uzun süreli sorguların sayısına bağlı olarak imo), MAXDOP = 2'ye kadar devam edilmesi garanti edilebilir.

    Paralellik için maliyet eşiğini ayarlamak da yardımcı olabilir. Çalıştığım sistemler, yüksek maliyetli sorgularla tüketilme eğilimindedir ve nadiren 50 veya 100'ün altındaki bir planla karşılaşır, bu nedenle, maliyet eşiğini ayarlamaktan ziyade maksdop'u (iş yükü grubu düzeyinde kızartılmış) ayarlayarak daha fazla çekiş yaptım.


  1. Bpool'a alakalı veri yerleştirme

    NUMA sunucuları ile ilgilenirken en sezgisel olduğunu düşündüğüm durum budur. Aynı zamanda, en tipik haliyle, iş yükü performansı için son derece önemli değildir.

    Tablo, NUMA düğümü 3'teki bpool'a okunursa ve daha sonra NUMA düğümü 4'teki bir sorgu, NUMA düğümlerinde tüm bpool aramalarını yapan tabloyu tararsa ne olur?

    Linchi Shea'nın bu performans etkisi üzerine harika bir yazısı var:

    NUMA düğümleri arasında belleğe erişmek, az miktarda ek bellek gecikmesi yaşar. En iyi performans için ek temel bellek gecikme süresini ortadan kaldırması gereken bazı iş yükleri olduğuna eminim - bu, çalıştığım sistemlerde bir sorun değildi.

    Ancak - çapraz düğüm erişimi ayrıca potansiyel olarak doyurucu olabilecek başka bir aktarma noktası da getirir. NUMA düğümleri arasındaki bellek bant genişliğinin doygun olduğu bir etkinlik varsa, düğümler arasındaki bellek gecikmesi artacaktır. Aynı iş ek CPU çevrimleri gerektirecektir.

    Yine - bellek bant genişliğinin kritik bir konudur gibi iş yükleri olduğundan eminim. Sistemlerim için listelediğim diğer konular daha önemliydi.


  1. Fiziksel bellek yerleştirme

    Bu nadirdir, ancak önemli olduğunda, gerçekten önemlidir. Çoğu sunucuda, bellek kurulumu neredeyse doğal olarak NUMA düğümleri arasında dengelenecek. Ancak bazı durumlarda, belleği düğümler arasında dengelemek için özel dikkat gerekir. Bazı sistemlerdeki performans, bellek dengesiz bir şekilde yuvalanmışsa kesinlikle çözülebilir. Bu olsa, set-it-ve-unut. İlk gerçekten yoğun geçen günün aksine, aylarca süren üretim hizmetinden sonra böyle bir problemi keşfetmek çok nadirdir.


BÜYÜK BİTİR!

Bir başkası, belki de eski istatistiklere bağlı olarak, zayıf plan seçiminin, gördüğünüz semptomlara yol açabileceği noktasını vurguladı. Bu benim deneyimimde böyle olmamıştır. Kötü planlar kolayca bir sorgunun beklenenden daha uzun sürmesine neden olabilir - ancak genellikle gerekenden daha fazla mantıksal işlem gerçekleştirildiği için. Veya dökülme nedeniyle tempdb. Sunucuyu gözetlerken tempdb'ye büyük miktarda dökülme belirgin olmalı - ve yüksek CPU yerine biri dökülmeyle ilgili disk yazmalarında ölçülebilir bekleme süresi bekler.

Bunun yerine, gözlemlediğiniz durum NUMA ile ilgiliyse, bunun yukarıda belirtilen faktörlerin bir birleşimi olmasını bekliyorum, çoğunlukla:

  1. çalışma alanı belleğinin kullanımı (mantıksal IO sayımlarında görünmeyecek)

  2. kalıcı yabancı bellek durumu nedeniyle çapraz NUMA düğümü olabilir (bu durumda, ilgili düzeltmeleri arayın).

  3. ve NUMA düğümü içerisinde spin tahsili çekişmesine neden olabilir ve bu, bir hibeye karşı tahsis yapıldığında (T8048 ile düzeltme)

  4. ve diğer paralel sorgu işçileri tarafından aşırı yüklenmiş mantıksal CPU'lar üzerinde çalışanlar tarafından yapılabilir (gerektiği şekilde paralellik ve / veya paralellik maliyet eşiğini ayarlayın)


7

( CPU / soketleriniz ve NUMA dağıtımınız hakkında daha iyi bir bağlam elde etmek için lütfen sorunuzu coreinfo -v(bir sysinternal yardımcı programı) çıktısı ile güncelleyin )

Yüzde 60 civarında olan toplam CPU kullanımına baktık. Sokete özgü CPU ölçümlerine bakmadık. G / Ç ölçümleri ortalama idi.

Bana göre yanlış ağaca havlıyorsun. SQL Server NUMAfarkında. Orada çapraz numa bellek erişimi yapmak için çok daha küçük performans cezası . Bu sorguyu, kaç tane NUMAdüğümünüz olduğunu ve hangi CPU ve çekirdeklerin atandığını görmek için de kullanabilirsiniz NUMA:

SELECT parent_node_id, scheduler_id, cpu_id
FROM sys.dm_os_schedulers WITH (NOLOCK) 
WHERE [status] = N'VISIBLE ONLINE';

Ya da sadece kaç tane NUMA:

select COUNT(distinct Parent_node_id)
from sys.dm_os_schedulers
where [STATUS] = 'VISIBLE ONLINE'
    and Parent_node_ID < 64

1 dakikadan fazla süren birkaç mantıksal okuma içeren sorgular vardı.

Bu, normalde eski istatistikler nedeniyle oluşturulan hatalı sorgu planlarınız olduğunda gerçekleşir. Emin size sahip olun istatistikler güncellenir ve endeksleri düzgün birleştirdiniz edilir .

Ayrıca, iş parçacığı açlıktan kaçınmak için MAXDOP daha duyarlı bir değere ayarlamanız gerekir .

Senin Set cost threshold of parallelism45 gibi iyi bir başlangıç değerine 5 varsayılanından koyma ve daha sonra bu değeri izlemek ve çevre başı olarak ayarlayın.

Çok fazla adhoc sorgu kullanıyorsanız, optimize for ad hoc workloadsplan önbellek şişmesini önlemek için açın (1'e ayarlayın) .

Dikkatli kullanın: SQL Server 2008/2008 R2'yi NUMA Düğümü Başına Sunulan 8'den Fazla İşlemciye Sahip Yeni Makinelerde kullanıyorsanız ve SQL Server 2012 veya 2014 kullanıyorsanız , bir düzeltme varsa , T8048'i kullanabilirsiniz .

Veri bankası sunucunuzla ilgili istatistik bilgilerini beklemeye başlamanızı şiddetle öneririz .

Bakınız: Nasıl Çalışır: SQL Server (NUMA Yerel, Yabancı ve Dışarıda Bellek Blokları)


1

Tamamen bir donanım perspektifinden bakıldığında, ana hafızanın düzenlenmesi, Nehalem mimarisini daha sonra bütünleşik bir bellek denetleyicisi tarafından yönetilmektedir, bu, CPU çekirdeğinin asıl çekirdeklerin yaşadığı kısımdan ayrı olan “Çekirdeksiz” kısmındadır, Hafıza her CPU için etkin bir şekilde 'Kablolu' olduğundan, yabancı hafıza erişimi AFAIK hızlı yol ara bağlantısı üzerindendir (Nehalem'den itibaren), bu nedenle yerel bir NUMA düğümündeki CPU çekirdeği doygunluğunun o belleğe uzaktan erişimi etkilememesi gerektiğini söyleyebilirim.

Bu bağlantıyı yararlı bulabilirsiniz:

http://cs.nyu.edu/~lerner/spring10/projects/NUMA.pdf

Chris

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.