... ne yapmamız gerektiğini kabaca tahmin etmeyi umuyordum.
Sorgularınız ve veri boyutlarınız hakkında daha fazla bilgi olmadan, doğru bir tahmin vermeksizin size her türlü tahmini vermek gerçekten zordur.
Veritabanı: sql server 2008 r2 kurumsal veritabanı
Windows: Windows 2008 r2 Enterprise 64 bit, kesinlikle VMware üzerinde çalışıyor.
İşlemci: Intel (R) Xeon (R) CPU E7-4860 @ 2.27GHz 2.26 GHz (2 işlemci)
Kurulu bellek: 4GB
İki işlemci (bunun VM'de 2 çekirdeğe maruz kaldığını varsayıyorum) yetersiz olabilir veya olmayabilir. Bir VM'ye atanan çekirdeklerin doğrudan fiziksel çekirdeklerle eşleştirilmesi gerekmez (veya gerektiğinde tek bir çekirdeğin% 100'ünün kullanılmasına bile izin verilmez!), Bu yüzden bunun bellekten daha esnek bir kaynak olduğunu görebilirsiniz. İş yükünüz veya donanım / sanallaştırma yapılandırmanız hakkında daha fazla bilgi olmadan, bunu 4'e yükseltmenin güzel olacağını söyleyebilirim.
Bellek ayırma. Ah oğlum. Bu, iş yükü için büyük ölçüde yetersizdir. Windows'un kendisinin mutlu olması için en az 2-3 GB olması gerekir ve kutuda BIDS çalıştıran 2 kullanıcının her biri için en az 500 MB gerekir. Ve bununla birlikte, kutu zaten maksimize edildi ve veritabanının ne kadar ihtiyacı olacağını anlamaya bile başlamadım .
Kullanıcıların çoğu asp.net web sitesi ve Rapor sunucusu web sitesi aracılığıyla veritabanıyla etkileşime girer.
Söylemediniz, ancak bunlar aynı kutuda çalışıyorsa, onlar için bellek gereksinimlerinin de dikkate alınması gerekir.
Son olarak, sunucuda da çalışan SSIS paketleri yoluyla günde 3 milyon kayıt getiren oldukça ilgili bir veri ambarı operasyonumuz var.
Bunun, sistemde canlı kullanıcı olmadığında gece çalıştığını varsayarsak, çalıştırılması çok uzun sürmediği sürece bunu bir sorun olarak görmüyorum. Şeylerin bu kısmı endişelerinizin en azıdır; canlı kullanıcılar daha önemlidir.
Daha fazla sorgu optimizasyonu gerçekleştirmek için ihtiyaç duyduğumuz ortak yanıtla önceki ek bellek taleplerimiz reddedildi.
Yukarıda gösterdiğim gibi, sağlanan mevcut bellek miktarı tamamen yetersizdir. Aynı zamanda, spektrumun diğer ucunda, tüm veritabanını bir kerede bellekte tutabilmek için yeterli miktarda bellek elde edebilmeniz pek olası değildir .
Böyle bir battaniye yanıtı alsanız bile (bu arada, muhtemelen gerçek kaynak kullanımının kendisi değil, ek kaynaklar için gerekçenizin ne kadar ikna edici olduğu ile daha fazla ilgisi vardı ), büyük olasılıkla veritabanının verimliliği olabilir gelişmiş. Ancak, şu anda yaşadığınız sorunları çözebilecek tek bir ayar yoktur; bunun önerisi benim için tam bir başlangıç değil.
Şu anda sağlanan bellek miktarının gereken minimum değerin (ASAP düzeltilmesi gerekir) altında olduğu genel yaklaşımı benimserim ve verimliliğini artırmak için iyileştirmeler yapılırken kullanıcı deneyimini kullanılabilir bir düzeye getirmek için ek kaynaklar gerekebilir . sistemleri.
İşte birkaç düşünce (saldırı sırasına göre):
Daha fazla kaynak sağladığınızda performansın ne kadar arttığını kanıtlayabiliyorsanız kazanırsınız . Mümkünse web sitesi yanıt süreleri de dahil olmak üzere Performans İzleyicisi günlüğünü (not: günlüğü bölümü çok önemlidir) kullanarak performans metriklerini takip edin . Bunu yaparken başlayın artık başka bir şey yapmadan önce,. Sonunda minimum bellek miktarına ulaştığınızda (hemen 32 GB almayacaksınız), aniden eklenen belleğin bir şeyleri geliştirdiğine dair kanıtlarınız var ... bu da daha fazlasını eklemenin muhtemelen yardımcı olacağı anlamına geliyor ! Geçerli yapılandırmada bir taban çizgisi toplamazsanız, işler önerilen minimum düzeye yükseltildiğinde tekneyi kaçıracaksınız.
Sunucunuzun bekleme istatistiklerini analiz edin . Bu size sistemdeki en büyük darboğazın ne olduğunu söyleyecektir. Muhtemelen PAGEIOLATCH_XXen yaygın / en yüksek bekleme süresine sahip olacaksınız , bu da sayfaları diskten almak için çok fazla G / Ç yapıldığını gösterir. Bu, bellek ekleyerek hafifletilebilir, böylece gerekli veriler zaten bellekte olduğundan fiziksel G / Ç'ler daha az sıklıkta olur. Bu analiz neredeyse vazgeçilmez bir sonuç olsa da, bu istatistikleri toplamış olmanız, kaynak ihtiyacını haklı çıkarırken size daha fazla cephane sağlar.
Yukarıda bahsettiğim gibi, bellek için minimum minimum gereksinim karşılanmıyor. Çalıştırdığınız tüm yazılımlar için önerilen donanım gereksinimlerini toplayın ve belki de Görev Yöneticisi'nin ekran görüntülerini alın. Bu tek başına yerinde en az 4-8 GB daha fazla haklı çıkarmak için yeterli olmalıdır. Yine de reddediyorlarsa, onları bir hafta boyunca denemenize izin vermeye ikna etmeye çalışın ve bundan sonra geri verin (performans istatistiklerini topluyorsunuz, bu yüzden geri vermenize gerek yok çünkü hafta ortası ' durumu ne kadar iyileştirdiğini kanıtlayabilecektir). Eğer hala reddediyorlarsa, başarısız olmak için kuruluyorsunuz; URLT .
İş yükünün bir kısmını boşaltabiliyorsanız (özellikle, mümkünse uzak durmaktan kaçının), bu, veritabanı için kullanılabilir bellek miktarını artıracaktır, bu da daha kritiktir.
Veritabanının tamamını bir kerede belleğe sığdıramazsınız, bu da bellekte fazla çalışmayı önlemek için SQL Server'ın maksimum bellek ayarını çok dikkatli bir şekilde ayarlamanız gerekir , bu da performansı başka hiçbir şey gibi öldürmez . Aşırı taahhüt aslında tüm verileri hafızaya sığdırmamaktan bile daha kötüdür . Şu anda bu senaryoda olmanız büyük olasılıkla sadece kullanılabilir bellek olmadığı için ve maksimum bellek ayarının varsayılan (sınırsız) olarak ayarlanmış olması muhtemeldir.
SQL Server Enterprise Edition çalıştırdığınız ve bellek çok önemli olduğu için, veri sıkıştırmayı uygulamayı kesinlikle öneririm . Bu, bellekte yer tasarrufu sağlamak için CPU kullanımındaki bir artışı değiştirecektir (ve dolayısıyla nispeten yavaş olan disk erişimlerinin azalması).
Veritabanını ayarlayın. Yapıların ve sorguların, dizin oluşturma ve erişim kalıplarına göre iyileştirmeler kullanması muhtemeldir. Ayrıca, çok fazla veri sık sık taranıp toplanıyorsa, dizinlenmiş görünümler, özet tablolar veya önceden hesaplanmış raporlar oluşturmak çok yararlı olabilir.
Bu daha uzun bir donanım olabilir, çünkü muhtemelen daha fazla donanım sağlama anlamına gelir, ancak bir önbellekleme çözümü uygulayın. En hızlı sorgu hiç yapmadığınız sorudur .
Bunlar sadece birkaç fikir. Sonuç olarak, tek başına ayarlama, buradaki sorunları çözmeyecek veya tek başına donanım yapmayacak, ancak ikincisi muhtemelen mevcut sorunların çoğunu hafifletecektir. Gerçekten böyle gider: yangını söndürmek için kısa vadede donanıma donanım atmak ve kök nedenini en iyi şekilde düzeltmek için uzun vadede problemi ayarlamayı atın.