Kesici uç performansı yük altında artar: Neden?

Son derece denormalize tablolara ekler gerçekleştiren bir kod parçası var. Tablolarda ~ 100 ila 300+ arasında değişen sütun sayısı vardır. Bu, Windows Server 2008 üzerinde çalışan SQL Server 2008 R2'dir.

Her ek, aynı işlem altındaki birkaç tabloya ekleme işleminden oluşur. Bazı ekler NHibernate tarafından toplu işlenir, ancak bazıları olamaz, ancak yine de hepsi aynı işlem altındadır.

Ekleme yapan bir kod parçasını art arda çağırarak ekler 500 kez gerçekleştirdiğimde ortalama ~ 360 ms alıyorum.

Garip bit, aynı anda 4 işlemleri (Windows Server 2008 altında 4 farklı komut istemlerinden aynı exe çalıştırmak) kullanarak test kodu çalıştırdığınızda, arama başına ekleme performansı çok daha iyi olur. 90 ms kadar hızlı giden patlamalar görüyorum (neredeyse X4 daha hızlı). Koddan ekleme süresini ölçüyorum.

4 süreç birbirleri hakkında hiçbir şey bilmediğinden, bunun SQL Server ile ilgisi olduğunu varsayıyorum, ama kesinlikle hiçbir ipucu var. Bunun neden olduğunu ve uçlar o kadar sık ​​olmadığında aynı performansı almama izin verecek herhangi bir yapılandırma olup olmadığını bilmek istiyorum.

Db düzeyinde neler olup bittiğini anlamak için SQL Server izleme yöntemleri ile ilgili öneriler eşit derecede hoş geldiniz.

Olası bir neden, dört eşzamanlı işlemin daha uygun bir günlük yıkaması deseni oluşturmasıdır - tipik olarak her günlük yıkamasının tek bir yürütme işleminde olduğundan daha fazla veri yazması anlamına gelir.

İşlem günlüğü çıktısı / yıkama boyutunun bir faktör olup olmadığını belirlemek için şunları izleyin:

• sys.dm_os_wait_stats için WRITELOGve LOGBUFFERbekler
• ES performansı için sys.dm_io_pending_io_requests
• Performans İzleyicisi sayaçları (veya sys.dm_os_performance_counters ):
  • Günlük Bayt Boşaltılan / sn
  • Günlük Yıkamalar / sn
  • Log Flush Bekleme Süresi

Dahili sınırlara ulaşılıp ulaşılmadığına bakın. SQL Server 2008 R2'de 64 bitlik sürümlerde (32 bitte yalnızca 8) veritabanı başına maksimum 32 olağanüstü (eşzamansız) günlük yıkama G / Ç'si olabilir. 3840KB'nin olağanüstü IO'larında da toplam bir boyut sınırı var.

Daha fazla bilgi ve daha fazla okuma:

• İşlem Günlüğü İzleme
• Düzeltme İşlem Kaydı Yağ
• İşlem Günlüğü Performans Sorunlarını ve Günlük Yöneticisinin Sınırlarını Tanılama
• İşlem Günlüğünü Optimize Etme

@PaulWhite'ın söylediği her şey, artı ...

Yerinde yabancı anahtarlarınız varsa, her ekleme, başvurulan her tabloda bir denetim yapılmasını gerektirir. Bana senin gibi geliyor, bana sadece 360ms geliyorsun, ki bu bana yavaş geliyor.

Her neyse, bu tabloları kontrol etmek, bu verileri diske yüklemek yerine RAM'de zaten bulundurmakla büyük ölçüde yardımcı olur.

Verileri RAM'e yüklemek, yürütmenizin önemli bir parçası gibi ve sadece bir kez olması gerektiği gibi geliyor.

Aynı zamanda etkili bir plan önbelleklemesi olabilir ve sorgularınızın ilk kez derlenmesi gerekir, sonraki çağrılar bu aşamadan kaçınabilir.

bazı sunucular / cpus / os'lar kalıpları hatırlar. önbellek gibi.

Aynı şeyi 4 kez yaptığınızdan eminim, köşeleri kesmenin yolları vardır, Tahmin ettiğim şey, bunu ilk yaptığınız yol, uzun bir süreç (örnek1) olarak düşünüyor, ancak ikinci şekilde yeniden kullanılan kodu görür ve önbellek (örnek2) gibi çalıştırır veya ilk işlem (ram örnek3) içine sığacak kadar büyük olabilir.

örnek1: 0111110000110111110000111011111000011110111110000

örnek2: 0111110000 | 11 | 0111110000 | 111 | 0111110000 | 1111 | 0111110000

örnek3: 0111110000011111000001111100000111110000 örnek3: döngü: 0111110000

Ubuntu sunucusunun tekrarlanan mysql sorguları ile bunu yaptığını biliyorum. Onları önbellekte kaydedebilirim, ancak zamandaki tek fark 10-40 mm olsa da topar. Okuldayken daha hızlı olmak için bu önbelleği kullanmak için programlar (perl / php) yapmanız gerektiğini gösteren sınıflar vardı.

Ancak, programa, hangi dilde, ne içinde derlendiğine veya nasıl programlandığına bağlı olabilir.