Yeni bir sunucuda daha kötü performans


11

Özel bir sunucudayız (tek dört çekirdekli, 6 GB RAM) ve yeni bir özel sunucuya (2x altı çekirdekli, 32 GB RAM) geçiyoruz. Her ikisi de Windows Server 2008, SQL Server 2008'dir. Yeni sunucudaki performans eski, daha yavaş sunucudan biraz daha kötüdür.

Testte, ASP.NET uygulamamız% 10 - 20 daha yavaş çalışır. İSTATİSTİK IO ve İSTATİSTİK ZAMAN ile ayrı ayrı pahalı sorgular çalıştırmak, yeni sunucuda% 10 - 20 daha uzun süre geçmesini gösterir. SQL Sorgu Profili pahalı sorgularda daha yüksek CPU kullanımı gösterir.

Yeni sunucudaki Görev Yöneticisi, sqlserver.exe dosyasının 22 GB RAM harcadığını gösterir, ancak CPU değerleri her zaman çok düşük kalır.

Tüm istatistikleri, yeniden oluşturulmuş veya yeniden düzenlenmiş dizinleri vb. Güncelledim. Yaptığım test miktarı göz önüne alındığında, yürütme planları bu noktada yeni sunucuda saklanmalıdır. Eksik dizinler varsa (sanmıyorum) eski ve yeni sunucuları eşit olarak etkiler. Yeni, eski verilerin aynı verilerini geri yükledi.

Yeni sunucudaki performansın daha iyi olmasını bekliyordum, ancak daha fazla endişe duymak yük. Eski sunucu yük altında bile daha iyi performans gösteriyorsa, bu yeni, biraz daha kötü olan sunucunun bu yükü alması gerektiğinde ne olur?

Burada başka ne eksik olabilir?

EDIT: MAXDOP 6 olarak ayarlandı.

Eski sunucu aynı fiziksel sürücülerde işletim sistemi, veritabanları ve tempdb'lere (RAID 10) sahiptir. Toplam 4 15k 3 Gb / s 3,5 inç SAS. Yeni sunucunun üç sürücü seti vardır: RAID 1 üzerinde işletim sistemi, RAID 10 üzerinde veritabanı, RAID 5 üzerinde tempdb. Toplam 9 15K 6 Gb / sn 2.5 İnç SAS.

Eski sunucuda 1 x Intel Xeon E5620 2,40 GHz Dört Çekirdekli 8 İş Parçacığı (H / T) bulunur. Yeni sunucuda 2 x Intel Xeon E5-2640 2,5 GHz Altı Çekirdekli 12 İş Parçacığı (H / T).

DÜZENLEME 2: İşte son analiz:

Güç planı dengeli, yüksek performans değil. Geçti.

Tempdb, RAID 10 yerine RAID 5 üzerindeydi. Biri tempdb ve diğeri diğer her şey için fiziksel olarak farklı iki RAID 10 yapılandırması oluşturmak için başka bir HD eklendi.

SQL ile ilgili dosyaları (mdf, ldf, ndf, bak) virüs taramasından hariç tuttu.

Yeni sunucuya taşındıktan sonra tüm dizinleri yeniden oluşturun. Çok yedeklenmişlerdi - muhtemelen yedekleme, kopyalama, geri yükleme sonucunda mı?

İşlemci atlamalarının o kadar büyük olmadığını fark ettim. Sorgular çok daha hızlı yürütülmeyecek, ancak daha fazla işlemci, daha fazla çekirdek, daha fazla RAM ile daha ölçeklenebilir olacağız.


O / S güç planının yanı sıra ilgili BIOS ayarları da olabilir: stackoverflow.com/a/27807572/538763
crokusek

Yanıtlar:


11

Raid 5, özellikle yazma ağır iş yükleri için raid 10'dan daha yavaştır. Bu nedenle, genellikle SQL sunucusu için önerilmez ve kesinlikle tempdb için önerilmez. Bu tek başına performans farkını kolayca açıklayabilir.

Benim önerim tempdb 10 baskınına taşımak olacaktır.


4

Bu çok genel bir sorundur, bu nedenle belirli bir tavsiyede bulunmak zordur. Ancak, bu durumda olsaydım, temellerden başlardım, en pahalı sorguları kontrol ettim. Hangi işlevler daha uzun sürüyor? İstatistik zamanıyla sorguları çalıştırdığınızda çoğu zaman ne tüketir? Odağınızı biraz daralttıktan sonra, eski sunucuyla işleri karşılaştırabilirsiniz. Ayrıca, kontrol edilecek bir şey, her iki sunucunun da aynı yama düzeyinde (SQL ve Windows) olduğundan emin olmaktır.


3

Sabit diskleriniz ve sahip olduğunuz tempdb dosyalarının sayısı hakkında hiçbir şey söylemezsiniz. Tempdbs nr = 32'ye kadar çekirdek sayısının genel bir önerisi vardır, temp dbs'nin eşit şekilde kullanılmasını sağlamak için atma anahtarı da vardır.

Ancak derinlemesine: http://www.sqlskills.com/BLOGS/PAUL/post/A-SQL-Server-DBA-myth-a-day-%281230%29-tempdb-should-always-have-one-data- işlemci başına dosya-çekirdeği.aspx ayrıca taşıma sırasında tablolar ve dizinler için ambalajı değiştirdiniz mi? Yedekleme ve geri yükleme, dizinlerde (kümelenmiş olanlar dahil) varsayılan olarak farklı bir dolguya dönüşebilir

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.