ASP.NET'de yüksek bellek düzeyleriyle karşılaştığınızda denetlenecek hızlı şeyler

Bu makalede, Microsoft ASP.NET'da yüksek bellekle karşılaştığınızda denetlenecek hızlı işlemler açıklanmaktadır.

Özgün ürün sürümü: ASP.NET
Özgün KB numarası: 893660

Bu makale bazı yaygın sorunlarla, bu sorunları gidermeye yönelik eylemlerle ve bu durumların neden sorunlara neden olabileceğine ilişkin kısa bir açıklamayla başlayacaktır.

ASP.NET Destek Sesi sütunu

Nisan 2005 Destek Sesi sütununda yanlışlıkla yanlış dosyanın bağlantısını sağladık. Web hizmeti için bir indirmeye bağlanmak yerine, Web hizmeti tarafından döndürülen XML dosyasına bağlandık. Bu bağlantı düzeltildi. Makaleyi doğru dosyanın eklendiği şekilde gözden geçirmek isterseniz bkz . XML kullanarak dinamik sayfa güncelleştirmeleriHTTP.

Yüksek bellek olarak kabul edilenler

Açıkçası, bu soru belirli uygulamaların hacmine ve etkinliğine bağlıdır. Genel olarak yüksek bellek, ASP.NET çalışan işleminiz (Aspnet_wp.exe) veya Internet Information Services (IIS) çalışan işlemi (W3wp.exe) belleğinizin tutarlı bir şekilde arttığı ve rahat bir düzeye dönmediğinden oluşur.

Genel olarak, rahat bir düzey varsayılan 2 GB kullanıcı belleği adres alanında 600 MB'ın altında olacaktır. Bellek düzeyi bu rahat düzeyden daha yüksek olduğunda, olması gerekenden daha az şey yapıyoruz. Bu davranış, sistemde çalışan diğer uygulamaları etkileyebilir.

Önemli olan, bazı uygulamaların diğerlerinden daha fazla bellek gerektirdiğini anlamaktır. Bu sınırları aşıyorsanız, Daha fazla bellek ekleyebilir veya Web grubunuza başka bir sunucu ekleyebilirsiniz (veya bir Web grubu düşünün). Bu durumlarda profil oluşturma da önerilir. Geliştiricilerin daha yalın uygulamalar oluşturmasını sağlayabilir. Bu makalede, sunucu çalışmayı durdurana kadar belleğin sürekli olarak arttığı bir duruma bakıyoruz.

Hata ayıklama için uygulama kurulumu

Burada Destek bölümünde çok fazla gördüğümüz yüksek belleğin nedenlerinden biri, uygulamanız için hata ayıklama, izleme veya her ikisini de etkinleştirmiş olmanızdır. Uygulamanızı geliştirirken hata ayıklamayı ve izlemeyi etkinleştirmek bir zorunluluktur. Varsayılan olarak, uygulamanızı Visual Studio .NET'te oluşturduğunuzda Web.config dosyanızda aşağıdaki özniteliğin ayarlandığını görürsünüz:

<compilation
 ...
 debug="true"
 />

veya

 <trace
 enabled="true"
 ...
 />

Ayrıca, uygulamanızın son derlemesini yaptığınızda, bunu Hata Ayıklama modunda değil Yayın modunda yaptığınızdan emin olun. Üretime geçtikten sonra hata ayıklama artık gerekli olmamalıdır. Performansınızı gerçekten yavaşlatabilir ve belleğinizi yitirebilir. Bu özniteliği ayarlamak, uygulamanızı işleme yönteminizle ilgili birkaç şeyi değiştirebileceğiniz anlamına gelir.

İlk olarak, bu compilation öğede ayarlanmış olsa bile toplu derleme devre dışı bırakılır. Bu, uygulamanızdaki her sayfa için bir derleme oluşturacağınız anlamına gelir, böylece bu derlemeyi bölebilirsiniz. Bu derlemeler bellek alanınıza rastgele dağıtılabilir ve bu da belleği ayırmak için bitişik alanı bulmanızı zorlaştırır.

İkincisi, executionTimeout özniteliği (<httpRuntime> Öğesi) 90 saniye varsayılanını geçersiz kılarak yüksek bir sayıya ayarlanır. Hata ayıklama sırasında sorun yoktur, çünkü hata ayıklamalarınızı bulmak için kodda sabırla ilerlerken uygulama zaman aşımına uyamazsınız. Ancak bu, üretimde önemli bir risktir. Başka bir deyişle, herhangi bir nedenle sahte bir isteğiniz varsa, bir iş parçacığını tutar ve birkaç dakika yerine günler boyunca herhangi bir zarar verici davranışa devam eder.

Son olarak, Geçici ASP.NET dosyaları klasörünüzde daha fazla dosya oluşturacaksınız. System.Diagnostics.DebuggableAttribute Ve (System.Diagnostics Ad Alanı, oluşturulan tüm koda eklenir ve bu da performans düşüşlerine neden olabilir.

Bu makaleden başka bir şey alamazsanız, umarım bu bilgiyi alırsınız. Hata ayıklamayı etkin bırakmak kötüdür. Bu davranışı çok sık görüyoruz ve değiştirmek çok kolay. Sayfa düzeyinde ayarlanabileceğini unutmayın. Tüm sayfalarınızın ayarlamadığından emin olun.

Dize birleştirme

Sunucu tarafı kodu kullanarak ve tarayıcıya göndermek için yalnızca bir büyük HTML dizesi oluşturarak HTML çıkışı oluşturan uygulamalar vardır. Sorun değil, ancak dizeyi kullanarak ve & birleştirerek + oluşturuyorsanız, kaç büyük dize oluşturduğunuzun farkında olmayabilirsiniz. Örneğin:

string mystring = "<html>";
mystring = mystring + "<table><tr><td>";
mystring = mystring + "First Cell";
mystring = mystring + "</td></tr></table>";
mystring = mystring + "</html>";

Bu kod yeterince zararsız görünüyor, ancak bellekte depoladığınız şeyler şunlardır:

<html>
<html><table><tr><td>
<html><table><tr><td>First Cell
<html><table><tr><td>First Cell</td></tr></table>
<html><table><tr><td>First Cell</td></tr></table></html>

Yalnızca son satırı depoladığınızı düşünebilirsiniz, ancak bu satırların tümünü depolursunuz. Özellikle büyük bir tablo oluştururken, büyük bir kayıt kümesinde döngü yaparak bu tablonun nasıl kontrolden çıkabileceğini görebilirsiniz. Yaptığınız şey buysa sınıfımızı System.Text.StringBuilder kullanarak tek bir büyük dizeyi depolamanız gerekir. Bkz. Dize birleştirme performansını geliştirmek için Visual C# kullanma

.NET Framework Service Pack 1 (SP1)

.NET Framework SP1'i henüz çalıştırmıyorsanız, bellek sorunlarıyla karşılaşıyorsanız bu SP'yi yükleyin. Çok fazla ayrıntıya girmeyeceğim, ama temel olarak SP1 ile artık belleği çok daha verimli bir şekilde ayırıyoruz. Temel olarak, bir kerede 64 MB yerine büyük nesneler için bir kerede 16 MB ayırıyoruz. Hepimiz taşındık ve hepimiz biliyoruz ki, birkaç büyük kutu yerine çok sayıda küçük kutu kullanıyorsak bir arabaya veya kamyona çok daha fazlasını paketleyebiliriz. Buradaki fikir bu.

Düzenli aralıklarla geri dönüşüm yapmaktan çekinmeyin

Iis'deki uygulama havuzlarını varsayılan olarak her 29 saatte bir geri dönüştüreceğiz. görevi sonlandırana, IIS'yi yeniden başlatana veya bilgisayarı yeniden başlatana kadar Aspnet_wp.exe işlemi devam edecektir. Bu davranış, bu işlemin aylar boyunca çalıştırılabildiği anlamına gelir. Bazı uygulamaların çalışan işlemini birkaç günde bir ve daha sonra uygun bir zamanda yeniden başlatması iyi bir fikirdir.

Sorulacak sorular

Önceki, hızlı bir şekilde düzeltebileceğiniz her şeydi. Ancak bellek sorunlarıyla karşılaşıyorsanız kendinize şu soruları sorun:

  • Çok fazla büyük nesne mi kullanıyorum? Büyük bir nesne yığınında 85.000 KB'tan fazla depolanıyor.

  • Nesneleri Oturum durumunda mı depoluyorum? Bu nesneler, bunları kullanıp atmanıza kıyasla çok daha uzun süre bellekte kalacaktır.

  • Nesnesini mi kullanıyorum Cache ? Akıllıca kullanıldığında, performans için büyük bir avantajdır. Ancak, akıllıca kullanılmadığında, hiç serbest bırakılmayan çok fazla bellek kullanırsınız.

  • Web uygulaması için çok mu büyük döndürdüm recordsets ? Kimse Web sayfasında 1.000 kayda bakmak istemez. Uygulamanızı, bir yolculukta 50 ile 100 arasında kayıt alamayacak şekilde tasarlamanız gerekir.

Hata ayıklama

WinDbg'yi ayarlamaya girmeyeceğim. Ancak, daha karmaşık sorunları gidermek istiyorsanız, belleğinizde tam olarak ne olduğunu görmek için aşağıdaki komutları kullanabilirsiniz.

!eeheap -gc

Bu komut size ne kadar yönetilen belleğe sahip olduğunuzu gösterir. Bu değer yüksekse, yönetilen kodunuzun derlediğiniz bir şey vardır.

!dumpheap -stat

Bu komutun çalıştırılması biraz zaman alır, hatta belleğiniz büyükse saatler sürer. Ancak bu komut size tüm nesnelerinizin listesini, her türün kaçını ve her birinin ne kadar bellek kullandığını gösterir. (Örneğin, sınıfı için StringBuilder birçok System.String nesne görürsünüz)

Çok fazla bellek alan bir nesne bulduğunuzda aşağıdaki komutu kullanarak daha fazla bilgi bulabilirsiniz:

!do <addr>

Aradığınız nesnenin adresini komutundan dumpheap alabilirsiniz.

Bu sütunlardaki belirli durumlar için bu tanılama aracını kullanmanın daha fazla yolunu birleştirmeye çalışıyoruz. İyi bir iş çıkardıysak bize bildirin!

Bellek ve performans makaleleri

Çöp Toplayıcı temel bilgileri ve performans ipuçları

Yüksek Performanslı ASP.NET Uygulamaları Geliştirme

ASP.NET Performans İzleyicisi etme ve Yöneticileri Ne Zaman Uyaracakları

.NET Uygulama Performansını ve Ölçeklenebilirliğini Geliştirme

  • Last updated on