Örneğimin iyi performans göstermesini sağlamak için neden periyodik olarak yeniden başlatılmaları gerekiyor?

SQL 2005'te bir üretim DB sunucumuz var. Her şey bir süre normal çalışıyor, ancak birkaç hafta sonra kayda değer bir performans düşüşü görüyoruz. Yalnızca SQL Server'ı yeniden başlatmak performansı normale döndürür.

Bazı arka plan:

• 1200'den fazla veritabanı çalıştırılıyor (çoğunlukla tek kiracı, bazıları çok kiracı). Biri sadece çok kiracıya geçme dersi vermeden önce, bu yapıyı korumak için geçerli sebepler var.
• RAM 16 GB'dir. Yeniden başlattıktan sonra, SQL Server'ın 15 GB kullanımına geri dönmesi çok uzun sürmüyor.
• Aktif DB bağlantıları yaklaşık 80 bağlantıdır - işlem başına web sunucusu başına bir bağlantı havuzu olduğu düşünülürse oldukça sağlıklıdır - bu nedenle bağlantı sızıntısı sorunumuz yoktur.

Yoğun olmayan zamanlarda birkaç şey denedik: - Veri önbelleğini temizlemek için DBCC DROPCLEANBUFFERS (CHECKPOINT ile) çalıştırın. Etkisi yoktur ve RAM kullanımının hiçbirini temizlemez). - Sorgu planlarını ve depolanan proc önbelleğini temizlemek için FREEPROCCACHE ve FREESYSTEMCACHE uygulamasını çalıştırın. Etkisi yok.

Açıkçası, SQL Server'ı yeniden başlatmak aktif bir üretim ortamında ideal değildir. Bir şeyleri özlüyoruz. Bundan başka biri geçiyor mu?

GÜNCELLEME: Nisan-28-2012 Hala bu problemle mücadele. Ben sadece işletim sistemi ile herhangi bir çekişme ekarte etmek için, SQL Server için belleği 10 GB'a düşürdüm. Daraltmaya daha da yaklaşıyorum, ancak bir sonraki adımda yardıma ihtiyacım var.

İşte bulduklarım, SQL Server'ı yeniden başlattıktan sonra sayfa dosyası 12.3 GB ile 12.5 GB arasında değişiyor. Günlerce böyle kalacak. Toplam sunucu iş parçacığı 850 ile 930 arasında takılacak - ayrıca günler boyunca sabit ve tutarlı (sqlserver sürekli olarak 55 ve 85 arasında trafiğe bağlı olanlar arasında).

Sonra, "bir olay" var. Etkinliğin ne olduğu hakkında hiçbir fikrim yok, günlüklerde göremiyorum ve haftanın günü veya saatinin gerçekleştiği tarihte tutarlı bir şey göremiyorum, ancak o ani sayfa dosyasının tamamı 14.1 veya 14.2'ye atlıyor GB ve dişliler 1750 ve 1785 arasında atlar.

Bu gerçekleştiğinde perfom kontrolü, bu ipliklerin 900'den fazlası sqlserver'dır. Bu yüzden bu konuların nereden geldiğini görmek için sp_who2'ye gidiyorum ... ve kullanılmış 80 ya da öylesine db bağlantıları var.

Peki .... kimse bu 900 ipliğin SQL sunucusundaki yerini ve ne yaptıklarını nasıl bulabileceğime dair bir fikri var mı?

GÜNCELLEME: Haziran-01-2012 Hala konuyla mücadele. Bunu hala okuyanlar için, yukarı zıplayan konu ile ilgili sorun çözüldü. Bunun nedeni otomatik olarak güncellenen ComVault yedekleme yazılımıdır. Sadece mevcut veritabanlarını yedeklemek yerine, artık orada olmayan (önceki veritabanlarının bir listesini tutuyordu) veritabanlarını yedeklemeye çalışan bir iş parçacığı oluşturuyordu.

Ancak - sorun hala devam ediyor ve her hafta yeniden başlamamız, birkaç gün vermemiz veya almamız gerekiyor. Işık tutabileceklerini görmek için Rackspace ekibiyle birlikte çalışmak.

Her şeyin yolunda olduğunu söylüyorsunuz, ardından birkaç hafta sonra performans düşüyor. (Genellikle, insanlar performansın hızlı bir şekilde veya belirli zamanlarda veya görünüşte rastgele aralıklarla düştüğünü iddia ederler. Bu kötü G / Ç performansı anlamına gelebilir veya kötü zamanlarda çalışan fırtınaları veya yoğun işlemci gerektiren sorguları ya da ağır programlanmış bir işi ya da eksikliği CPU yoğun sorgulamalar veya disk okur ya da diğer şeyler neden olan indeksleme veya kötü istatistikler.) Haftalar olağandışı.

Hipotezim, sunucunuzdaki başka bir uygulamanın belleği sızdırıyor olmasıdır. Bunu virüs yazılımı (her DBA'nın favori sunucu yazılımı canavarı) ve 3. parti izleme yazılımı ile gördüm. Zaman içinde SQL Server'ın bellek kullanımını iki kez kontrol ederdim ve diğer tüm uygulamaların bellek kullanımını da kutuda tutardım. SQL Server'ın bellek kullanımında ayarlanmış zor sınırlarınız varsa ve sayfalamaya izin vermeyecek şekilde ayarladıysanız, sayfalanan ve G / Ç kapasitesi tüketen diğer uygulamalar olabilir.

Aramak zor değil. Eğer zaten ölçümleri sunucuda tutmuyorsanız, sadece Perfmon'u başlatır ve her 30 veya 60 dakikada bir örnek alırım. Birkaç gün sonra, diğer uygulamaların hafıza kullanımının yukarı doğru kaydığını görebilirsiniz.

SQL Server günlüğünde "önemli sql sunucusu bölümlerinin çıkarılmış olduğunu" belirten hata mesajları var mı? Bu da büyük bir ipucu olurdu.

Sadece 16 GB RAM'e sahip tek bir SQL server örneğinde 1200 DB çalıştırabildiğiniz ve sizi birkaç hafta sorunsuz çalıştıktan sonra bu tür sorunlara sahip olduğunuz için tebrik etmeme izin verin. Yerel PASS bölümünde anlatmak için güzel bir hikaye.

Şimdi sorun gidermek için: RAM'iniz hem SQL hem de OS için 16 GB'dir. Maksimum bellek ayarınızın 15 GB veya maks. Bu, arabellek havuzunun tüm belleği kullanmasına ve işletim sistemini boğmasına neden olabilir. Tampon havuzunu ve önbellekleri temizlemenin herhangi bir farklılık göstermediğini söylüyorsunuz, artı PLE'niz 300'ün üzerinde. Bu, bellek şişesi boyunlarına karşı tanıklık ediyor. Sunucudaki CPU ve IO nasıl (özellikler / istatistikler)?

Çalıştırın select * from sys.dm_exec_request where session_id>50 and session_id<>@@spidve gördüğünüz kaynak içeriği nedir (wait_type, wait_time, last_wait_type, wait_resource).

1200 veritabanları, bir os ve muhtemelen başka şeyler? Evet, bence sunucunun kendisinin çalışması için 1 gb'den fazla ram'a ihtiyaç duyacağını düşünüyorum, özellikle de 15 gb'yi SQL Server'ın maksimum bellek ayarı olarak ayarlarsanız, o konu için 15 gb'nin dışında ek belleğe ihtiyaç duyuyor .

Sunucuyu biraz daha soluma odası bırakmak için SQL Server'ı 14GB'a düşürdüm.

Ayrıca, 16 GB RAM ile üçüncü bölüm yedekleme yardımcı programına sahip bir SQL Server 2008 x64 sistemindeki bellek ödenekleri için "Professional SQL Server 2008 Dahili ve Sorun Giderme" de verilen bir örnek:

• Windows için 2 GB
• İşçi konuları için 1GB
• MPA'lar için 1GB, vb.
• Yedekleme programı için 1GB
• SQL Server için 11 GB

Kitapta, sahip olabileceğiniz maksimum iş parçacığı sayısının nasıl belirleneceği ve ne kadar hafıza kullanacakları hesaplanır. Konu başlığının ne kadar belleğe ihtiyacı olacağını bulmak için bunu çalıştırın (sunucunuzu eşleştirmek için sunucu türünü değiştirin).

declare @servertype int

set @servertype=1
/*
1: x86 (32-bit)
2: x64 (64-bit)
3: IA64

*/

select max_workers_count *
    (
        case @servertype when 1 then .5
            when 2 then 2
            when 3 then 4
            else .5
        end
    )
from sys.dm_os_sys_info

Veritabanı belleği tüm veritabanlarına eşit olarak dağıtılmışsa, her bir veritabanı için yalnızca 12.8 Megs (15 * 1024) /1200=12.8 vardır. Daha fazla belleğe ihtiyacın var.

Performansın neden yavaşladığını araştırmanız gerekiyor. Kilitleme, engelleme vb. Görüyor musunuz? Bekleme istatistikleri neye benziyor?

DBCC komutları yalnızca belleği tekrar işletim sistemine bırakmayacakları bellek tamponlarını siler.

SQL Server'ın aslında belleği harcadığını biliyor musunuz? SQL Server'ın ne yaptığını ve üzerinde çalıştığını bulmak için yeniden başlatıldıktan sonra Perfmon oturumu kurmayı veya DMV bilgilerini toplamaya başlamanızı öneririm. Ayrıca, kullanıcılar toplama süreniz boyunca normalden daha fazla iş yapıyorsa (Ay Sonu işleme vb.) Dikkat edin. Aynı sunucuda SSRS, SSIS veya SSAS kullanıyor musunuz?

Sistemde 1200 veritabanınız var, sahip olduğunuz en büyük DB nedir?