[asp.net] w3wp.exe ineens extreem hoog geheugen (>=700MB!!)

[Verwijderd]

Ik heb een asp.net applicatie draaien, en tot vorige week woensdag draaide de applicatie perfect. Toen begonnen de problemen ineens. Sinds die woensdag is ie op woensdag ochtend, maandag, en gisteren (2x) "gecrasht". De reden waarom ik het "gecrasht" noem, is omdat de server niet echt vastloopt, want ik kan er gewoon nog op met remote desktop, en de sql server lijkt ook nog te draaien, etcetera. Maar als ik de aspx pagina's opvraag van de webapplicatie dan gaat ie trippen en treden er fouten op.

Als ik dan kijk naar het w3wp.exe geheugen gebruik dan zit die ineens giga hoog (ene keer op 700MB, en gisteren zelfs op 1.2GB!). Dit lijkt mij absoluut niet gezond aangezien w3wp.exe normaliter altijd tussen de 70 en de 90MB schommeld. Aangezien ik tot nu toe de afgelopen week geen andere concreet aanwijsbare oorzaken heb gevonden lijkt het mij dat het probleem wat ik in de eerste alinea omschreef te maken heeft met het excessief geheugen gebruik dat ik hier in de tweede alinea beschrijf. Wat ik alleen niet voor elkaar krijg om te achterhalen waar die explosieve groei in geheugen gebruik van w3wp.exe ineens vandaan komt.

Concrete vraag aan jullie.. kennen jullie het probleem, en hebben jullie eventueel oplossingsrichtingen?? Want ik begin een beetje vast te lopen na een week overal en nergens zoeken...

[specs server]
Windows 2003 Enterprise edition (met SP1)
Intel Xeon MP CPU 2,7 Ghz
3,75GB RAM
IIS 6.0
ASP.NET 1.1
SQL Server 2000 (met SP3)

[load]
In de maand oktober 4.971.380 hits. Alle hits komen in principe tussen 6:00 en 18:00. Gemiddeld gezien komt dit dus uit op 3,7 hits per seconde.

[gorgi_19]

Hoeveel threads draait het w3wp.exe? Die heeft wel eens de neiging om zichzelf op te blazen als je multithreading gebruikt. Verder zegt de hoeveelheid geheugen niets; w3wp pakt wat er beschikbaar is en gooit wat leeg als hij het nodig vindt.

[ Voor 33% gewijzigd door gorgi_19 op 04-11-2005 13:18 ]

[Verwijderd]

Hij gebruikt 1 thread.

Wat betreft het geheugen, ik kan die eigenschap van sql server, maar wist niet dat w3wp op dezelfde manier functioneerd.

Maar het kan toch niet normaal zijn dat ie van 70-90 MB ineens piekt naar 700-1200MB??.. En dan is het ook nog wel weer toevallig dat ie ook dan juist helemaal gaat trippen.

[edit]
of misschien gaat ie juist naar 700-1200MB omdat ie aan het trippen is?..

de vraag is dus.. hoe kan een asp.net webapp ineens zoveel geheugen pakken???

[ Voor 21% gewijzigd door Verwijderd op 04-11-2005 13:57 ]

[gorgi_19]

Verwijderd schreef op vrijdag 04 november 2005 @ 13:54:
Hij gebruikt 1 thread.

Zeker weten? Staat er maar 1 bij het kopje "Threads" in Task Manager?

[Verwijderd]

gorgi_19 schreef op vrijdag 04 november 2005 @ 13:59:
[...]

Zeker weten? Staat er maar 1 bij het kopje "Threads" in Task Manager?

Uh.. misverstandje!! Ik dacht dat je bedoelde het aantal worker processes (web garden)..


Ff gekeken, en hij gebruikt op dit moment 38 threads.


[edit]
en sql server zit op 60 threads.

[ Voor 15% gewijzigd door Verwijderd op 04-11-2005 14:04 ]

[Wolly]

Misschien dat je hier iets meer mee kunt?

Gebruik je nog webservices oid op die server?

[Verwijderd]

Verwijderd schreef op vrijdag 04 november 2005 @ 12:42:
Ik heb een asp.net applicatie draaien, en tot vorige week woensdag draaide de applicatie perfect. Toen begonnen de problemen ineens. Sinds die woensdag is ie op woensdag ochtend, maandag, en gisteren (2x) "gecrasht"... Maar als ik de aspx pagina's opvraag van de webapplicatie dan gaat ie trippen en treden er fouten op.

Wat voor fouten?

connectieproblemen met je database? misschien connectiepool wat vergroten.

Verwijderd schreef op vrijdag 04 november 2005 @ 12:42:

Als ik dan kijk naar het w3wp.exe geheugen gebruik dan zit die ineens giga hoog (ene keer op 700MB, en gisteren zelfs op 1.2GB!). ... Wat ik alleen niet voor elkaar krijg om te achterhalen waar die explosieve groei in geheugen gebruik van w3wp.exe ineens vandaan komt.

Concrete vraag aan jullie.. kennen jullie het probleem, en hebben jullie eventueel oplossingsrichtingen?? Want ik begin een beetje vast te lopen na een week overal en nergens zoeken...

[load]
In de maand oktober 4.971.380 hits. Alle hits komen in principe tussen 6:00 en 18:00. Gemiddeld gezien komt dit dus uit op 3,7 hits per seconde.

Ik denk dat we hier weinig over kunnen zeggen.

Zijn er nog Windows updates geweest?
Zijn er nog updates geweest van je asp.net-applicatie?
Heb je het dataverkeer al geanalyseerd?
Misschien de asp.net code eens door iemand anders laten controleren...
Objecten opslaan in de cache/sessie is not-done.
Gebruik van veel datasets is not-done.
Heb je overal wel netjes object.Dispose() aangeroepen. try... finally, etc.
etc.

[ Voor 3% gewijzigd door Verwijderd op 04-11-2005 23:17 ]

[Verwijderd]

Wolly.. dat forum topic had ik idd ook al gevonden... thanks voor het zoeken iig!

sinaasappelsap... het probleem is juist dat we die fouten niet kunnen achterhalen.. de pagina laad gewoon niet goed. Het grote probleem is dus juist dat er geen touw aan vast te knopen valt wat er nou echt specifiek fout gaat

Er zijn geen windows updates geweest, en ook niet van mijn asp.net applicatie. Dataverkeer hebben we naar gekeken, maar dat is geen bottleneck voor zover we nu kunnen zien.

Waarom is objecten in de sessie opslaan not done?.. ik heb altijd begrepen uit verschillende goede bronnen dat het wel mag, mits met mate.

We gebruiken geen datasets. Dus dat kan het probleem niet zijn.

We roepen (waar nodig; bijv. bij filestreams, db connecties, etc) netjes Dispose aan.

[SlowMeDown]

Jij doet niet toevallig dynamisch bestanden naar clients streamen, dus niet via een hyperlink naar het bestand toe, maar het bestand naar de HttpResponse schrijven via de HttpResponse.WriteFile methode?

Daar zit een grote fout in die ervoor zorgt dat je ASP.NET process zeer veel geheugen kan gaan gebruiken en spontaan kan recyclen. Vanaf service pack 1.1 en .NET framework 2.0 is de TransmitFile methode daarom beschikbaar.

Wellicht doe jij niks van dit alles en praat ik nu poep, maar misschien heb je er toch wat aan.

[Verwijderd]

SlowMeDown schreef op maandag 07 november 2005 @ 11:43:
Jij doet niet toevallig dynamisch bestanden naar clients streamen, dus niet via een hyperlink naar het bestand toe, maar het bestand naar de HttpResponse schrijven via de HttpResponse.WriteFile methode?

Daar zit een grote fout in die ervoor zorgt dat je ASP.NET process zeer veel geheugen kan gaan gebruiken en spontaan kan recyclen. Vanaf service pack 1.1 en .NET framework 2.0 is de TransmitFile methode daarom beschikbaar.

Wellicht doe jij niks van dit alles en praat ik nu poep, maar misschien heb je er toch wat aan.

Er wordt in het systeem "redelijk"-veelvuldig gebruik gemaakt van het dynamisch streamen van bestanden.. en inderdaad middels de WriteFile methode. Ik ga ns kijken naar TransmitFile.

Thanks!

[Hydra]

Cool! Een klant van ons heeft dit probleem, even die info forwarden, hopelijk hebben ze er wat aan.

[Verwijderd]

Hydra schreef op dinsdag 08 november 2005 @ 12:09:
Cool! Een klant van ons heeft dit probleem, even die info forwarden, hopelijk hebben ze er wat aan.

Hebben zij al een oplossingsrichting gevonden?..

Want ik denk dat er meer aan de hand is dan alleen de Response.WriteFile...

[Hydra]

Verwijderd schreef op woensdag 09 november 2005 @ 09:20:
Hebben zij al een oplossingsrichting gevonden?..

Want ik denk dat er meer aan de hand is dan alleen de Response.WriteFile...

Nee, ze hebben de info doorgespeeld naar de mensen die die app ontwikkeld hebben. Mocht ik iets horen dan laat ik het wel ff weten.

[Verwijderd]

Verwijderd schreef op zondag 06 november 2005 @ 18:04:
sinaasappelsap... het probleem is juist dat we die fouten niet kunnen achterhalen.. de pagina laad gewoon niet goed. Het grote probleem is dus juist dat er geen touw aan vast te knopen valt wat er nou echt specifiek fout gaat

Veel plezier met zoeken..

Verwijderd schreef op zondag 06 november 2005 @ 18:04:
Er zijn geen windows updates geweest, en ook niet van mijn asp.net applicatie. Dataverkeer hebben we naar gekeken, maar dat is geen bottleneck voor zover we nu kunnen zien.

Verwijderd schreef op zondag 06 november 2005 @ 18:04:
Waarom is objecten in de sessie opslaan not done?.. ik heb altijd begrepen uit verschillende goede bronnen dat het wel mag, mits met mate.

Inderdaad, mits met mate. dus zeker wel een idee om daar naar te kijken (niet dat dat het probleem hoeft te zijn.)
Stel je plaatst een object van 0,1 mb in de sessie. en je hebt tien openstaande sessies, dan is dat al gauw 1 Mb. heb je honderderd openstaande sessies, dan is dat 10 Mb. Heb je duizend openstaande sessies, dan is dat 100 Mb. En als je de sessieduur vergroot, zullen er automatisch ook meer openstaande sessies zijn. En pas in piekbelastingen van je website komen meestal de 'programmeerfouten' naar voren.
Het is maar een idee....

Verwijderd schreef op zondag 06 november 2005 @ 18:04:
We gebruiken geen datasets. Dus dat kan het probleem niet zijn.

Datatable misschien? of whatever.

[Verwijderd]

Het is ook inderdaad zeker zo dat we ook kritisch kijken naar potentiele fouten in ons programmeerwerk. Ik ga ook nog wel even kijken naar het sessie gebruik.

En we gebruiken sporadisch nog wat datatables, maar dat is dus minimaal...


Kan het probleem in jullie ogen te maken hebben met het feit dat de server multi-processor is? Ik kwam op verschillende plekken namelijk mensen tegen met een vergelijkbaar probleem als de onze en dan met de oorzaak van multi-processor server.

[EfBe]

Verwijderd schreef op woensdag 09 november 2005 @ 09:20:
[...]

Hebben zij al een oplossingsrichting gevonden?..
Want ik denk dat er meer aan de hand is dan alleen de Response.WriteFile...

Heb ik ook gehad. Er zit een memory leak in BinaryWrite, zodat je managed byte[] array niet wordt vrijgegeven. Ook de truuk met het passen van een IntPtr naar BinaryWrite (een int pointer naar de stream) werkt niet, want dan wordt de stream niet gefreed, ongeacht dat je hem closed.

WriteFile(stream) werkt OOK NIET, je stream data wordt niet gefreed, ookal close je de stream.

WriteFile(filename) werkt WEL, je bent dan wel even wat memory kwijt maar zodra de file over is, wordt dat vrijgegeven. TransferFile kost geen memory en werkt ook (vanaf .NET 1.1 SP1, het is een method toegevoegd aan .NET 1.1 via Sp1, en undocumented, pas documented vanaf .net 2.0).

Er is wel een nadeel aan transfer file: als de transfer lang duurt en de session wordt gekilled door de webserver, dan valt de download ook weg.

Ik ben een dag bezig geweest om alle mogelijke varianten uit te proberen middels profilers etc., WriteFile(filename) en TransferFile werken het beste, maar die drop van de connection daar moet je rekening mee houden op Win2k3 SP1 wanneer je TransferFile gebruikt. Daar is overigens een hotfix voor beschikbaar, maar niet publiekelijk te downloaden (dus PSS bellen)

[ Voor 8% gewijzigd door EfBe op 10-11-2005 13:00 ]