[ASP] memory lek

[Verwijderd]

Ik heb een beetje vreemde situatie mijn windows 2000 server loopt regelmatig vast. Ongeveer 50 tot 100 gebruikers zijn op hetzelfde moment online in een ASP applicatie, deze applicatie maakt gebruik van SQL server 2000 op een aparte windows 2000 server. Deze server werkt goed kan alle verzoeken gemakkelijk aan en loopt nooit vast.

De windows 2000 server loopt echter de laatste dagen regelmatig vast, we hebben een behoorlijke update gedaan, hiervoor hadden wij eigenlijk nooit problemen.

De belangrijkste wijziging in deze update zit hem in het niet meer gebruik maken van de scripting object module van Visual Interdev. We gebruiken deze nog op bepaalde plaatsten, nu gebruiken wij voornamelijk de ADO connection en recordsets.

Is het mogelijk dat de combinatie tussen deze twee methoden problemen kan veroorzaken?

De server waarop de ASP pagina's draaien is een windows 2000 met 2 Gig intern geheugen, ruim 10 Gig vrije schijfruimte, een dual 1 Gig processor.

Indien nog meer specificaties nodig zijn, vraag je maar, wie helpt mij verder?

[Verwijderd]

Overigens sluiten we ieder object dat wij creeren netjes en sluiten het af met Set object = nothing, connecties openen met de juiste parameters voor de connection pooling

[NMe]

Ik ben zelf vorige week toevallig tegen eenzelfde probleem aangelopen. Zonder code kan ik je niet zeggen waar het bij jou aan ligt, maar bij mij kwam het door het niet opruimen van (ADO-/recordset-/enz)objecten vlak voor het response.redirecten naar een andere pagina. Daarop zou ik even controleren als ik jou was, en bovendien kun je natuurlijk controleren of een object überhaupt wel opgeruimd wordt.

Waar je ook op kan controleren is het aantal objecten dat je op een bepaald moment aangemaakt hebt. 200 ADO objecten open hebben op een bepaald moment is niet echt gunstig.

[ Voor 18% gewijzigd door NMe op 19-04-2004 20:00 ]

[Freee!!]

Mag ik je even wijzen op dit knopje

[Jaspertje]

NMe84 schreef op 19 april 2004 @ 19:59:
Ik ben zelf vorige week toevallig tegen eenzelfde probleem aangelopen. Zonder code kan ik je niet zeggen waar het bij jou aan ligt, maar bij mij kwam het door het niet opruimen van (ADO-/recordset-/enz)objecten vlak voor het response.redirecten naar een andere pagina. Daarop zou ik even controleren als ik jou was, en bovendien kun je natuurlijk controleren of een object überhaupt wel opgeruimd wordt.

Waar je ook op kan controleren is het aantal objecten dat je op een bepaald moment aangemaakt hebt. 200 ADO objecten open hebben op een bepaald moment is niet echt gunstig.

Is het niet zo dat IIS dat vanzelf opruimt net voor een response.redirect?
- Hoeveel sessies gebruik je per user?
- Crasht ie echt omdat het memory volzit?
- Kijk bij SQL Server eens naar de profiler.

[NMe]

Jaspertje schreef op 19 april 2004 @ 20:06:
Is het niet zo dat IIS dat vanzelf opruimt net voor een response.redirect?

Daar ging ik inderdaad ook vanuit, totdat me door de beheerder van de server verteld werd dat dit niet het geval is. Na het aanpassen van de betreffende code heb ik geen vastloper meer gezien... Trouwens, volgens MS maakt IIS sowieso na het einde van het script het geheugen weer schoon, en daar is ook geen woord van waar...

[gorgi_19]

NMe84 schreef op 19 april 2004 @ 20:08:
[...]

Daar ging ik inderdaad ook vanuit, totdat me door de beheerder van de server verteld werd dat dit niet het geval is. Na het aanpassen van de betreffende code heb ik geen vastloper meer gezien... Trouwens, volgens MS maakt IIS sowieso na het einde van het script het geheugen weer schoon, en daar is ook geen woord van waar...

Je moet natuurlijk wel kijken wat IIS op kan ruimen en wat niet.. Sommige zaken kan IIS niet opruimen.

[Verwijderd]

Trouwens, volgens MS maakt IIS sowieso na het einde van het script het geheugen weer schoon, en daar is ook geen woord van waar...

Helemaal mee eens

dit is overigens een klein stukje code, openen, en sluiten van een query in een functie

code:

    Dim oConnection, oRecordSet
    Dim strSQL
    
    Set oConnection = Server.CreateObject("ADODB.Connection")
    Set oRecordSet = Server.CreateObject("ADODB.RecordSet")

    oConnection.ConnectionTimeout   = Application("cnKennisnet_ConnectionTimeout")
    oConnection.CommandTimeout      = Application("cnKennisnet_CommandTimeout")
    oConnection.CursorLocation      = Application("cnKennisnet_CursorLocation")

    Call oConnection.Open(Application("cnKennisnet_ConnectionString"), Application("cnKennisnet_RuntimeUserName"), Application("cnKennisnet_RuntimePassword"))

strSQL = "bla bla bla FROM.."

    oRecordSet.CacheSize        = 10
    oRecordSet.CursorLocation   = 3
    Call oRecordSet.Open(strSQL, oConnection, adOpenForwardOnly, adLockReadOnly)

    If Not oRecordSet.EOF And Not oRecordSet.BOF Then
        getData = oRecordSet.GetRows()
    Else
        getData = Null
    End If
    
    Call oRecordSet.Close()
    Call oConnection.Close()
    
    Set oRecordSet  = Nothing
    Set oConnection = Nothing

[Verwijderd]

- Hoeveel sessies gebruik je per user?
- Crasht ie echt omdat het memory volzit?
- Kijk bij SQL Server eens naar de profiler.

1 sessie per gebruiker +/- 75 sessies tegelijk, timout 20 minuten

de crash log is:
.........|0|800a03e9|Out_of_memory|646|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Invalid_column_name_'CssClass'. 500 0 949 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0).........

[Verwijderd]

Waar je ook op kan controleren is het aantal objecten dat je op een bepaald moment aangemaakt hebt. 200 ADO objecten open hebben op een bepaald moment is niet echt gunstig.

Is er een goede methode om te controleren welke objecten je op dat moment nog open hebt (eventueel wat door andere gebruikers open is?

Ik zou bijvoorbeeld een poosje in de site kunnen rondklikken en dan zien wat eventueel open blijft. We hebben vanochtend ongeveer 500 bestanden doorgewerkt om te controleren of ergens nog de connectie niet werd afgesloten.

Ik denk echter eerder dat het in de combinatie Scripting Object Module van Visual Interdev ligt.

modbreak:
Mag ik je even wijzen op het bestaan van de edit-functie? Het is nl. niet nodig om steeds opnieuw nieuwe posts te maken als je nog iets aan je vorige post wilt toevoegen.
Daarbij leest het ook irritant als je 3x onder elkaar een reply hebt staan van eenzelfde persoon

[ Voor 20% gewijzigd door whoami op 19-04-2004 20:22 ]

[NMe]

Misschien een global op applicatieniveau ergens? Maar ik had het eigenlijk over het kijken hoe vaak je een object aanmaakt binnen één file. Misschien maak je ergens binnen een recursieve functie steeds een nieuw object aan ofzo. Stel dat die functie per gebruiker 100 keer doorlopen wordt, en er op een bepaald moment 40 gebruikers online zijn, dan heb je op een slecht moment wel 4000 van die objecten in je geheugen staan. Dan kun je in je code wel netjes opruimen, maar als de server voor de opruimende regel vastloopt, dan heb je daar ook niet veel aan...

[pistole]

Verwijderd schreef op 19 april 2004 @ 20:16:
[...]


1 sessie per gebruiker +/- 75 sessies tegelijk, timout 20 minuten

de crash log is:
.........|0|800a03e9|Out_of_memory|646|80040e14|[Microsoft][ODBC_SQL_Server_Driver][SQL_Server]Invalid_column_name_'CssClass'. 500 0 949 Mozilla/4.0+(compatible;+MSIE+6.0;+Windows+NT+5.0).........

weet je zeker dat de "out of memory" bij IIS vandaan komt? Het lijkt bijna wel een SQL Server melding.
En bij out of memory meldingen moet ik altijd aan oneindige loops denken...

zoeken bij microsoft op 800a03e9 levert 3 min of meer relevante artikelen op...

[ Voor 26% gewijzigd door pistole op 20-04-2004 00:08 ]

[Verwijderd]

weet je zeker dat de "out of memory" bij IIS vandaan komt? Het lijkt bijna wel een SQL Server melding.
En bij out of memory meldingen moet ik altijd aan oneindige loops denken...

Als je die melding ziet zou je dat inderdaad denken, echter het vreemde is dat wij de SQL Server en IIS als twee gescheiden systemen hebben draaien en de IIS de geen is die er mee op houdt.

[pistole]

Verwijderd schreef op 20 april 2004 @ 08:26:
[...]


Als je die melding ziet zou je dat inderdaad denken, echter het vreemde is dat wij de SQL Server en IIS als twee gescheiden systemen hebben draaien en de IIS de geen is die er mee op houdt.

check even je IIS logs, naar requests die misschien overdreven lang duren (zorg dat je die kolom in je iis logs hebt), misschien dat die in de richting van een script wijzen dat de fout veroorzaakt.

[farlane]

Lijkt me meer een melding van de DB driver die je gebruikt. Waarom gebruik je eigenlijk geen OLEDB driver ipv de ODBC driver ( tenminste aan de melding te zien gebruik je een ODBC driver ) ?

[Verwijderd]

farlane schreef op 20 april 2004 @ 09:02:
Lijkt me meer een melding van de DB driver die je gebruikt. Waarom gebruik je eigenlijk geen OLEDB driver ipv de ODBC driver ( tenminste aan de melding te zien gebruik je een ODBC driver ) ?

Is het gebruik van een OLEDB driver aan te raden boven een ODBC driver dan?


Zoals ik bovenaan dit topic al meldde gebruiken wij de Scripting Object Module van Visual Interdev, welke gebruik maakt van ODBC (zie ik net) en een ADO connectie met een OLEDB in de global.asa, zou zoiets zoveel problemen kunnen veroorzaken?

[ Voor 26% gewijzigd door Verwijderd op 20-04-2004 09:32 ]

[farlane]

Ik weet niet of dit een oorzaak zou kunnen zijn, maar de melding lijkt me van de ODBC driver vandaan te komen.

Volgens mij kun je vrij simpel een OLEDB driver gebruiken ; het is alleen een kwestie van je connection string aanpassen. ( dwz als je geen SQL instructies hebt gebruikt die niet ondersteund worden door de OLEDB driver, maar dat lijkt me sterk )

[edit]

Is het gebruik van een OLEDB driver aan te raden boven een ODBC driver dan?

Ligt er aan van waaruit je start : als je ADO gebruikt is de weg naar ODBC langer dan de weg met een OLEDB driver. Je maakt dan gebruikt van een OLEDB naar ODBC bridge driver.

Een directe koppeling met ODBC ( zal wel een SDK voor zijn ) zal waarschijnlijk sneller zijn ( gevoelsmatig ), maar een stuk bewerkelijker.

[ Voor 38% gewijzigd door farlane op 20-04-2004 10:12 ]