We zien veel fragmentatie van virtueel geheugen en fouten in het geheugen, waarna het de limiet van 3 GB bereikt.
De debug-compilatie is ingesteld op true in de web.config, maar ik krijg verschillende antwoorden van iedereen die ik vraag. Als debug is ingesteld op true, wordt elke aspx gecompileerd in willekeurige delen van de ram, waardoor die ram wordt gefragmenteerd en uiteindelijk onvoldoende geheugen ontstaat problemen?
Antwoord 1, autoriteit 100%
Scott Guthrie (manager van het ASP.NET-ontwikkelteam) heeft een interessante post erover.
De belangrijkste punten waarom je debug="true"niet moet verlaten zijn:
- De compilatie van ASP.NET-pagina’s duurt langer (aangezien sommige batchoptimalisaties zijn uitgeschakeld)
- Code kan langzamer worden uitgevoerd (aangezien sommige extra debug-paden zijn ingeschakeld)
- Er wordt veel meer geheugen gebruikt in de applicatie tijdens runtime
- Scripts en afbeeldingen die zijn gedownload van de WebResources.axd-handler worden niet door de browser in de cache opgeslagen, wat resulteert in meer verzoeken tussen
client en server
Hij noemt ook de vlag <deployment retail=”true”/> in machine.config, waarmee de debug=”true”-vlag globaal kan worden overschreven van alle toepassingen die op een machine worden uitgevoerd (bijvoorbeeld op een productieserver).
Update: het implementeren van web-apps met debug="true"is nog steeds slecht, zoals je kunt lezen in Recente blogpost van Scott Hanselman:
Dit is waarom debug=”true” slecht is. Serieus, we maken geen grapje.
- Overschrijft de time-out voor het uitvoeren van verzoeken, waardoor het in feite oneindig wordt
- Schakel zowel pagina- als JIT-compileroptimalisaties uit
- In 1.1 leidt dit tot overmatig geheugengebruik door de CLR voor het opsporen van foutopsporingsinformatie
- In 1.1 schakelt batchcompilatie van dynamische pagina’s uit, wat leidt tot 1 assembly per pagina.
- Voor VB.NET-code leidt dit tot overmatig gebruik van WeakReferences (gebruikt voor bewerken en continueren van ondersteuning).
Een belangrijke opmerking: in tegenstelling tot wat soms wordt gedacht, is setting
retail = “true” in een element is geen direct tegengif voor
met debug=”true”!
Antwoord 2, autoriteit 16%
De debug-vlag moet worden ingesteld op false in web.config, tenzij u de toepassing daadwerkelijk moet debuggen.
Het uitvoeren van de foutopsporingsmodus kan het geheugengebruik enigszins verhogen, maar het is waarschijnlijk niet zo’n groot probleem als waar u het over heeft. U moet het echter op false zetten om het effect dat het heeft te elimineren en te kijken of u enige verbetering kunt opmerken.
In de foutopsporingsmodus werkt de garbagecollection anders. De levensduur van variabelen wordt uitgebreid van het werkelijke gebruik naar het bereik van de variabele (om de waarde in de debugger te kunnen tonen). Hierdoor leven sommige objecten langer voordat ze worden ingezameld.
De compiler optimaliseert de code niet bij het compileren in debug-modus, en er worden ook enkele extra nop-instructies toegevoegd zodat elke coderegel ten minste één instructie heeft waar een breekpunt kan worden geplaatst.
Het maken van een uitzondering duurt aanzienlijk langer in de foutopsporingsmodus. (Normaal gesproken zou de code echter niet zo vaak uitzonderingen moeten genereren.)
Antwoord 3, autoriteit 5%
Het kan absoluut van invloed zijn op het geheugen, kijk maar eens naar enkele van de prestatietellers en voer een vergelijking uit met beide configuraties.
Als je site veel bestanden heeft, zou ik me meer zorgen maken over disk io in de map asp.net temp.
Paar vragen…
- Heeft u veel bestanden in uw App_Code?
- Staat u toe dat de site kan worden bijgewerkt of publiceert u deze?
- Zo ja, wordt de site regelmatig bijgewerkt of is er een implementatieproces?
- Wat is de hardwareconfiguratie?
Waarom niet meerdere configuraties gebruiken?
Web.Debug.Config – Foutopsporing ingeschakeld
Web.UAT.Config – Wat uw voorkeur ook is
Web.Release.Config – Foutopsporing uitschakelen
Op deze manier kunt u regressieconfiguratiefouten minimaliseren, zoals een ontwikkelaar die een web.config incheckt met debug=”true”
Antwoord 4, autoriteit 4%
AFAIK “debug = true” veroorzaakt niet de situatie die u noemde.
Ik had hetzelfde probleem met een ASP.NET-toepassing die on-the-fly afbeeldingen maakte.
Dus ik denk dat je een probleem hebt met niet-afgedankte bronnen.
Als u uw aspx-bestanden met code-behind-bestanden op de server implementeert. Het wordt één keer gecompileerd wanneer het verzoek bij een aspx komt. dan wordt het in de cache opgeslagen totdat het bestand verandert.
Antwoord 5
Stel op productiesystemen altijd Debug=false in. Zoals de vlag suggereert, mag deze alleen worden ingesteld op true bij het debuggen van een ontwikkelsysteem.
Deze vlag heeft niets te maken met uw geheugenfragmentatieprobleem.