SQL Server Önbellek Yıkama ve Disk G / Ç

.NET 4.0'da geliştirdiğimiz ve arkada SQL Server 2008 R2 çalıştırdığımız bir OLTP sistemini test etmekle meşgulüz. Sistem, çok performanslı SQL Server Service Broker kuyruklarını kullanıyor, ancak işleme sırasında tuhaf bir trend yaşıyoruz.

SQL Server işlem istekleri 1 dakika boyunca bir kabarcık hızında, ardından ~ 20 saniye arttırılmış disk yazma etkinliği. Aşağıdaki grafik sorunu göstermektedir.

Yellow = Transactions per second
Blue   = Total CPU usage
Red    = Sqlsrv Disk Write Bytes/s
Green  = Sqlsrv Disk Read Bytes/s

Sorun giderme sırasında, kalıpta önemli bir değişiklik yapmadan aşağıdakileri denedik:

• SQL Server Aracısı durduruldu.
• Neredeyse tüm çalışan işlemleri öldürdü (A / V, SSMS, VS, Windows Explorer vb. Yok)
• Diğer tüm veritabanları kaldırıldı.
• Tüm konuşma zamanlayıcıları devre dışı bırakıldı (tetikleyici kullanmıyoruz).
• İleti kuyruğu odaklı bir yaklaşımdan basit / ham bir tablo izleme tasarımına taşındı.
• Hafiften ağırya farklı yükler kullanılır.
• Tüm kilitlenmeler düzeltildi.

SQL Server önbelleğini oluşturuyor ve belirli zaman tabanlı aralıklarla diske yazıyor gibi görünüyor, ancak bu teoriyi desteklemek için çevrimiçi bir şey bulamıyorum.

Sonra, sorunu tekrar edip edemeyeceğimi görmek için çözümü özel test ortamımıza taşımayı planlıyorum. Aradaki herhangi bir yardım çok takdir edilecektir.

Güncelleme 1 İstendiği gibi, burada Kontrol Noktası Sayfaları / Saniye , Sayfa Yaşam Beklentisi ve bazı disk gecikme süresi sayaçlarını içeren bir grafikle .

Gözlemlediğimiz düşük performansın (sarı çizgi) Kontrol Noktası (açık mavi çizgi) gibi görünüyor.

Disk gecikmesi işleme sırasında nispeten tutarlı kalır ve sayfa ömrü beklentisinin gözle görülür bir etkisi yoktur. Ayrıca SQL Server için kullanılabilir olan ram miktarını da ayarladık, bu da büyük bir etkiye sahip değildi. Kurtarma modelini 'den' SIMPLEe değiştirmek FULLde çok az fark yarattı.

Güncelleme 2 "Kurtarma Aralığı" nı aşağıdaki gibi değiştirerek, kontrol noktalarının meydana gelme aralığını azaltmayı başardık:

EXEC sp_configure 'show advanced options',1
GO 

RECONFIGURE
GO

EXEC sp_configure 'recovery interval', '30'
GO

RECONFIGURE 
GO

EXEC sp_configure 'show advanced options',0
GO
RECONFIGURE

Bunun kötü bir uygulama olup olmadığından emin değilim?

Diğerleri zaten suçluyu işaret etti: SQL Server, bellekte (arabellek havuzunda) güncellemeler biriktirir ve yalnızca periyodik olarak (kontrol noktalarında) temizler. Önerilen iki seçenek (-k ve kontrol noktası aralığı) tamamlayıcıdır:

• -k kontrol noktasının daha az agresif G / Ç talepleri üretmesine ve daha uzun süre dayanmasına neden olacaktır
• kurtarma aralığının düşürülmesi kontrol noktasının daha sık başlamasına neden olur

Ama ben sadece şimdiye kadar aldığınız iyi yorumları regurgitate cevap vermedi :)

Gördüğünüz şey maalesef sıraya alınmış işlemenin çok tipik bir davranışıdır . Service Broker kuyruklarını kullanın veya tabloları kuyruk yaklaşımı olarak kullanmayı tercih edin , sistem bu tür davranışlara çok yatkındır. Bunun nedeni, kuyruk tabanlı işlemin yazma ağır olmasının yanı sıra OLTP işlemeden daha fazla yazma ağır olmasıdır. Hem enqueue hem de dequeue ilkelleri yazma işlemidir ve neredeyse hiç okuma işlemi yoktur. Basitçe söylemek gerekirse, kuyruk işleme, diğer iş yükleri, hatta OLTP (yani, TPC-C benzeri iş yükü) ile karşılaştırıldığında en fazla yazıyı (= en kirli sayfalar ve çoğu günlük) üretecektir .

Daha da önemlisi, kuyruk iş yükünün yazma işlemleri bir ekleme / silme desenini izler: eklenen her satır çok hızlı bir şekilde silinir. Bu, kesici uç ağır (ETL) iş yükünün yalnızca ek örüntüsünden ayırmak için önemlidir. Temelde hayalet temizleme görevini tam bir yemekle besliyorsunuz ve kolayca geçebilirsiniz. Bunun ne anlama geldiğini düşünün:

• enqueue bir ekleme, kirli bir sayfa oluşturur
• dequeue bir silme işlemidir, aynı sayfayı tekrar kirletir (şanslı olabilir ve kontrol noktasından önce sayfayı yakalayabilir, böylece çift floştan kaçınır, ancak sadece şanslıysa)
• hayalet temizleme sayfayı temizler ve tekrar kirletir

Evet, işlediğiniz her mesaj için üç farklı G / Ç isteğinde üç kez diske bir sayfa yazabileceğiniz anlamına gelir (en kötü durum). Ayrıca, kontrol noktalarının rastgele IO'sunun gerçekten rasgele olacağı anlamına gelir , çünkü sayfanın yazma noktası iki kontrol noktası arasındaki hareketli kafalar tarafından tekrar ziyaret edilir (birçok OLTP iş yüküyle karşılaştırıldığında, yazmaları bazı 'sıcak noktalar' üzerinde gruplama eğilimi vardır, sıra değil ...).

Bu üç yazma noktanız var, aynı sayfayı tekrar tekrar kirli olarak işaretlemek için yarışıyor . Bu, herhangi bir sayfa bölünmesini dikkate almadan önce, anahtar sırası ekleme nedeniyle hangi kuyruk işlemeye de eğilimli olabilir . Karşılaştırıldığında, 'tipik' OLTP iş yükleri çok daha dengeli bir okuma / yazma oranına sahiptir ve OLTP yazma işlemleri, genellikle güncelleştirmelerle ('durum' değişiklikleri) ve aslan payını alan ekler ile ekler / güncellemeler / silmeler arasında dağıtılır. Kuyruk işleme yazma işlemleri, tanım gereği 50/50 bölünmeyle özel olarak eklenir / silinir.

Bazı sonuçlar şöyle:

• Denetim noktası çok sıcak bir konu haline geldi (artık sizin için sürpriz değil)
• Ağır parçalanma göreceksiniz (aralıklı parçalanma, aralık taramaları yapmayacağınız için çok önemli olmayacaktır, ancak IO verimliliğiniz acı çeker ve hayalet temizlemenin daha fazla çalışması vardır, daha da yavaşlar)
• MDF depolama rasgele IO veriminiz tıkanıklığınız olacak

Benim tavsiyem 3 harfle geliyor: S, S ve D. MDF'nizi hızlı rastgele IO'yu işleyebilecek bir depoya taşıyın. SSD. Paranız varsa Fusion-IO . Ne yazık ki bu daha ucuz RAM ile çözülemeyen semptomlardan biridir ...

Düzenle:

Mark'ın işaret ettiği gibi, bir fiziksel disk tarafından desteklenen iki mantıksal diskiniz var. Belki de en iyi uygulamaları izlemeye çalıştınız ve D: ve C: üzerindeki verileri günlüğe kaydetmeye çalıştınız, ancak ne yazık ki boşuna, C ve D aynı disktir. Kontrol noktaları arasında sıralı işlem hacmi elde edersiniz, ancak kontrol noktası başlar başlamaz disk kafaları hareket etmeye başlar ve günlük işlem hacminiz çöker ve tüm uygulama işlem hacmini düşürür. Veri günlüğünden (ayrı disk) etkilenmeyecek şekilde DB günlüğünü ayırdığınızdan emin olun.