Bir sunucunun gerçekte ne kadar RAM'e ihtiyacı var?

Dünyaya dağıtılmış birkaç sunucum var. 6 GB RAM ile SQL Server 2005 x64 ile Windows 2003 x64 çalıştırıyorlar. Kutular en iyi (veya kabul edilebilir) bir konfigürasyona sahip değil, çünkü onları yıllar önce sipariş eden adam ne yaptığını gerçekten bilmiyordu.

Kutuların belleği sürekli olarak azalıyor, disk belleği dosyası kullanılıyor ve her şey yavaşlıyor. Tipik olarak taahhüt ücreti 5,8 GB'dir ve daha sonra birisinin yoğun bir şey yapması gerektiğinde (örneğin bir rapor çalıştırın), bu sayı çatıdan geçer.

Daha fazla bellek siparişi veren güçleri almaya çalışıyorum, ancak muazzam bir muhalefet alıyorum (örneğin, yazılımı daha performanslı hale getirin, tüm bu sunucular için çok fazla maliyet veya kutunun yeterli belleğe sahip olmadığını kanıtlayın. ..).

Sonunda daha fazla bellek sipariş edebilmemiz için, bir kutunun teknisyenler için sunabileceğim ne kadar RAM'e ihtiyaç duyduğuna dair yönergeler (veya bir formül) var mı?

Kolayca anlatmanın hiçbir yolu yok çünkü tamamen kullanımınıza ve uygulamanıza bağlı. Bir veritabanı sunucusunu maksimize ediyorsunuz ... veritabanı ne kadar büyük? İşlem istatistikleriniz nedir?

Gerçek dünyadaki sınırlamalar senaryonuzda açıktır. Bir süre 6 gig problemsiz koşuyorsunuz, o zaman takas ve dayak var. 6 gig yeterli değil.

Performansın işi etkilemesi için yeterliyse, yüksek up'larınız hafızayı kaldırmaya ihtiyatlı olduğu konusunda yeterince şikayet duymalıdır. Ne zaman harcadığınızı ve sonra sunucuyu "ayarlamak" ve ayar sorunlarını gidermek için ne kadar maliyeti anlayın, sunucuya eklenen bellek bellek maliyeti ve yarım saatten az bir süre için sorunu çok iyi çözebilir kesinti.

Gerçek hayattaki kullanımınıza dağıtıp oradan çalışana kadar tam olarak ne kadar bellek kullanacağınızı bilemezsiniz.

Bununla birlikte, uygulamanızın gerçekten darboğaz olduğunu doğrulamak isteyebilirsiniz. Disk i / o istatistiklerinizi ve ağ işlem hacminizi görmek için Windows performans izleyicisini çalıştırın. Parçalanma seviyenizin ne olduğunu görün ( Google burada iyi bir arkadaştır ). Bir sorgunun büyük ölçüde verimsiz olduğu durumlarda, bariz sorunlar için de kodu denetlemeyi deneyebilirsiniz ( tekrar Google ).

Ama yine de her şey bunun işi ne kadar kötü etkilediğine bağlı. Ayarlamaya yatırım yapmak daha mı değerli, yoksa önce donanımı atmak ve sonra ayarlamayı denemek yeterince kötü mü?

Daha fazla RAM'e ihtiyacınız olup olmadığını görmenin kolay bir yolu Page Life Expectancy perfmon sayacını grafik olarak çizmektir. Bu sayaç, SQL Server'ın verilerin diğer veriler için yer açmadan önce arabellek havuzunda saklanacağını düşündüğü süreyi gösterir. Bu sayıyı olabildiğince yüksek istiyorsun. Yüklü 6 Gig RAM ile (muhtemelen 4 gig'de maks olacak şekilde SQL ayarlamanız gerekir) muhtemelen en fazla birkaç dakika veri depolayacaksınız, birisi büyük bir rapor çalıştırdığında bu sayı tankını göreceksiniz birkaç saniye basın. Ne kadar çok RAM'e sahip olursanız, o kadar uzun veri bellekte tutulabilir ve disklerden daha az okuma yapılması gerekecektir.

Örneğin, şu anda birlikte çalıştığım sistemlerde 256 Gig RAM var ve verileri yaklaşık 12000 saniye bellekte tutuyoruz.

Lütfen bir hedef numaranın çarpmasını istemeyin, sadece sayının mümkün olduğunca yüksek olmasını istersiniz. Sistemleriniz hakkında daha fazla bir şey bilmeden çekim yapmak için iyi bir sayı veremem.

Hmmmm. Büyük bir MSSQL kurulumu için bile 6 konser iyi bir miktar koç. Aslında kodunuzun gerçekten etkili olduğundan emin olmak ve bakmak isteyebilirsiniz. 6 gig işlem biraz alışılmadık ... 1099 yıl sonu işleminde bir konser vermeyen eyalet çapında bordro sistemleri üzerinde çalıştım ... Ve sık sık çalıştırmak için mi? Bilmiyorum. Ne tür verilerle çalışıyorsunuz?

Olduğu söyleniyor, 64 bitlik bir kutuda istediğiniz kadar RAM doldurabilirsiniz ve koç kir ucuzdur, bu yüzden mümkün olduğunca oraya koyabilirsiniz ... Gerçekten çok fazla RAM'iniz olamaz bir veritabanı sunucusu.

Düzenleme: Bu çılgınca artık güncel değil. 256 gig RAM'li MSSQL kutularım var.

Daha fazla bellek (veya başka bir bileşen) satın almak için silahı atlamadan önce, sunucuda bir performans analizi çalıştırmanızı tavsiye ederim. Bunu perfmon kullanarak kendi başınıza yapabilir veya üçüncü taraf araçlarını kullanmaya bakabilirsiniz. Hem işletim sisteminin hem de SQL sunucusunun performansını analiz etmelisiniz. IMHO, çoğu zaman uygun bir analiz yapılmadan önce bir soruna donanım atmaya hazırız. Bu noktada bildiğiniz herkes için bir sorgu, saklı yordam, yürütme planı, disk G / Ç, CPU kullanımı vb. İle ilgili bir sorun olabilir. Bellek basıncı genellikle sistemdeki başka bir darboğazın belirtisi olabilir.

"Satanicpuppy" dediği gibi, çok fazla RAM diye bir şey yok, ama 6GB iyi olmalı, belki sunucunuzun ne yaptığını yeniden düşünmelisiniz, "donanım" probleminiz olduğunu düşünmüyorum, SQL programlamanıza odaklanın ...

Veritabanı sunucuları söz konusu olduğunda "yeterli" bellek diye bir şey yoktur. Tabii ki, aslında ne yaptıklarına ve çalıştırdıklarına bağlıdır, ancak çok fazla veri içeren ve karmaşık sorgular yapan sürekli kullanılan bir veritabanı ise - 6 GB kolayca yetersiz kalabilir.

Bir sıkıntılı sunucuyu en az 32 veya 64 GB'a yükselterek işe başladım ve işe yarayıp yaramadığını görün. Değilse, veritabanı ayarlama, uygulama sorun giderme ve hata ayıklama'ya dönün - bir aptal veritabanını tasarlamadığı sürece, birkaç sunucu sınıfı bellek çubuğundan çok daha fazlasına mal olur (ve bir aptal şeyi tasarlamış olsa bile, belirgin bir tasarım elde eder) korunan destekle düzeltilen hatalar oldukça zor olabilir).

Bununla birlikte, başka birinin belirttiği gibi - disk veya ağ G / Ç performans eksikliği gibi (yazılım tasarım sorunlarının dışında) başka bir şey olabilir - sadece temel SQL performans izlemesinden geçmek için bir DBA profesyonelini işe almak gün yararlı olabilir.

Daha fazla dizin oluşturmaya bakmalısınız. Genel olarak, çoğu insan veritabanını endekslemediğini düşünüyorum.

Bu hala hava kodu, henüz tam olarak test etmedim, ancak sizi doğru yöne götürmeli

http://accessadp.com/2011/08/22/missing-indexes-great-script-for-determining-roi/

Select ‘create index IX_’ +
 sys.objects.name +
 isnull(replace(‘_’ + equality_columns, ‘,’, ‘_’), ”) +
 isnull(replace(‘_’ + inequality_columns, ‘,’, ‘_’), ”) + ‘ on ‘ +
 sys.objects.name +
 ‘(‘ +
 coalesce(equality_columns + ‘,’ + inequality_columns, equality_columns , inequality_columns ) +
 ‘) ‘ +
 isnull(‘ include (‘ + included_columns + ‘)’, ”)
 as CreateIndexSql,
 (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) AS Score,
 sys.schemas.schema_id,
 sys.schemas.name AS schema_name,
 sys.objects.object_id,
 sys.objects.name AS object_name,
 sys.objects.type,
 partitions.Rows, partitions.SizeMB,
 sys.dm_db_missing_index_details.equality_columns,
 sys.dm_db_missing_index_details.inequality_columns,
 sys.dm_db_missing_index_details.included_columns,
 sys.dm_db_missing_index_group_stats.unique_compiles,
 sys.dm_db_missing_index_group_stats.user_seeks, sys.dm_db_missing_index_group_stats.user_scans,
 sys.dm_db_missing_index_group_stats.avg_total_user_cost, sys.dm_db_missing_index_group_stats.avg_user_impact,
 sys.dm_db_missing_index_group_stats.last_user_seek, sys.dm_db_missing_index_group_stats.last_user_scan,
 sys.dm_db_missing_index_group_stats.system_seeks, sys.dm_db_missing_index_group_stats.system_scans,
 sys.dm_db_missing_index_group_stats.avg_total_system_cost, sys.dm_db_missing_index_group_stats.avg_system_impact,
 sys.dm_db_missing_index_group_stats.last_system_seek, sys.dm_db_missing_index_group_stats.last_system_scan
 FROM
 sys.objects
 JOIN (
 SELECT
 object_id, SUM(CASE WHEN index_id BETWEEN 0 AND 1 THEN row_count ELSE 0 END) AS Rows,
 CONVERT(numeric(19,3), CONVERT(numeric(19,3), SUM(in_row_reserved_page_count+lob_reserved_page_count+row_overflow_reserved_page_count))/CONVERT(numeric(19,3), 128)) AS SizeMB
 FROM sys.dm_db_partition_stats
 WHERE sys.dm_db_partition_stats.index_id BETWEEN 0 AND 1 –0=Heap; 1=Clustered; only 1 per table
 GROUP BY object_id
 ) AS partitions ON sys.objects.object_id=partitions.object_id
 JOIN sys.schemas ON sys.objects.schema_id=sys.schemas.schema_id
 JOIN sys.dm_db_missing_index_details ON sys.objects.object_id=sys.dm_db_missing_index_details.object_id
 JOIN sys.dm_db_missing_index_groups ON sys.dm_db_missing_index_details.index_handle=sys.dm_db_missing_index_groups.index_handle
 JOIN sys.dm_db_missing_index_group_stats ON sys.dm_db_missing_index_groups.index_group_handle=sys.dm_db_missing_index_group_stats.group_handle
 WHERE
 sys.dm_db_missing_index_details.database_id=DB_ID()
 AND (CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.user_seeks)+CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.unique_compiles))*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_total_user_cost)*CONVERT(Numeric(19,6), sys.dm_db_missing_index_group_stats.avg_user_impact/100.0) > 100