io_stall_writes_ms neden tempdb için bu kadar yüksek?

Aynı disk sürücüsünde kullanıcı ve sistem veri dosyaları var. (İo_stall_write_ms / (1.0 + num_of_writes)) kullanıcı dosyaları için 2'nin altında ancak tempdb dosyaları genellikle 400'ün üzerinde. Birkaç sunucuda görüyorum ve tempdb'e yazmanın daha uzun sürmesinin bir nedeni olup olmadığını merak ediyorum normal bir veritabanı veri dosyasından daha fazla.

SELECT DISTINCT UPPER(LEFT(mf.physical_name, 1)) AS Directory,
( io_stall_write_ms / ( 1.0 + num_of_writes ) ) as result, 
io_stall_write_ms, num_of_writes, 
fs.database_id, 
fs.[file_id]
FROM sys.dm_io_virtual_file_stats(NULL, NULL) AS fs
INNER JOIN sys.master_files AS mf ON fs.database_id = mf.database_id
AND fs.[file_id] = mf.[file_id]

Teşekkür ederim,

Kısa Cevap: Daha yüksek IO tezgahları görmek başlı başına bir sorun olabilir veya olmayabilir. Bir sorununuz varsa suss etmek için daha fazla bilgiye bakmanız gerekir. Biraz yüksek görünüyor, evet, ama acı çekiyor musun? Eğer öyleyse, muhtemelen IO sisteminiz yükü doğru işlemiyorsa (çünkü bir sürücüde her şeye veya başka bir nedenden dolayı her şeye sahip olduğunuz için) ya da TempDB'de çok fazla şey yapıyorsunuz (ilk sorunu değiştirmek - IO performansı - muhtemelen daha kolay ve daha verimli bir çözümdür, ancak önce bir sorununuz olup olmadığını belirleyin)

Daha uzun tartışma / cevap:

Burada iki soru var -

1.) Yüksek IO Tezgahları gördüğümde ne yapmalıyım?

İlk önce, "yüksek" seyirci gözündedir. Eğer 10 DBA'ya IO tezgahları için "çok yüksek" ne olduğunu soracak olsaydınız, muhtemelen onlarla rakamlarla 2-3 farklı cevap alırsınız, 5-6 "Bu bağlıdır" cevaplar ve bir boş bakış. Benim tahminim, özellikle diğer DB'ler ortalama durma süresi için 2 ms veya daha düşük olduğunda, ortalama 400 ms'lik potansiyelin çok yüksek olduğu varsayımımdır.

Hangi veritabanının yüksek tezgahları göreceğinden bağımsız olarak, aynı şekilde yaklaşmalısınız. Bir IO durak, kulağa böyle geliyor ... Beklenenden daha uzun süren bir IO talebi .. Durmak. Bunlar olur. Kaynakların paylaşıldığı ve sınırlı kaynakların (gerçekten tüm sistemlerimiz) olduğu bir sistemde her zaman olurlar. Tezgahlar performans sorunları haline geldiğinde veya onlara yol açtıklarında bir sorun haline gelirler. Burada, izlemenin proaktif bir parçası olarak veya sorun giderme yaptığınız performans sorunlarıyla karşılaştığınıza inanıyorum. Ayrıca sadece IO tezgahlarında kaybolmak istemiyoruz. Büyük resme değil, bulmacanın bir parçasına bakıyoruz. SQL en son yeniden başlatıldığından beri bekleme istatistiklerine veya dosya istatistiklerine bakmak zahmetli olabilir, çünkü her zaman bakıyorsunuz ve bazı bakım penceresi veya ağır yük penceresi sayaçları eğebilir. Bu yüzden tam resme baktığınızdan emin olun.

Ama bir disk performans sorunu var şüpheli veya böyle bir sorguda bir şey görüyorum, normalde aşağıdaki gibi bir işlemi izlerim:

1. Sunucudaki bekleme istatistiklerine bakın. @swasheck , aşağıdaki yanıtta harika bir bağlantıyı yorum olarak paylaştı . Bu, Paul Randal'ın SQL Server'daki bekleme istatistiklerini inceleme ve analiz etme konusundaki mesajına götürür. Oraya git. Ne tür beklemeler görüyorsunuz? Eğer IO performansı (ilgili bekler görüyor musunuz PAGEIOLATCH_*, IO_COMPLETION, WRITELOGvb?). Bunu yaparsanız, tıpkı IO tezgahları gibi IO ile ilgili bazı performans sorunlarınız olduğunu gösteren başka bir göstergedir. Ama burada size başka bir anlaşma şekli veriyor.
2. ES performansına bakın. Özellikle, Physical Disk:Avg Disk Sec/Readve Avg Sec Disk Sec/Writesayacı perfmon içine bakın . Bunlar gecikmenizi ölçer. Bir performans günlük dosyasına kaydedilen bir süre boyunca bu sayaçları izleyin. Ortalamalar için ne gördünüz? 0.020 saniyenin (20 ms) üzerindeki sayıları görüyorsanız, bu bir sorun olabilir. 40-50ms avg veya daha yüksek sayılar görürseniz, sorunun daha kesin bir göstergesidir. Ayrıca sivri uçlarına bak? Ne kadar yükseliyorlar ve ne kadar sürüyorlar? Yüzlerce ms'de ani artışlar görürseniz ve onlarca saniye veya daha uzun süre dayanırlar ve / veya sık sık gerçekleşirse, iş yükünüz için IO performansınızla ilgili bir sorun yaşamanız daha olasıdır.
3. ES kurulumunuza bakın. Bu ne? Yerel diskler? SAN? Depolama Dizisi? Bunun dışında ne tür ve GİB'ler görmelisiniz? Yapmaya çalıştığınız şey için yeterli mi? İş yükünüz için ES'nizin boyutunu küçültmüş olabilirsiniz. Sadece fiziksel iğlerinize, RAID ayarlarınıza vb. Bakmayın. Disklerinize giden yollara bakın. Diğer birçok trafikle paylaştığınız her şeyi 1 GB'lık tek bir bağlantıdan mı geçiriyorsunuz? Disk performansı metriklerine depolama alanının perspektifinden bakabilir misiniz?

( Not: bu bekleme istatistikleri analizi ve perfmon analizi için - çeşitli dönemlere ve kullanım türlerine bakın. Gece gündüz sizden farklı kullanım istatistikleriniz var mı? Toplu işlem pencereleri? Bu dönemlerin her birinde bu araçlara bakın ve her biri için ne gördüğünüzü anlayın)

Burada bir başka ES performans değerlendirmesi -

• Sistem DB'leri ve Kullanıcı DB'lerinin paylaşıldığını söylediniz. Bu üretim mi? Öyleyse, bu her zaman en iyi senaryo değildir. Aynı sürücüdeki günlük dosyasını ve veri dosyalarını mı paylaşıyorsunuz? Bu da en iyi senaryo değil. Bu depolamayı başka neler paylaşıyor? İğler ve baskın grupları ve diskler hakkında endişe duyduğunuz ve en iyi performans gösteren diskleri kimin alacağına karar vermek zorunda olduğunuz bir dünyada, (genel bir genel kural olarak .. DB dünyasında olması çok iyi değil) ama bu gerçek tutma eğilimindedir) benim en hızlı ve en adanmış TempDB (daha fazlası aşağıda), sonra günlük dosyaları, sonra veri dosyaları ile gidin. NetApp, Dell Equal Logic veya EMC VNX vb. Gibi bir cihazda büyük disklerin bulunduğu bir dünyada,

2.) TempDB'nin daha yüksek olmasının bazı nedenleri nelerdir?

Bu yüzden TempDB bir veritabanı ve daha önce tartıştığım gibi diğer herhangi bir veritabanı gibi IO tezgahları olabilir. Ancak TempDB'nin daha yüksek okumalara sahip olmasının bazı nedenleri nelerdir? (ayrıntılı değil, düzenlemelere, diğer cevaplara veya yorumlara eklemeler veya düşünceler hoş geldiniz) -

1. Kodunuz nedeniyle - TempDB kodunuzda kasıtlı olarak mı kullanıyorsunuz? Geçici tablolar ve tablo değişkenleri oluşturuldu ve yok edildi mi? TempDB'de böyle bir çok şey yapıyor musunuz? Bu mutlaka kötü ya da iyi değildir, ancak buna bakabilir ve kasıtlı TempDB kullanım düzeninizi anlayabilirsiniz.
2. TempDB paylaşılan bir çalışma atıdır - TempDB, kullanıcı tanımlı geçici nesneler ve tüm SQL örneğiniz tarafından kullanılan çeşitli çalışma tabloları ve işlemler için geçici bir alan olarak kullanılan bir veritabanıdır. Kaç tane kullanıcı veritabanı var? Genel olarak ne tür bir iş yükü görüyorsunuz? TempDB, her şeyin paylaşılması için bir kaynaktır.
3. Verimsiz sorgular ve yetersiz bellek - Belki de dizinleri yeterince sıkı kullanmayan veya büyük tarama ve sıralama işlemleri yapan sorgular vardır. Büyük karma işlemler ve sunucudaki bellek bunlar için yeterli değil. Bu işlemler, perde arkasında çalışma masası olarak TempDB'ye "dökülecek". Bazen bu, sorgu planlarınıza ve indeksleme veya sorgu ayarlamaya bakarak önlenebilir. Bazen olur (daha çok depo iş yüklerinde, buluyorum). Yeterli belleğiniz varsa, bu yardımcı olabilir, ancak bu sorgular zaman zaman dökülebilir. Şuna da bak.
4. Sisteminizde adil sayıda güncellemeyle Taahhüt Edilen Anlık Görüntü Yalıtım düzeyini mi kullanıyorsunuz? Bu ayrıca TempDB aktivitesinde artışa neden olabilir.

Mesele şu ki - TempDB çok çeşitli şekillerde kullanılıyor ve en yoğun veritabanınız olmasa da en yoğun veritabanınızdan biri olarak görmek beni hiç şaşırtmıyor. Bir müşterinin sitesinde tüm veritabanlarının en yüksek ve en yüksek ortalama duraklarına sahip olduğunu gördüğümde de beni şaşırtmıyor. Bazen iş yükünün doğasıdır. Burada bahsettiğim bazı şeylere bakmak, bu sayıların bir problemi gösterip göstermediğini ve eğer öyleyse, onu çözmede nasıl daha derine ineceğini belirlemenize kesinlikle yardımcı olabilir.

TempDB, örnek üzerindeki tüm veritabanları arasında paylaşılır. Bu nedenle, TempDB içinde bazen belirli sayfalar için çekişme olabilir: SGAM , GAM ve PFS . Özetle, bu sayfalar şu ana kadar TempDB'de nelerin kullanıldığını ve yeni kullanım için alanın nerede bulunduğunu takip ediyor.

Tipik olarak, bu, TempDB'ye birden fazla veri dosyası ekleyerek ele alınır. Doğru sayıya ilişkin birkaç farklı felsefe vardır, ancak hepsi birden fazla olması gerektiğini kabul eder.

İşte çalıştırmak için birkaç sorgu ...

Bu, TempDB'de kaç dosya olduğunu ve nerede bulunduğunu gösterecektir.

-- tempdb layout
use tempdb
go
exec sp_helpfile
go

Bu size kaç CPU ve çekirdeğe sahip olduğunuzu gösterecektir.

-- cores and hyperthreading
select cpu_count, hyperthread_ratio 
from sys.dm_os_sys_info
go

Bu, NUMA düğümü başına kaç NUMA düğümü ve çekirdeği olduğunu gösterecektir.

-- numa nodes and schedulers
select node_id, online_scheduler_count
from sys.dm_os_nodes
order by node_id
go

Bu, hangi sayfaların TempDB'de beklediğini gösterecektir.

-- see if anything is waiting on tempdb
select * 
from sys.dm_os_waiting_tasks
where resource_description like '2:%'
go

İşte sayfa çekişmesi konusunda biraz daha derinlemesine incelenen bir makale .

Tamam, şimdi felsefe kısmı ... :-)

Kendime göre, eğer bir SMP sistemindeysem, toplam çekirdeklerin yarısı kadar dosya istiyorum .

Bir NUMA sistemindeysem, sadece NUMA düğümü başına çekirdek kadar dosya istiyorum .

Ancak, TempDB için dörtten fazla dosyaya sahip olmak için nadiren herhangi bir gelişme görüyorum. Bu yüzden genellikle dört ile başlıyorum ve bağlantılı olduğum makalede açıklandığı gibi çekişmeyi izliyorum.

Sorunları görmeye devam edersem, iki tane daha eklerdim. Tekrar kontrol edin, daha fazlasını ekleyin ve çekişme kaybolana kadar tekrarlayın.