[ASP] Geheugen Lekje(800 Mb)

[Verwijderd]

Ik heb de server draaien:

Windows 2000
SQL2000

Beide met nieuwste service-packs en updates.
Verder draaien er de volgende componenten op:

AspUpload van Persits
AspImage van ServerObjects
AspMail van ServerObjects
AspQmail van Serverobjects

We draaien IIS5 en gebruiken alleen ASP. Verder draait er wel index server op deze smurfer.

Ik heb dus een probleem met dat het geheugen volloopt(tot 800 Mb). Dit gebeurt in het proces "dllhost". Het heeft dus te maken met die componenten of iets wat niet afgesloten wordt. Ik heb in VB een tool geschreven die controleerd of objecten worden afgesloten maar helaas alles wordt afgesloten. Heeft iemand hier wel eens datzelfde probleem gehad en zo ja, hoe heb je dit opgelost.

Verder wil ik wel eens weten wat die dll-host precies is.

[Verwijderd]

Dat zou je webserver moeten zijn. Hebben we bij ons ook last van. (Leaks) Hebben ook naar Microsoft gebeld, maar die gaven een tooltje waarmee je lekken kan opsporen, maar dus geen oplossing.

[Verwijderd]

Fijne gasten Heb je die tool toevallig ergens beschikbaar? En heb je dat leak ook op je DLLhost proces?

[Verwijderd]

Nee, we hebben niet de moeite genomen om dat tooltje te proberen. (Misschien kun je op MSDN zoeken?)
Voorlopig gewoon bv elke nacht/week/maand (afhankelijk van hoeveel last je ervan hebt) de server resetten, of overstappen op .NET

[Verwijderd]

ik wordt er best moe van. Heeft .net het beter voor elkaar?

[eborn]

Ik wacht eigenlijk op de flame-war

Ontopic: kun je niet een programma draaien dat het geheugen weer vrijgeeft? Er zijn toch van die programma's voor? Of is dit echt een bug in de server en niet in Windows?

[Verwijderd]

Laat maar komen.

Het heeft gewoon met proggen te maken, als je dit in Netwerk vraagt dan zitten ze allemaal glazig te praten.

En wat blijkt, er hebben meer mensen last van. Dus ik zie geen probleem.

Mischien wel een goed idee om een prog te schrijven die IIS herstart of zo, maar ik vind het een waardeloze zooi.

[eborn]

Op woensdag 03 april 2002 11:57 schreef voetenzalf het volgende:
Laat maar komen.

Het heeft gewoon met proggen te maken, als je dit in Netwerk vraagt dan zitten ze allemaal glazig te praten.

Zo'n war bedoelde ik niet Ik bedoelde tussen *Nix en Windows

Maar je kunt idd iets maken wat elke dag de webserver om 3 uur 's nachts herstart. Maar zoals je al aangeeft, mooi is anders. Als het een bekend probleem is zou je eigenlijk wel denken dat iemand er een mooie oplossing voor heeft verzonnen.

[TeeDee]

mijn ervaring met serverobjects:

Die dingen, als die niet helemaal perfecto afgesloten worden maken ze er een pracht van een memleak van.

Je moet het dus zoeken bij aspimage, aspmail en aspqmail. Die veroorzaken (bij ons iig) veel memleaks...

[raptorix]

Op woensdag 03 april 2002 12:21 schreef TeeDee het volgende:
mijn ervaring met serverobjects:

Die dingen, als die niet helemaal perfecto afgesloten worden maken ze er een pracht van een memleak van.

Je moet het dus zoeken bij aspimage, aspmail en aspqmail. Die veroorzaken (bij ons iig) veel memleaks...

Inderdaad, misschien toch nog eens goed code nalopen of het goed gebeurt.

[Verwijderd]

Lijkt mij ook dat er dingen niet afgesloten zijn.
En dan nog een adviesje:
Kijk uit met updates voor je windows server, wij hebben de security rollup pakkage geinstalleerd en nu kan de server het hele netwerk niet meer op........of bijvoorbeeld Exchange Service Pack 2 installeren en dan een aantal patches voor je IIS, ook dat ging errug fout.

[Verwijderd]

Thanx allot voor het advies. Ik ga eens ff alle mail scripts ook nog maar een keer nalopen. In ieder geval allemaal bedankt.

[Verwijderd]

Beetje omslachtige manier om uit te zoeken welke site er slecht gecode is (als je er meerdere hebt draaien is het volgende):

- zet elke website op High Isolation(of een paar verdachte)
- Mocht je machine nu weer naar een hoge Mem-usage gaan, kijk welke dllhost dit is en processid.
- Open je Computer Services Snap-in
- Ga dan COM+ Applications en zoek de bijbehorede processid (waarschijnlijk moet je even de view op 'status' zetten voor meer details

[Verwijderd]

Het vreemde is dat er maar 2 dll hosts draaien en die hebben een hele vreemde usr. Namelijk usr_iwam en dat is zo vreemd. Is het te achterhalen welk component welke dllhost gebruikt?

Alle scripts doorlopen is inderdaad nog al een heel karwei. Er draaien nu zo'n 20 websites op. Dus dat is wel pijnlijk. In ieder geval bedankt. Ik ga dit eens bekijken.

[Verwijderd]

Roepen dat het IIS is of een of ander component is onzin. Kijk in ELKE page na of je PRECIES doet wat het component voorschrijft DAT je moet doen wanneer je klaar bent met het component.

voorbeeld: als het component voorschrijft dat je EERST Close() moet aanroepen, dan moet je dat NIET nalaten: sommige components releasen in dat soort methods externe resources en verzuimen dat wanneer de com reference wegvalt en het object wordt opgeruimd. (Memleak). Dit is een van de leaks in oude ado recordset objects (set rsADO = nothing hielp dan niet)

Zet (indien je VBScript gebruikt in je ASP pages) altijd alle objects op 'nothing' voordat je op welke manier dan ook de page verlaat en roep alle NODIGE methods aan om resources op te laten ruimen door het component alvorens je het op nothing zet.

IIS cachet verder veel com components. Als je 1GB aan mem in je bak hebt zitten, dan zal IIS daar een groot deel van opeten voor caching. Kijk de IIS registry parameters na hoe dit te tweaken (via de metabase van IIS, kan via vbscript)

IIS zelf leaked af en toe memory maar niet zo ontstuimig veel. Veelal is crappy programming (ja sorry) van de webapplicatie de oorzaak.

[Verwijderd]

Op woensdag 03 april 2002 13:41 schreef voetenzalf het volgende:
Het vreemde is dat er maar 2 dll hosts draaien en die hebben een hele vreemde usr. Namelijk usr_iwam en dat is zo vreemd. Is het te achterhalen welk component welke dllhost gebruikt?

Wellicht wordt het tijd eens wat documentatie door te lezen Want als je niet weet wie IWAM_machinenaam is dan wordt het al knap complex.

Via tooltjes als HandleEx kun je bekijken welke dll's gemapped zijn in welke processen. (ook handig als je een COM component wilt updaten en die is gelocked door een proces). IIS start per webprocess een DllHost process op (zie manual) en daarin draaien de components binnen die website.

Alle scripts doorlopen is inderdaad nog al een heel karwei. Er draaien nu zo'n 20 websites op. Dus dat is wel pijnlijk. In ieder geval bedankt. Ik ga dit eens bekijken.

Ik zou je willen aanraden per website een apart process te laten draaien. (dus high isolated gebruiken binnen IIS). Zeker bij 3rd party components. Zodoende start IIS per website een DllHost op en daarbinnen worden de components gedraaid. Wil je een website uit memory halen MET components, dan is een unload actie binnen een website voldoende. Draai je alles binnen het IIS process dan moet je veelal het complete inetinfo process killen (of w3svc stoppen/starten).

Beheer wordt bij in-proc draaiende websites een stuk lastiger, zeker wanneer je een component wilt updaten dat door 1 enkele website wordt gebruikt: je kunt bij in=proc draaiende websites niet alleen die ene website uit memory halen PLUS het component (die blijft vrolijk cached in IIS).

[dusty]

Brakke modules gebruiken, niet zelf de objecten afsluiten.

Allemaal hetzelfde liedje voor veel ASP-ers.

[Greyfox]

Een memoryleak van 800Mb lijkt me aan de grote kant.
Ik kan me niet voorstellen dat dat de fout van een gekocht component is.
Als dat het geval is, zou ik de leverancier opbellen voor een verklaring.

Wat het ook zou kunnen zijn is dat je in een lusje een component aanmaakt (oid) en die niet meer vrijgeeft i.p.v. eenmalig aanmaken voordat je de lus in gaat.
Ook bij het doorlopen van een recordset is deze fout snel gemaakt.

[Bobco]

[disclaimer]ik heb in 2 jaar geen ASP gedaan[/disclaimer]

Kan er ook niet iets aan de hand zijn met sessies die erg lang blijven leven? En natuurlijk de tip die hierboven al tig keer gegeven is: wordt alles wel netjes gesloten?

[Verwijderd]

Ik denk dat ik maar eens ga isolaten. Lijkt mij de beste oplossing. Het rare is dat de code niet brak is. Alles is netjes in classes gebouwd, stored procedures gebruikt. Ik ben heel bang aan het worden dat het een van die ServerObjects is. Ik ga eens ff kijken.

[Verwijderd]

sessies gebruiken we bijna niet, bij afschermde stukken maar een. Verder ook netjes de DB koppling met een udl en het pad staat in een application. Ik dacht eerst dat die sessie's het probleem waren maar daar twijfel ik hard aan.
Ik ben echt bang dat het een fout is in een component.

[Basszje]

Op woensdag 03 april 2002 14:06 schreef dusty het volgende:
Brakke modules gebruiken, niet zelf de objecten afsluiten.

Allemaal hetzelfde liedje voor veel ASP-ers.

Met PHP kan dit natuurlijk niet gebeuren

[Verwijderd]

Op zo'n post zit ik niet te wachten

Kan me van PHP ook nog een redelijk recent BUG(je) herrineren. Of niet?

[dusty]

Op woensdag 03 april 2002 14:18 schreef Basszje het volgende:
[..]
Met PHP kan dit natuurlijk niet gebeuren

Zodra men externe programmatuur buiten PHP gaat gebruiken (wat in principe ASP modules ook zijn) kan het ook bij PHP gebeuren.

Prutser niveau van ASP-ers en PHP-ers is helaas even hoog.. schat rond de 95%.

[Verwijderd]

Op woensdag 03 april 2002 14:18 schreef Basszje het volgende:
[..]
Met PHP kan dit natuurlijk niet gebeuren

[meelijmode]
Nee, die moeten het zonder binary component object model doen
[/meelijmode]

[Verwijderd]

He Dusty moet ik me aangesproken voelen?

[SiNisTrAD]

is er nog wat uitgekomen uit je onderzoek? Wij hebben namelijk last van hetzelfde, de DLLHost groeit ook bij ons erg snel. Wij gebruiken ook: AspUpload van Persits, AspImage van ServerObjects en AspMail van ServerObjects

[Verwijderd]

Op woensdag 03 april 2002 11:44 schreef daxx909 het volgende:
Nee, we hebben niet de moeite genomen om dat tooltje te proberen. (Misschien kun je op MSDN zoeken?)
Voorlopig gewoon bv elke nacht/week/maand (afhankelijk van hoeveel last je ervan hebt) de server resetten, of overstappen op .NET

Praktische 'oplossing'
AT 3:00 "iisreset.exe"

[gotcha]

wij gebruiken ook aspupload en dat ding heeft nogal de neiging om tijdens het uploaden van files behoorlijk veel geheugen te gebruiken (rustig 2x de grootte van het te uploaden bestand). dit geldt overigens alleen als je de SaveToMemory-methode gebruikt. indien mogelijk kun je dan ook beter de SaveToFile methode gebruiken, die schrijft uploadstream direct naar schijf ipv alles eerst in je geheugen te laden.
over het vrijgeven van die geheugenruimte zegt persits niks. ik neem aan dat ie dit vrijgeeft zodra je file hebt opgeslagen op schijf, en bovendien bij het voltooien van de verwerking van de asp pagina. je moet er blijkbaar maar op vertrouwen dat het goed gaat, er is geen mogelijkheid om geforceerd geheugenruimte vrij te geven (upload.clear ofzo)
overigens heb ik zelf nog geen problemen gezien mbt geheugenlekken en aspupload (wel tal van andere problemen, maar da's offtopic...)