Artan RAM, Kötü Performans

Kurmak:

Windows Server 2008 R2
SQL Server 2008 R2 SP1
240 GB RAM
TempDB, otomatik büyüme olmadan 8x16 GB veri dosyasıdır (toplam 128 GB)
Fiziksel / Bağımsız Sunucu

Bu sunucu ETL işleme için kullanılır. Bu sunucuya toplam 240GB RAM için daha fazla RAM taktık. SQL Server hizmetleri çalışan tek gerçek şeydir.

Bellek BIOS, OpenManage ve Windows'da iyi görünüyor.

SQL Server'ı Min / Maks 70 / 100GB bellek kullanacak şekilde yapılandırırsam, sorunumuz olmaz. Ancak, bunu 120 / 150GB'a yükselttiğimde, ETL işlemlerimizden birini çalıştırdığımda aşağıdaki hatayı alıyorum:

'PRIMARY' dosya grubu dolu olduğundan '<geçici sistem nesnesi: 422234507706368>' veritabanında 'tempdb' için alan ayrılamadı. Gereksiz dosyaları silerek, dosya grubundaki nesneleri bırakarak, dosya grubuna ek dosyalar ekleyerek veya dosya grubundaki mevcut dosyalar için otomatik büyümeyi ayarlayarak disk alanı oluşturun. (Msg 1105, Durum 2, Prosedür Bilinmiyor, Satır 1)

Bellek yapılandırmasını değiştirmeden önce bu sorunla hiç karşılaşmadık. Orijinal 70 / 100GB'ye yeniden yapılandırdıktan sonra bu hatayı almıyoruz.

Denediğim şeyler:

TempDB veri dosyalarını otomatik olarak büyümeye ayarlayın. Bu, disk kapasitesine ulaşılana kadar dosyaların otomatik olarak büyümesine ve ardından başarısız olmasına neden olur.
Daha fazla TempDB veri dosyası ekleyin. Gösterildiği gibi aynı hata.
TempDB boyutunu 8x32 GB'a (toplam 256 GB) artırın

Bu soruna neyin sebep olabileceği konusunda bir kaybım var.

sql-server sql-server-2008-r2 memory

— Derek Kromm
kaynak

Hafızanız NUMA düğümü arasında dengeli mi? İşlemcileriniz nasıl? SQL Server günlüğü başlatma sırasında kaç CPU kullanıldığını gösteriyor mu?

— Aaron Bertrand

ETL süreçleri için ne kullanıyorsunuz? SSIS mi yoksa benzer bir araç mı? SQL Server dışındaki bir araçsa, SQL Server örneğinizle aynı sunucuda mı çalıştırıyorsunuz?

— Mike Fal

Bu iyi bir nokta @Mike, SQL Server çok fazla kullandığından, ETL işlemi işini yapmak için yeterli belleği yakalayamazsa, tempdb'ye çalışmak zorunda kalabilir.

— Aaron Bertrand

Tempdb kullanımını izlemek için iyi bir başlangıç: msdn.microsoft.com/en-us/library/ms176029(v=SQL.105).aspx . Bu size neler olduğuna dair bir fikir vermelidir.

— Thomas Stringer

TempDB gerçekten genişlediğinde gerçekten neler olduğunu analiz ettiniz mi? Basit bir sp_who2 / sp_whoisactive? Daha iyi yönetilebilen, ancak söylemesi zor bazı uzun vadeli işlemleriniz var gibi geliyor bana. Şahsen, ben bellek değişikliğine bağlı alamadım ama ilk kod bakmak ve düzgün çalışıp çalışmadığını görmek.

— Mike Fal

Yanıtlar:

Herkese yardımları için teşekkür ederim.

Bazı yürütme planlarını doldurduktan sonra, mevcut RAM miktarına göre farklı şekilde işlenen bir JOIN olduğu ortaya çıkıyor. Daha az RAM ile bir Hash ile değerlendirir; daha fazla RAM ile bir dizi Birleştirme Birleşmeleri kullanır.

Bu yüzden temelde, şu anda yeniden düzenleme yaptığım kötü yazılmış T-SQL'e geldi.

— Derek Kromm
kaynak

Bu oldukça karşı sezgiseldir, çünkü bir karma birleşimi bir bellek yardımı gerektirirken birleştirme gerektirmez. Birleştirme birleştirmesini desteklemek için ek bir sıralama işlemi var mı?

— Martin Smith

Bu sorunun cevabı değil, sadece bir yorumda yorum göndermek istemedim bazı kod. NUMA düğümlerinde zamanlayıcılarınızın ve belleğinizin dengesini görmek için (ayrıca çevrimiçi olarak herhangi bir düğüm görünüp görünmediğini görmek için):

SELECT 
  parent_node_id, 
  [status],
  AVG(current_tasks_count) AS avg_tasks_count, 
  AVG(load_factor) AS avg_load_factor,
  scheduler_count = COUNT(*)
FROM sys.dm_os_schedulers
GROUP BY parent_node_id, [status];

SELECT 
  memory_node_id, 
  name, 
  SUM(single_pages_kb + multi_pages_kb) AS memory_kb
FROM sys.dm_os_memory_clerks
GROUP BY memory_node_id, name;

(SQL Server 2012'de, son SUMolarak SUM(pages_kb)artık ayrı tek ve çok sayfalı ayırıcılar olmadığından olmalıdır.)

— Aaron Bertrand
kaynak