Performans · SQL Server · Sorun Giderme

Baskı Altındaki TempDB: Tahmin Etmeden Contention Teşhisi

3 dk okuma

TempDB, SQL Server instance üzerindeki tüm veritabanları tarafından paylaşılır. Bu nedenle birbirinden bağımsız problemlerin buluşma noktası haline gelebilir. Dosya eklemek allocation contention türlerinden birini çözebilir; fakat spilling query, kontrolsüz version store büyümesi veya yavaş storage sorununu düzeltmez. Güvenli başlangıç noktası problemi sınıflandırmaktır.

[company_article_image src=”articles/tempdb-contention.svg” alt=”İş yüklerini TempDB iç baskısı ve ölçülebilir kanıtlarla ilişkilendiren teşhis modeli” caption=”Farklı TempDB baskı yolları farklı kanıt ve düzeltme gerektirir.”]

TempDB’nin ne yaptığını belirleyin

TempDB temporary table, table variable, worktable, sort, hash, row versioning, online operasyonlar ve internal engine görevlerini destekler. Toplam dosya boyutunu neden kabul etmek yerine olay sırasında hangi tüketicinin büyüdüğünü ölçün.

SELECT SUM(user_object_reserved_page_count) * 8.0 / 1024 AS user_objects_mb,
       SUM(internal_object_reserved_page_count) * 8.0 / 1024 AS internal_objects_mb,
       SUM(version_store_reserved_page_count) * 8.0 / 1024 AS version_store_mb,
       SUM(unallocated_extent_page_count) * 8.0 / 1024 AS free_space_mb
FROM tempdb.sys.dm_db_file_space_usage;

Yalnızca wait adına değil wait resource değerine bakın

PAGELATCH_* fiziksel disk gecikmesi değil, bellekteki page latch beklemesidir. Beklenen page resource değerini inceleyin. Allocation sayfalarında tekrarlanan baskı allocation contention gösterebilir; başka page ID değerleri metadata veya belirli bir objeyi işaret edebilir. PAGEIOLATCH_* ise data-file I/O ile ilişkilidir ve file latency kanıtı gerektirir.

Session tüketimini bulun

SELECT s.session_id,
       (s.user_objects_alloc_page_count - s.user_objects_dealloc_page_count) * 8.0 / 1024 AS user_mb,
       (s.internal_objects_alloc_page_count - s.internal_objects_dealloc_page_count) * 8.0 / 1024 AS internal_mb
FROM sys.dm_db_session_space_usage AS s
ORDER BY internal_mb DESC, user_mb DESC;

Büyük tüketicileri active request, execution plan ve memory grant değerleriyle ilişkilendirin. Sort ve hash spill; hatalı cardinality estimate, yetersiz grant veya aşırı concurrency göstergesi olabilir.

Version store retention kontrolü yapın

RCSI, snapshot isolation ve bazı engine özellikleri row version tutar. Uzun süren transaction cleanup işlemini engelleyebilir. Uygulamanın ihtiyaç duyduğu isolation modelini kapatmadan önce active snapshot transaction ve transaction yaşını belirleyin.

Konfigürasyonu ölçerek değiştirin

  • Eşit boyutta ve eşit growth ayarlı data file kullanın.
  • Ölçülen peak ihtiyaca göre pre-size yapın ve filesystem headroom bırakın.
  • Küçük percentage growth yerine kontrollü sabit artış kullanın.
  • Allocation contention kanıtlandıysa dosyaları kademeli artırın.
  • Data ve log latency değerlerini ayrı ölçün.

Aynı workload penceresini tekrar çalıştırıp latch wait, spill, file latency, growth event ve uygulama response time değerlerini karşılaştırın. TempDB tuning, baskıyı başka yere taşımadan ilk kullanıcı belirtisini iyileştirdiğinde tamamlanır.

İlgili Makaleler