SVCHOST / Workstation hizmetinde Windows 2012 Core Extreme bellek kullanımı


9

Hepimiz aynı sorunu yaşayan yaklaşık 200 sunucumuz var, Hyper V, Dosya Kümesi ve IIS, sunucudaki RAM'i en üst düzeye çıkaran veya neredeyse en üst düzeye çıkaran normal kullanım yoluyla sunucuda bir olay meydana geliyor. Bu gerçekleştiğinde, SVCHOST / İş İstasyonu hizmeti, özellikle (İş İstasyonu hizmetini kendi SVCHOST'una izole ederek ayıklanır) tutamaçları / iş parçacıklarını bırakmayı durdurur ve bu hizmet tarafından kullanılan bellek hiçbir zaman serbest bırakılmaz. Bazı aşırı durumlarda, 255 GB'lık bir sunucuda 40 GB'a kadar koç kullanan İş İstasyonu hizmetlerimiz vardır. Ayrıca bazı durumlarda 40 milyondan fazla tanıtıcı bulmak.

Yeniden başlatma sırasında sorun elbette ortadan kalkar ve W3 işlemi veya HyperV VM'leri tarafından tüm bellek kullanılana kadar tekrar görünmez, bundan sonra İş İstasyonu hizmeti tüm RAM'i yakalamaya başlar. İşlem çok yavaştır ve sunucudaki RAM miktarına bağlı olarak hafta / ay sürebilir.

Hem Hyper V sunucularımız hem de IIS sunucularımız çalışma dosyaları için paylaşımlara erişir, bu paylaşımlar SSD depolamadadır, bu nedenle çok performanslıdırlar. Mevcut tüm yamaları yükledik, ancak bunu önemli bir adım haline getirecek ve bunun R2'de sabitleneceğine dair açık bir gösterge bulamayacak çok fazla aracımız olduğu için R2'ye taşınmadık.

ProcMon ve diğer araçları çalıştırdık ancak en sorunlu sunucularda bu araçlar çalışmaz. Diğerlerinde, sağladıkları sonuçlar, bu süreçte gerçekten bir bellek sızıntısı olduğunu gösteriyor.

Bu işlemden hafızayı boşaltmamızın veya hatayı hep birlikte önlememizin bir yolu var mı? Yeniden başlatmak zorunda değiliz ve bir hata durumundayken işlemi yeniden başlatamayız. İşlem donar.

Bu sorunu 'düzeltmek' için düzenli olarak yeniden başlatma yapmaktan kaçınmaya çalışıyoruz, bu nedenle cevaplar takdir edilecektir.


Sorun nedir?
Andrew Schulman

Gerçekten de öyle, ama en iyi ihtimalle belirsiz, sadece binlerce / milyon iplik açılıyor. En sorunlu sistemlerde bu araçları bile çalıştıramayız, sadece sunucuyu çökertirler.
Craig

Kutuyu yeniden başlatmak dışında sorunu çözmek için iyi bir çözüm bulmak istiyoruz. Bu sorun başladıktan sonra hizmetleri durduramıyoruz.
Craig

KB 2811660 yüklendi mi? Bu sistemler sunucu yöneticisi çalıştırıyor mu? support.microsoft.com/kb/2793908

Evet, bu KB bir süre önce yüklendi. Ayrıca, bu sızıntı KB'nin WMI hizmeti için geçerli olan İş İstasyonu hizmetine özgüdür.
Craig

Yanıtlar:


1

Svchost'un sunucu performansını yok ettiği neredeyse benzer bir sorunum vardı.

Çözüm: Tam bir Olay Günlüğüm olduğu ortaya çıktı. Onu temizledim ve hiçbir şey olmamış gibi her şey geri döndü.

(Ayrıca olay günlüğünün boyutunu varsayılandan değiştirmenizi öneririm, aşağıya bakın)

Windows arabirimini kullanarak maksimum günlük boyutunu ayarlamak için
- Olay Görüntüleyicisi'ni başlatın .
- Konsol ağacında, yönetmek istediğiniz olay günlüğüne gidin ve seçin.
- Eylem menüsünde Özellikler'i tıklatın.
- Maksimum günlük boyutu (KB) altında, istediğiniz değeri ayarlamak için değer değiştirici denetimini kullanın ve Tamam'ı tıklatın.

Tam olarak burada olanlara benziyor, ancak gerçekten kolay bir düzeltme haline geldi. Yeniden başlatma sorunu geçici olarak çözecektir, ancak herhangi bir şey günlüğe yazmaya çalıştığında, her şey elden çıkar ve kaynakları tüketmeye devam eder.

Bu yardımcı olur umarım!


-1
>Is there a way we can free up the memory from this process ?

Tahsis edilen belleği harici olarak (düzgün bir şekilde) serbest bırakmanın veya kaynakları rahatsız eden uygulamayı öldürmeden işlemenin hiçbir yolu yoktur.

>or avoid the bug all together? 

Bir bellek ve kaynak sızıntısı yaşıyorsunuz. Sorunu çözmenin tek yolu sızıntıyı bulmak ve tetikleyiciden kaçınmak (mümkünse) ya da sızıntıyı kaynak kodu düzeyinde düzeltmektir; Son durumda, düzeltme ekini üretmek için Microsoft yardımına ihtiyacınız var, ancak sorunun tam olarak nerede olduğunu "tam olarak" söylemenizi bekliyorlar.

MS Uygulama Doğrulayıcı'yı kullanarak bellek / kaynak sızıntısını saptayarak suçluyu bulmayı deneyebilirsiniz


Tetikleyici, kaçınamayacağımız dosya paylaşımlarıdır.
Craig

Tetiği önleyemiyorsanız, "Application Verifier" ile sızıntıyı bulun ve MS ile bu bilgileri arayın.
Pat

Birden fazla olduğu gibi uygulamaların hepsi Microsoft'tur. Onlarla zaten temasa geçtik, daha hızlı bir çözüm arıyoruz, çünkü bunu çözmek için haftalar / aylar sürebilir.
Craig

MS'in şu anki olmayan bir işletim sisteminde bu tür şeyleri çözmek için acele etmeyeceğini düşünürsek, daha hızlı bir çözüm bulacağınızı düşünmüyorum. Farklı bir şey, sızıntının nerede olduğunu onlara bildirirseniz.
Pat

Açık bir vakamız var ve bir aydır onlarla çalışıyoruz. Sızıntı tam anlamıyla İş İstasyonu hizmetinde.
Craig

-1

RAM'i ezmek kolaydır, ancak çözüm yoktur.

Daha derin araştırmalar için Sysinternals RAMMAP veya VMMAP'yi öneririm. Bu araçlarla neler olduğunu daha iyi görebilirsiniz. çoğu zaman bir meta dosyası sorunu.

Server 2008'den bu yana, uygulamaların paylaşımdan başlatılması sırasında zaman içinde inanılmaz bir bellek tüketimi ile bellek tükenmekte olan tüm terminal sunucuları ile bu sorunu yaşıyoruz.

Çözümümüz, uygulamaları ayrı bir Terminal Sunucusunda barındırıyor ve sık sık bellek tüketimini temizliyor.

Bunu
, tüm süreçlerde SeDebugPrivilege ile SetProcessWorkingSetSize () kullanarak kendinden tasarlanmış bir c ++ komut satırı uygulamasıyla yapıyoruz

Böyle bir şey yapmamanız şiddetle tavsiye edilir;)


Neden oy kullanmıyorsunuz? Tam olarak ne istedi! Burada yardım etmeye çalışmak hiç de zevkli değil ...
Magnus
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.