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

Makale
07/17/2023

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

Orijinal ü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ğinin kısa bir açıklamasıyla 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ğinde ortaya çıkar.

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 kullanmayı düşünebilirsiniz). 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 durumla karşı karşıyayız.

Hata ayıklama için uygulama ayarlama

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 tüketebilir. Bu özniteliği ayarlamak, uygulamanızı nasıl işlediğinizle 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şturarak bu derlemeye girebileceğiniz anlamına gelir. 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 zarara neden olan 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 bunun nasıl kontrolden çıkabileceğini görebilirsiniz. Yaptığınız buysa sınıfımızı System.Text.StringBuilder kullanarak tek bir büyük dizeyi depolayın. 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ı yaşıyorsanız bu SP'yi yükleyin. Çok fazla ayrıntıya girmeyeceğim, ama temelde, 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 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 korkmayın

Iis'de 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 eder. Bu davranış, bu işlemin aylar boyunca çalıştırılabileceğini gösterir. Bazı uygulamaların çalışan işlemini birkaç günde bir veya 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ı depoliyorum? Bu nesneler, kullanıp atmanıza kıyasla bellekte çok daha uzun süre 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çbir zaman serbest bırakılmayan çok fazla bellek kullanılır.
Web uygulaması için fazla büyük mü döndüreceğim recordsets ? Kimse Web sayfasındaki 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, 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

Belleğiniz büyük olsa bile bu komutun çalıştırılması biraz zaman alır. Ancak bu komut size tüm nesnelerinizin listesini, her türden kaç tane olduğunu 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 edinin:

!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ışacağız. İyi bir iş yapıp yapmadığımızı bize bildirin!