Når oppstår et OutOfMemonryException? Hvis vi prøver å lage et nytt objekt og søppelsamleren ikke finner noe ledig minne, kan vi fange opp unntaket; Et annet tilfelle er at når CLR trenger minne og systemet ikke kan levere det, vil også unntaket bli kastet. Men på dette tidspunktet kan ikke applikasjonen vår fange feilen.
Debug-analyse av minneoverløp (OutOfMemoryException).
Adresseringsområdet til 32-bits operativsystemet er 4G, hvorav 2G er okkupert av operativsystemet, noe som betyr at minnet som er igjen for brukerprosessen kun er 2G (som også trekker fra deler av plassen som opptas av bildet når programmet lastes inn, vanligvis kan bare omtrent 1,6G~1,8G brukes). Hvis en prosess trenger å be om minne mens den kjører, og operativsystemet ikke kan tildele minneplass til den, vil den produsere et out-of-memory-unntak, System.OutOfMemoryException i .net (unntaket som kastes når det ikke er nok minne til å fortsette kjøringen av et program). Selv om den endelige manifestasjonen er OutOfMemoryException, kan årsaken være annerledes, og før dette problemet løses, er det nødvendig å analysere den nåværende minnebruksstatusen for prosessen for å finne riktig årsak før riktig medisin forskrives. Her er noen tips for å feilsøke slike problemer.
For mer informasjon, vennligst se til:http://blog.csdn.net/lazyleland/article/details/6704661
iis Application Pool Memory Overflow Error System.OutOfMemoryException
På en ASP.NET webserver er mengden minne ASP.NET kan bruke vanligvis ikke lik all mengden minne. I konfigurasjonsfilen machine.config <processModel>finnes det egenskapen "memoryLimit" i konfigurasjonsseksjonen, verdien av denne egenskapen er en prosentverdi, standard er "60", det vil si at ASP.NET-prosessen (du kan se ASP.NET-prosessen i oppgavebehandlingen, aspnet_wp i IIS5, w3wp i IIS6) kan bruke 60 % av alt fysisk minne. Når mengden minne brukt av ASP.NET overstiger denne grensen, vil IIS automatisk begynne å resirkulere prosessen, det vil si å opprette en ny prosess for å håndtere HTTP-forespørsler og gjenerobre minnet som den gamle prosessen opptok.
Når vi har en server med stort minne, må verdien av "memoryLimit" justeres riktig. For eksempel, hvis vi forbereder en server med chemas-microsoft-com tilstrekkelig marttags" />t="on"> 4G-minne, så t="on">4G×60%=t="on">2.4G. For Win32-operativsystemer er imidlertid all minneplassen en prosess kan oppta kun t="på">2G. Når minnet som opptas av ASP.NET-prosessen begynner å nå t="on">2G, fordi det ikke når "resirkuleringsterskelen" t="on">2.4G, vil ikke IIS starte resirkuleringsprosessen, men på grunn av begrensningene i Win32 er det faktisk umulig å tildele mer minne til denne prosessen, så OutOfMemoryException vil sannsynligvis bli kastet. For å unngå dette måtte vi redusere «memoryLimit» riktig slik at IIS kunne behandle resirkulering tidligere.
Microsoft anbefaler at ASP.NET prosessen ikke tar opp mer enn 60 % av minnet, og det er best å gjøre den beregnede faktiske verdien maks til t="on">800M. Når det er sagt, for en server med t="on" > 4G-minne, er det best å sette egenskapen "memoryLimit" til "20". Å sette en passende terskel for resirkulering slik at IIS kan resirkulere prosesser i tide er svært viktig for å sikre stabil drift av hele serveren og unngå OutOfMemoryException.
I IIS6 bestemmes ikke lenger resirkuleringsterskelen for ASP.NET prosesser av egenskapen "memoryLimit" i konfigurasjonsdelen, men av innstillingene i applikasjonspoolkonfigurasjonen i IIS Manager.
Men selv om disse konfigurasjonene settes riktig, er det ingen garanti for at OutOfMemoryExceptions vil bli fullstendig unngått, og årsakene kan være varierte og komplekse, slik at minnegjenvinningsoperasjoner kan være for tidkrevende. Utviklere bør alltid huske på å ikke bruke og kaste bort minne unødvendig i koden sin. :)
Hvis du har en server med stort minne og er frustrert over begrensningen ved å bruke t="på" >2G-minne i Win32-operativsystemet, finnes det to alternative løsninger:
- Start datamaskinen i /3GB-modus, og følg lenken etter artikkelen om metodedeltakelse
- Bruk Windows Server 2003 64bits Edition
Flere elementer for å unngå minneoverløp
Hvis du vil lage et array, sørg for at det er riktig størrelse.
Sørg for at du har nok minne til intern bruk og nye hostede objekter.
Hvis du programmerer på .NET Compact Framework, kaster den offentlige språkkjøretiden dette unntaket når det ikke er nok minne til intern bruk eller et nytt administrert objekt. For å unngå dette unntaket bør du unngå å skrive store metoder som tar opp 64KB eller mer minne.
Overdreven administrert minnebruk skyldes ofte:
- Les store datasett inn i minnet.
- Å lage for mange bufrede oppføringer.
- Last opp eller last ned store filer.
- Bruk for mange regulære uttrykk eller strenger når du analyserer filer.
- Overdreven visningsstatus.
- Det er for mye data eller for mange økter i session-tilstanden.
- Dette unntaket kan oppløses når en metode kalles på et COM-objekt og metoden returnerer en brukerdefinert type som inneholder et sikkert array (et array med ubestemte størrelser) med en ekstra melding "Ikke nok lagringsplass til å fullføre denne operasjonen". Dette er fordi .NET-rammeverket ikke kan samle strukturelle felt med sikre arraytyper.
Et eksempel på et minneoverløp forårsaket av feil bruk av bytematriser
Hvis utdatafilen er spesielt stor, kan den rapportere System.OutOfMemoryException direkte. Den riktige måten å gjøre dette på er å sende ut bytestrømmen av filen i segmenter, men det finnes asp.net ferdiglaget metode Response.WriteFile(filePath) som gjør nettopp det.
Følgende er den riktige måten å skrive på:
Når en asp.net opplever et minneoverløp, er en enkel måte å håndtere det på å gjenerobre applikasjonspoolen med en gang. Men dette løste ikke problemet helt.
Minneoverløp ved opprettelse av en bildetype (System.OutOfMemoryException)
Feilkode: System.Drawing.Image myimg=System.Drawing.Image.FromFile(file. FullName);
Unntak som kastes når en åpen fil ikke er en bildefil:
MSDN: Denne metoden kaster et OutOfMemoryException-unntak hvis filen ikke har et gyldig bildeformat, eller hvis GDI+ ikke støtter filens pikselformat.
Slik unormal informasjon er lett misvisende.
<processModel> Element
Konfigurer innstillingene for ASP.NET prosessmodell på Internet Information Services (IIS) webserveren. Seksjonen kan kun settes i Machine.config-filen <processModel> , og den påvirker alle ASP.NET applikasjoner som kjører på serveren.
Advarsel For informasjon om dette elementet, vennligst les seksjonen «Notater».
Eksempel på konfigurasjon av strukturen:
Eksegese
Det administrerte kodekonfigurasjonssystemet leser ikke <processModel> konfigurasjonsinnstillingene. I stedet leses den direkte av den uadministrerte DLL-aspnet_isapi.dll. Endringene i denne seksjonen trer i kraft etter at du starter IIS på nytt.
Hvis du installerer ASP.NET på en domenekontroller, må du ta spesielle skritt, ellers vil ikke installasjonen fungere. For mer informasjon, se Lokalisert ihttp://support.microsoft.comMicrosoft-artikkelen i Knowledge Base CHS315158 «ASP.NET kan ikke bruke standard ASPNET-konto på domenekontrollere».
Når ASP.NET kjører i IIS versjon 6 native modus, bruker den IIS 6 prosessmodellen og <processModel> ignorerer innstillingene i seksjonen. For å konfigurere prosessidentitet, resirkulering eller andre prosessmodellverdier, bruk brukergrensesnittet til Internet Services Manager for å konfigurere IIS-arbeidsprosesser for applikasjonen din.
Tidsverdien er formatert som "timer:minutter:sekunder". Hvis bare ett tall gis uten kolon, antas verdien å være minutter; Derfor tilsvarer timeout="4" timeout="00:04:00".
Hvis et ASP.NET program får ASP.NET arbeidsprosesser (Aspnet_wp.exe på Windows 2000 og Windows XP Professional og W3wp.exe på Windows Server 2003) til å starte på nytt og gir en feilmelding som indikerer at omstarten skyldes en mistenkt fastlåst tilstand, bør den øke responseDeadlockInterval-innstilling.
Lagre brukernavn og passord i registeret
Lagre brukernavn og passord i registeret
For å kryptere brukernavn og passord og lagre dem i registeret, sett brukernavn og passord som følger.
brukernavn="registry:HKLM\Software\AspNetProcess,Name"
password="registry:HKLM\Software\AspNetProcess,Pwd"
Den delen av strengen som kommer etter nøkkelordregisteret og før kommaet angir navnet på registernøkkelen som ASP.NET åpnes. Delen etter kommaet inneholder et strengverdinavn som ASP.NET vil lese legitimasjonen fra. Kommaer kreves, og legitimasjon må lagres i HKLM-konfigurasjonsenheten. Hvis konfigurasjonen er feilformatert, vil ASP.NET ikke starte arbeidsprosessen og vil deretter dukke opp i veien for den nåværende kontoopprettelsesfeilkoden.
Legitimasjonen må være i REG_BINARY format og inneholde utdataene fra et kall til Windows API-funksjonen CryptProtectData. Du kan opprette og lagre krypteringsinformasjon i registeret med ASP.NET Settings Registry Console (Aspnet_setreg.exe), som bruker CryptProtectData for å fullføre krypteringen. For å laste ned kildekoden til Aspnet_setreg.exe og Visual C++ og hjelp, besøk nettsidenwww.asp.netog søk etter "aspnet_setreg".
Du bør konfigurere tilgang til registernøklene som lagrer krypterte legitimasjoner slik at tilgangen kun er tilgjengelig for administratorer og SYSTEM. Siden registernøkkelen vil bli lest av den ASP.NET prosessen som kjører som SYSTEM, bør du sette følgende tillatelser:
Administrators:F
SYSTEM:F
SKAPEREIER: F
ProcessAccount:R
Dette vil gi to forsvarslinjer for å beskytte data:
ACL-tillatelser krever tilgang til data med administratorens identitet.
Angriperen må kjøre kode (CryptUnprotectData) på serveren for å gjenopprette kontoens legitimasjon.
eksempel
Følgende eksempel spesifiserer flere <processModel> konfigurasjonsinnstillinger.
Følgende eksempel spesifiserer at det krypterte brukernavnet og passordet lagres under registerets brukerdefinerte element AspNetProcess.
Krav
- Inkludert i: <system.web>
- Nettplattform: IIS 5.0, IIS 5.1, IIS 6.0
- Konfigurasjonsfiler: Machine.config, Web.config
- Konfigurasjonsseksjonshåndterer: System.Web.Configuration.ProcessModelConfigurationHandler
http://doc.51windows.net/iismmc/ ... essmodelelement.htm
|
Publisert på 14.03.2019 21:47:39
|
|
|
|
