Daha fazla CPU çekirdeği ve daha hızlı diskler


13

Ben her zamanki gibi bir dizi farklı rolü kapsayan küçük bir şirketin parçasıyım. Sonuncusu .NET web uygulamamız için özel bir SQL Server kutusu tedarik ediyor. 32 GB RAM ile çift Xeon E5-2620 (altı çekirdekli) 2.00 GHz CPU yapılandırmasında (toplam 12 çekirdek) alıntı yaptık. Bu, bize bir RAID 1 yapılandırmasında iki adet 2,5 "SAS 300 GB sürücüden (15k RPM) oluşan disk dizisi için sınırlı bir bütçe bıraktı.

Disk kurulumunun SQL Server için en uygun olduğunu biliyorum ve veritabanını, günlük dosyalarını ve tempdb'yi kendi sürücülerine koyabilmemiz için RAID 10 için gerçekten zorlamak istiyorum. Bunu bütçemizle uyumlu hale getirmek için CPU çekirdeği sayısını azaltmayı düşünmeli miyim? ya da çift RAID 1 kurulumunda çekirdeği tutmak ve daha az sürücü kullanmak için daha iyi bir banka alabilir miyim?

İşte bazı ek istatistikler

  • SQL Server veritabanı, büyük olasılıkla sırasıyla% 80'e karşı% 20'ye kadar çok sayıda yazma okumasına doğru eğimlidir. Mevcut DB boyutu şu anda 10 GB 26 GB civarındadır ve ayda 250 MB oranında büyür.

  • Şu anda SQL Server 2008 R2 Standard üzerinde, web sunucusuyla paylaşılan tek bir dört çekirdekli Xeon kutusunda (12 GB Ram, RAID 1'de 2 x 10k 300GB SAS sürücüler) çalışarak SQL Server 2012 Standard'a geçmek istiyoruz.

  • Veritabanı atılan bazı arka plan zamanlama görevleri ile yaklaşık 100-150 eşzamanlı kullanıcılara hizmet vermektedir. Bunu okurken, 12 çekirdeğin ciddi bir overkill olduğunu düşünüyorum!


Tüm uygulamayı bir SQL Azure DB'ye bağlı bir Azure bulut hizmetine (2 küçük örnek) dağıttım. Test sırasında performans makul olmasına rağmen (neredeyse sıfır yük) Çok fazla okuduğum öngörülemezlik nedeniyle üretimde kullanmak için cesaretimi kaybettim. Ölçeklendirme yaklaşımıyla daha iyi çalışabilir, ancak sadece 10 GB'lik bir veritabanı ile muhtemelen şu anda ölçeklendirmekten ve biraz para biriktirmekten kurtulabilirim.

Başlangıçta lisans maliyetlerini göz ardı ettim ve SQL Server 2012 lisanslamanın çekirdek sayısına dayandığını fark etmedim. Ben bir SQL Server 2012 Standard lisansı ile bir BizSpark MSDN aboneliği var, bu yüzden bu kutunun dışında kaç çekirdek kullanacağını okumak gerekir.


7
10GB? Daha hızlı diskler size çok yardımcı olmaz. Tüm verileriniz neredeyse her zaman bellekte olmalıdır ... RAID 10'un size ne kadar maliyeti olacak? SQL Server'ın hangi sürümü / sürümü? Yazılım lisansının donanım maliyetinin kolayca 10-20x olacağını sanıyorum.
Aaron Bertrand

2
Genel olarak benim tavsiyem RAM'i önce IO ve ardından CPU'ya tercih etmektir. Yazma yoğun iş yükleri iyi G / Ç gerektirir, ancak bütçeniz için en önemli husus CPU'ların ek lisans maliyetleri gerektirmesidir. Bu yönü düşündünüz mü?
Remus Rusanu

4
SSD satın almayı düşünün. Üzgünüz, ancak 15 bin SAS fiyatı SSD'yi daha iyi bir teklif haline getiriyor. Aslında, şimdi benzer bir yerdeyim ve 300G 10k Velciraptor'ları 450G 10k SAS sürücüler ve 500G SSD (aynalı) ile değiştiriyorum. 15k SAS disklerin fiyatı / avantajı beni rahatsız ediyor.
TomTom

4
@TomTom kabul etti. 15K SAS, 1972 Datsun için yakıt katkısı gibidir - evet biraz daha iyi olacak, ancak fark göz ardı edilebilir ve SSD'nin ekstra maliyeti buna değecektir.
Aaron Bertrand

Yanıtlar:


10

Mütevazi olan deneyimlerden bahsetmişken paylaşmaya değer olduğunu düşünüyorum, SQL veritabanları (Sybase ve SQL sunucusu burada) ile büyük darboğaz depolama.

Ancak bence birisi yanlış varsayımlar yapmadan önce kurulumlarını ilk kez değerlendirmek adil olur. Benim durumumda, CPU kullanımı yakın zamanda CPU'yu yükseltmeyi haklı gösterecek kadar yükselmedi. Bunun yerine, tek bir sürücüden RAID 1'e ve ardından RAID 10 + 'ya 8GB'dan 16GB RAM'e kadar bir çarpıma yükselttim.

Tüm bu RAID yükseltmeleri önceki bekleme sürelerini 2 ila 6 kat azaltmaya yardımcı oldu. SSD'lere yükseltmenin daha da iyi olacağını düşünüyorum. Bunu düşünürseniz, hepsi (teorik) bant genişliğine indirgenebilir. [(RAM Hızı + RAM Boyutu + Bellek denetleyicisi) CPU'ya bağlantınız] combo'nuz, verilerinizin her zaman önbelleğe alınması gerektiğinde okuma işlemlerinde en önemli faktör olacak bir bant genişliği sınırına sahiptir, özel (RAID) depolama alanınızın bir bant genişliği sınırı vardır ( önbellek kaçırıldığında okumaları etkiler ve kızarma sırasında yazarken veya birçok müşteride bir sürü veri yazarken).

Tüm bu limitleri olabildiğince normalleştirin (kaynakları boşa harcamazsınız şekilde yaklaştırın) ve mümkün olduğu kadar yükseltin (gerektiğinde yükseltin ve yalnızca gerekirse, sistem kazanırsa kaynakların boşa harcanmasına izin vermeyin ' t Bunları kullanamazsınız çünkü başka bir darboğaz yolundadır). Sonunda, en kötü darboğazınız, özel yapılandırmanızda en az performans gösteren (en az bant genişliğine sahip) sunucu alt sistemi olacaktır.

Ayrıca yükseltme işlemi sırasında veritabanı dosyaları ve veritabanı günlük dosyaları için ayrı RAID yapılandırmaları oluşturduğumu da ekleyebilirim. Bunun nedeni, veritabanı günlük dosyalarının yazma yoğun olma eğilimindedir. Bir veritabanını bir kilitlenmeden kurtarmak için bir günlük dosyası kullanılır ve veritabanı dosyasına herhangi bir veri yazılmadan önce işlem yapılırken her zaman derhal yazılır.

Bir günlük dosyası bazı veritabanı çoğaltma sunucuları tarafından da kullanılır, ancak çoğaltmanın çoğu anında yapılmaz, bu nedenle okuma performansı etkisi burada minimumdur. En azından öyle düşünüyorum. Bu yükseltmeyi tekrar yaparken minimum kıyaslama yaptım, CPU'larını yükseltmeyi düşünmeden önce herkesin farklı yapılandırmalarını karşılaştırmasını ve önce depolamasını, ardından RAM ve ağ bağlantısını yükseltmesini öneriyorum.

5'ten fazla sunucuda daha kapsamlı yükseltmelerden sonra, deneyimimi paylaşmak için geri geldim. Kesinlikle ilk önce depolama alanı, daha sonra RAM ve daha sonra CPU'yu savunuyorum. Nedeni, sistemdeki depolama, RAM ve CPU arasındaki bant genişliklerinin en düşükten en yükseğe sıralanmasıdır. Bu yüzden bir grup sunucuyu RAID10 ve çift RAID1'den SSD'lere yükselttim.

Maliyet endişeleri nedeniyle yaptığım şekilde (yükseltmek için 20 sunucum daha var) veritabanı verilerini ve nesne dosyalarını bir SSD'ye (evet, RAID0'da yalnızca bir SSD) taşımak ve işlem günlüğü artı tempdb'yi 4xHDD RAID10'a taşımak yapılandırması. SSD'deki tempdb ile de harika sonuçlarla test ettim (aslında bazen 15 kattan daha hızlı sorgularla çok güzel sonuçlar, geçmişte dakikalar yerine birkaç saniye süren bazı raporlar sağladım), ancak daha sonra tempdb'i disk RAID10'a taşıdım çünkü SSD için yoğun yazma aşınma endişeleri.

Şimdi temelde en uzun sorguların her biri için 10-15 kat daha hızlı yanıt süreleri gözlemledim. SSD, verileri RAM'e hızlı okumak için mükemmeldir, çünkü SQL Server talep edilene kadar RAM'e veri getirmez ve elbette verilerin CPU tarafından işlenmesi için önce RAM'e yüklenmesi gerekir (daha sonra L1, L2, L3 önbelleğinde) SSD'ler bu ilk bekleme süresini büyük bir faktör kadar azaltmaya yardımcı olur. Ve SSD'ler ayrıca değiştirme sürelerini azaltmaya yardımcı olur ... RAM'in temizlenmesi ve özellikle veri tabanınız RAM'e sığmayacak kadar büyükse yeni verilerin yüklenmesi.

Sonuçta, sunucuların çalışmasına izin vermek için bir tür yavaş geçiş sürecinde birkaç ay boyunca çok memnunuz ve çalışıyoruz, böylece tüm sunucularımı bu yapılandırmaya geçirmeden önce aşınma düzeyinde bilgi toplayabiliyorum. Ve bu sadece SQL Server Express! : D - SSD'lerinizin sürekli IOPS sağlayabildiğinden emin olun, çünkü bu büyük bir fark yaratan başka bir şeydir (sadece google it). Bu yüzden Intel DC (DataCenter) serisi SSD'leri seçtim.


0

Muhtemelen ilk bölümde aradığınız cevap değil, ama: onu buluta itmeyi düşündünüz mü? AWS, yukarıdaki ihtiyaçların çoğunu sağlamanıza ve donanımla uğraşmak zorunda kalmadan satın alma gücünüzü uzatmanıza izin verebilir.

İkinci bölüm - Donanım gerçekten görevlere bağlıdır. Özel CLR entegrasyonu yapabildiğimde daha fazla CPU'ya yöneliyorum, çünkü o zaman problemlere gerçekten paralel çözümler için optimize edebilirim. Çoğu zaman, tabanlı çözümlere sahip olmak daha iyi olursa, RAM ve sabit disk hızının en büyük darboğaz olduğunu ve ikincisinin sizin durumunuz olduğunu düşünüyorum. (Yukarıdaki SSD fikrinin yararlı olacağı yerler)

Sunucunuzdan herhangi bir gerçek istatistik olmadan, yazma işlemlerini düşürmek için bazı önbellek çözümlerine bakmanızı öneririm (yazmalarla bir tür günlük kaydı yapmıyorsanız veya bir tarihe ihtiyaç duyan şeyler) ve sabit sürücülerinize çok daha fazla para koyarsanız CPU'lardan daha. SQL Server, sorgulara paralel gitme konusunda oldukça iyidir (eğer onlar için yazıldıysa), ancak yazımlarda ağırysanız, sabit sürücünüz gerçek darboğazdır.


1
Adamım, bunun MALİYETİNE hiç baktın mı? 7/24 koştuğunuzda pıhtılaşma için saatlik oranlar delilik. Büyük veri toplama ve indirme bant genişliği delilik. 50gb veriyi veritabanına girip veritabanından çıkarmanız gerektiğinde karşılaştırılabilir bir bağlantıya sahip olmak için 1gbit - hatta 10gbit konuşmamak - maliyetleri deliliktir. Eğer (a) veritabanını yerelden KULLANMAYINIZ - yani bulutta kalırsa veya (b) küçükse bulut tamamen güzel ve züppe olur.
TomTom

Evet, genel bulut yolunda ilerledim, aslında çok aşağı iniyorum! Performans vasat, beklediğiniz gibi .. ama maliyet için benim için salıncak değil. Ben genişleme kalıpları geliştirmek için hepim ama Colo ucuz ve popüler bulut satıcılarından herhangi birine yakın olmak için bir ton para harcamanız gerekir. Altyapıyı soyutladığından emin olun, ancak donanım bakım maliyetlerini eklediğinizde bile zor bir satış olmaya devam ediyor.
QFDev
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.