SQL Server - Herkes SUMA, iz bayrağı 8048 veya iz bayrağı 8015 kullanıyor mu?

Son zamanlarda bir SQL Server 2008 R2 sisteminde ciddi bir spinlock çekişmesi sorununu çözmek için SQL Server başlangıcı İzleme Bayrağı 8048 dahil edildi.

Performans değerinin izleme bayrağı 8048 tarafından iletildiği kullanım durumlarını bulan diğer kişilerden duymak (NUMA düğümü başına çekirdek başına sorgu belleği verme stratejisini teşvik etmek), izleme bayrağı 8015'i (SQL Server fiziksel NUMA'yı yok sayar) veya SUMA ( Yeterince üniform bellek erişimi, bazı NUMA makinelerde bir BIOS seçeneği araya sokuldu).

İz bayrağı 8048 http://blogs.msdn.com/b/psssql/archive/2011/09/01/sql-server-2008-2008-r2-on-newer-machines-with-more-than-8-cpus -presented başına numa-düğüm-may-ihtiyaç iz-flag-8048.aspx

İz bayrağı 8015 http://blogs.msdn.com/b/psssql/archive/2010/04/02/how-it-works-soft-numa-io-completion-thread-lazy-writer-workers-and-memory -nodes.aspx

Sistem iş yükünün kanlı detayları, sorunlu sistemden metrikler toplandı ve müdahale sonrasında sistemden metrikler toplandı.

İz bayrağı 8048 'düzeltme' idi, ancak en iyi düzeltme miydi? SQL Server 8015 izleme bayrağı nedeniyle fiziksel NUMA'yı görmezden geliyorsa aynı şeyi yapmış mıydı? BIOS'u belleği araya sokacak şekilde ayarlayıp sunucuyu NUMA davranışı yerine SMP taklit eden SUMA davranışıyla bırakmaya ne dersiniz?

Barış! tw: @sql_handle

Sistem hakkında: - 4 hex core Xeon E7540 @ 2.00GHz, aşırı dişli - 128 GB RAM - WS2008R2 - MSSQL 2008 R2 SP2 - maxdop 6

İş yükü hakkında: - 2 rapor uygulama sunucusundan alınan 1000'lerce Toplu iş planlı / sıralı rapor. - 3 parti parti: günlük, haftalık, aylık - Tüm rapor uygulama sunucularının SQL Server'a bağlantıları tek bir hizmet hesabı olarak yapılır - Maksimum rapor eşzamanlılığı = 90

Sorunlu sistemdeki önemli bulgular: - Perfmon'dan 15 saniyelik aralıklarla - - Sistem% 95 -% 100 CPU'da meşgul - - SQL Server arabellek sayfası aramaları saniyede 10000 / saniye

• Bekleme ve spinlock DMV'lerinden 5 dakikalık aralıklarla
• • Yüksek CMEMTHREAD garsonlar ve bekleme süresi
• • Yüksek SOS_SUSPEND_QUEUE dönüş ve geri çekilme

Bob Dorr'ın 8048 izleme bayrağı üzerindeki CSS Engineer Blog yazısı, NUMA düğümü başına 8 çekirdekten fazla olan sistemlerin, sorgu belleği verimindeki tıkanıklık nedeniyle benzer belirtilerle karşılaşabileceğini gösteriyor. İzleme bayrağı 8048, stratejiyi NUMA düğümü yerine çekirdek başına olarak değiştirir.

Müdahale

MSSQL, -T8048 ile yerinde yeniden başlatıldı. Fark hemen belli oldu: tampon sayfa arama oranı 1 milyonun üzerine çıktı ve saniyede 8 milyona yükseldi. Daha önce 24 saatte tamamlanamayan sorunlu toplu iş yükü 4 saatten daha az bir sürede tamamlandı. Araştırma ya da müdahalenin odağı olmayan bir başka toplu iş yükü, izleme bayrağı 8048'in düzeltici değerini doğrulamanın bir parçası olarak (ve istenmeyen yan etkilerinin en az düzeyde olmasını sağlamanın bir parçası olarak) sunuldu. Bu rapor partisi daha önce 2 saat içinde tamamlandı; izleme bayrağı 8048 yerinde olduğunda, rapor partisi yaklaşık 20 dakikada tamamlandı.

Gecelik ETL de bir fayda ile karşılaştı. ETL süresi yaklaşık 60 dakikadan 40 dakikaya düştü.

Birkaç yerden bilgiyi bir araya getirerek, yüksek dereceli rapor kuyruğu derecesinin, eşzamanlı raporun donanım iş parçacığı sayısından daha büyük olduğunu ve çalışanların iş parçacığı baskısı neden olana kadar bir NUMA düğümü üzerinde baskı oluşturmak için birleştirilmiş tüm raporlar için tek bir kullanıcı hesabının olduğunu tahmin ediyorum. Aynı kullanıcı hesabı için bir sonraki bağlantı talebinde bulunmaktan zevk alacaksınız, bu noktada bir sonraki NUMA düğümü anında bazı bağlantılara kavuşacaktır. Her NUMA düğümü, sorgu belleği verim tıkanmasını vurgulama olasılığı yüksek olacak.

Sorgu belleği için daha fazla şerit açmak, tıkanıklığı giderdi. Ama bunun maliyetinden emin değilim. Bob Dorr'ın CSS yazısı, 8048 izleme bayrağıyla ek bir ek bellek olduğunu açıkça ortaya koyuyor. Bu, MSSQL 2008 R2 maksimum sunucu belleği tarafından yönetilen tek sayfalık ayırıcı bölgedeki ek yük mü? Öyleyse, sistemin tampon havuzu önbelleğinde daha az sayıda veritabanı sayfasına sahip olacağını tahmin ediyorum. Değilse, maksimum sunucu belleği yerleştirmek için düşürülmeli midir?

Bu harika bir yazı.

Son sorunuzu cevaplamak için cevabınızın "evet" olduğunu tahmin ediyorum.

Bu, muhtemelen iz bayraklarına başvurmadan önce yumuşak numa izlerdim. Numa düğümü tahsisi konusunda haklısınız ve bu probleminizin temelinde olabilir. Yumuşak numa aracılığıyla, sayı sayısını (4?) - 4'e (doğru sayıysa) bağlı olarak istekleri ölçeklendirebilir ve ardından, her ana bilgisayarı ip adresi aracılığıyla belirli bir sayı düğümüne atayabilirsiniz. Bunun için hiper iş parçacığını devre dışı bırakırdım. Birleştiğinde, sorun muhtemelen azalacak, ancak daha az sayıda zamanlayıcıya mal olacak.

Ayrı bir düşünceye göre, zorla parametreleştirmeye bakardım - yükünüzün işlemcinizi çok yüksek kullanması çok ilginç ve buna değer olabilir.

Son olarak, çok numa düğümlü sistemlerde, tipik olarak her N saniyede bir masaya boşalan aşağıdaki sorguların çıktısına sahibim. İş yükü değiştiğinde veya izleme bayrakları uygulandığında bazı ilginç analizler yapar:

SELECT getdate() as poll_time, node_id, node_state_desc, memory_node_id, online_scheduler_count, active_worker_count, avg_load_balance, idle_scheduler_count
FROM sys.dm_os_nodes WITH (NOLOCK) 
WHERE node_state_desc <> N'ONLINE DAC'

ve

SELECT top 10 getdate() as sample_poll, wait_type, count (*)
FROM sys.dm_os_waiting_tasks
WHERE [wait_type] NOT IN
('CLR_SEMAPHORE','LAZYWRITER_SLEEP','RESOURCE_QUEUE','SLEEP_TASK','SLEEP_SYSTEMTASK',
'SQLTRACE_BUFFER_FLUSH','WAITFOR', 'BROKER_TASK_STOP',
'BROKER_RECEIVE_WAITFOR', 'OLEDB','CLR_MANUAL_EVENT', 'CLR_AUTO_EVENT' ) 
GROUP BY wait_type
ORDER BY COUNT (*) DESC