Hej

Vi hade ett stort system som använde sig av classic ASP och VB6 com komponenter som fungerade bra.

systemet är nästan stort (databassen mest) men nu när vi har uppgraderat VB6 komponterna till .NET komponenter, den har blivit mycket långsamt och även oftast får man out of memory exception.

det är så att vi hade en class som cachade allting men nu den växer och växer till minnet tar slut. men varför minnet tog inte slut tidigare (innan migreringen)???

tack för hjälpen.

Om ni har kodat om det till .NET och du nu får out of memory exeception så är mitt största tips att ni helt enkelt har gjort en bug i er kod. Det mesta av .NET egna komponenter och objekt städar GC upp till er, men om ni glömmer stänga databaskopplingen så kommer detta inte kunna stängas av GC och om du har andra objekt som typ fil objekt så måste du göra Close() / Dispose() på dessa objekt för att du skall städa upp efter dig.

Generellt kan man säga att finns det en Dispose()/Close() funktion på klassen du använder så skall du alltid kalla på den när du är färdig med din kod.

En annan sak som många missar är om man öppnar typ sin databas i sin kod och något går fel och det kastas ett fel tillbaka så kommer din databaskoppling aldrig stängas (fören ditt program stängs) så vid sådant komponenter så är using() insktuktionen bra att använad, eller åtminsonde try-catch-finally.

Det kan också vara så att du råkat göra en rekursiv loop som aldrig tar slut, då får du också out-of-memory.

Men allt detta är ju lätt att se om man kör TDD och har ordentliga testar till sin kod :)

- M

TACK,

Vi fortffarande använder ADODB och har inte gått över till Ado.net, kan det åstadkomma något minnes leckage.

egnetligen vi har inte ändrat mycket på koden, en av mina kollegor har ändrat våran Cache klass ( den som cachar). Vi har inte använt dispose/close alls.

En egen cache klass är ett ställe där man välsigt lätt kan få minnesläckor.

Helt enkelt att om du har ett object som du lägger i cachen och inte plockar bort det från cachen så kommer .NET aldrig att ta bort objektet som ni kanske tror är borta.

- M

Är det bara komponenterna ni bytt till .net ?
returnerar dina .net komponenter adodb recordsets till klassiska asp sidor ?

ta en titt på Tess Ferrandes debugging labbar om minnes läckor finns ett verktyg som heter debugg diag som du kan använda för att analysera ditt problem.

http://blogs.msdn.com/tess/archive/2008/03/17/net-debugging-demos-lab-6-memory-leak.aspx

det är bara komponenterna som har bytts till .net och adodb returnerar string i form av xml.

tack för länken men man oftast tagit pratat om något debugg verktyg för .net ramverket, i vårt fall problemet ligger i Com och det är inte .net ramverket. tror jag.

Hej Robert,

Kolla om du kör med rätt thraeding model. Om du har missmatch (dvs COM är MTA, och din kod är STA, eller tvärtom) då skappas den här problemet pga av marshalering av parametrar.

Mvh,
Tibi

tack Tiberiu

MTA och STA verkar vara lite överkurs för mig. jag vet bara att det är något om Multi eller single trådad com.

vi har ibland asyncrona anropp inne i com men jag vet inte hur man jemför om com är sta och vår kod är MTA eller tvärtom.

det är så att systemet funkar bra men vi vet inte vad händer som i ett visst tid den börjar käka minnet. Vi löste problemet genom att under properties -> pooling vi ändrade pooling till 4 st. och ändrade recycling time från 15 minuter till 1 och max minne till 400 mb. nu när en av poolarna börjar käka minnet och går till 400 mb efter en minut den recyclas och en annan pool börjas.
är det rätt lösning?

Hej Robert,

om det hjäper, då är det rätt lösning. :)

Tibi

Det är en lösning på symptomen inte på problemet, problemet är ju att poolen går till 400 MB och en lösning är att ni hittar var någonstans som det äter minne och rättar det. Men det är ju inte det lättaste, så ni har ju fått en tillfällig lösning tills ni hittat problemet!

- M

Min gissning är att problemet ligger i att ni inte använder COM komponenter på rätt sätt i .Net.

Det gäller att tänka på att .Net inte lämnar tillbaka objekten automatiskt när man slutar använda dem.

I klassisk VB gör man ungefär så här (kommer inte ihåg exakt):

dataset.Tables("xxx").Fields("blabla").Value = "zzz"

Det som händer i bakgrunden är:
1. .Tables skapar ett TableCollection objekt
2. ("xxx") skapar ett Table objekt
3. .Fields skapar en FieldCollection objekt
4. ("yyy") skapar ett Field objekt

Total 4 COM objekt. I klassisk VB är det inget problem eftersom de automatiskt frigörs.

I .Net kommer objekten att hänga kvar tills GC:n får för sig att rensa eller att man gör det manuellt.

Ovanstående skulle då se ut så här:

ITableCollection itc;
ITable it;
IFieldsCollection ifc;
IField if;
try {
itc = dataset.Tables;
it = itc("xxx");
ifc = it.Fields;
if = ifc("yyy");
if.Value = "zzz";
}
finally {
if (if != null) Marshal.ReleaseComObject(if);
if (ifc != null) Marshal.ReleaseComObject(ifc);
if (it != null) Marshal.ReleaseComObject(it);
if (ifc != null) Marshal.ReleaseComObject(itc);
}

Glöm inte att cast i .Net kan skapa en ny referens till objektet.

IWhatEvever x = new IWhatEver();
y = ((ISomethingElse)x).Value;

skapar 2 referenser till x (en till interfacet IWhatEver och en till ISomethingElse) så man måste anropa ReleaseComObject 2 gånger (alternativt FinalReleaseComObject). Det är dock lite lurigt eftersom .Net endast skapar en referens per interface.

tack alla,

nu har jag två funderingar,

om i en av .net com componenter skapar jag en instance av andra t.ex. Facade.Question objQuestion = new Facade.Question();

Räcker det inte att kallar på objQuestion.Dispose() ??

andra, när vi migrerade till vb.net och sedan till C#, skapade den inte något konstroktur till klasserna. Skapar det något problem?

tack igen

"Räcker det inte att kallar på objQuestion.Dispose() ?? "

Det beror på vad du menar, du har gjort vad du kan. Men GC är en hel vetenskap och ditt objekt försvinner inte ur minnet när du kallar på Dispose() utan objekt kommer att bli flagat som att det är okej för GC att ta bort det när GC tycker att den behöver mer minne (tror jag det var, det är typ 3 år sedan jag läste på om GC). Om du vill vara helt säker så får du säga till GC själv att den skall tömma sig på minne, men generellt så bör man inte göra det, eftersom GC har bättre koll än du när den behöver tömmas...

"andra, när vi migrerade till vb.net och sedan till C#, skapade den inte något konstroktur till klasserna. Skapar det något problem?"

Nej det skapar inga problem, det finns en default konstruktor till alla dina klasser som du kan använda även om du inte skapar en själv.

- M