|
|
Közzétéve 2019. 03. 14. 21:47:39
|
|
|
|

Mikor következik be OutOfMemonryException? Ha megpróbálunk új objektumot létrehozni, és a szemetgyűjtő nem talál szabad memóriát, elkaphatjuk a kivételt; Egy másik eset, hogy amikor a CLR-nek memóriára van szüksége, és a rendszer nem tudja biztosítani, akkor a kivétel is megjelenik. De jelenleg a jelentkezésünk nem tudja észrevenni a hibát.
Memória túlcsordulás hibakeresési elemzése (OutOfMemoryException).
A 32 bites operációs rendszer címezési területe 4G, amelyből a 2G az operációs rendszer foglalja el, ami azt jelenti, hogy a felhasználói folyamat számára maradt memória csak 2G (ami a program betöltésekor a kép által foglalt hely egy részét is levonja, általában csak körülbelül 1,6G~1,8G használható). Ha egy folyamatnak memóriát kell kérnie futás közben, és az operációs rendszer nem tud számára memória helyet foglalni, akkor egy memóriakívüli kivételt generál, a System.OutOfMemoryException in .net (az a kivétel, amelyet akkor dobnak be, ha nincs elég memória a program végrehajtásához). Bár a végső megnyilvánulás az OutOfMemoryException, az ok más lehet, és a probléma megoldása előtt szükséges elemezni a folyamat aktuális memóriahasználati állapotát, hogy megtaláljuk a helyes okot, mielőtt felírnánk a megfelelő gyógyszert. Íme néhány tipp az ilyen problémák hibakeresésére.
További információért kérjük, lásd:http://blog.csdn.net/lazyleland/article/details/6704661
iis Application Pool memória túlcsordulási hibarendszer.OutOfMemoryException
Egy ASP.NET webszerveren a ASP.NET által használt memória általában nem egyezik meg az összes memória mennyiségével. A machine.config konfigurációs fájlban <processModel>van egy "memoryLimit" tulajdonság a konfigurációs szakaszban, ennek az értéke százalékos érték, az alapértelmezett érték "60", vagyis a ASP.NET folyamat (a feladatkezelőben ASP.NET folyamatot láthatod, aspnet_wp IIS5-ben, w3wp az IIS6-ban) a fizikai memória 60%-át használhatja. Amikor az ASP.NET által használt memória mennyisége meghaladja ezt a korlátot, az IIS automatikusan újrahasznosítja a folyamatot, vagyis létrehoz egy új folyamatot a HTTP kérések kezelésére, és visszafoglalja a régi folyamat által foglalt memóriát.
Ha egy szerverünk nagy memóriával rendelkezik, a "memoryLimit" értékét megfelelően kell módosítani. Például, ha egy szervert készítünk elő chemas-microsoft-com ffice marttags" />t="on"> 4G memóriával, akkor t="on">4G×60%=t="on">2.4G. Azonban Win32 operációs rendszereknél az összes memóriahely, amit egy folyamat elfoglalhat, csak t="on">2G áll. Amikor a ASP.NET folyamat által elfoglalt memória eléri a t="on">2G értéket, mivel nem éri el a t="on">2.4G "újrahasznosítási küszöböt", az IIS nem indítja el az újrahasznosítási folyamatot, de a Win32 korlátai miatt valójában lehetetlen több memóriát biztosítani ehhez a folyamathoz, így valószínűleg az OutOfMemoryException eldobható. Ennek elkerülése érdekében megfelelően kellett csökkentenünk a "memoryLimit"-et, hogy az IIS korábban feldolgozhassa az újrahasznosítást.
A Microsoft azt javasolja, hogy ASP.NET folyamat ne foglalja el a memória 60%-át, és a legjobb a számított tényleges értéket legfeljebb t="on">800M-nél t="on"800M-nél tegyék. Ugyanakkor egy t="on" > 4G memóriával rendelkező szerver esetén a "memoryLimit" tulajdonságot "20"-ra állítjuk be. Nagyon fontos egy megfelelő újrahasznosítási küszöb beállítása az IIS számára, hogy időben újrahasznosítsa a folyamatokat, hogy biztosítsuk az egész szerver stabil működését és elkerüljük az OutOfMemoryException-t.
Az IIS6-ban ASP.NET folyamatok újrahasznosítási küszöbértékét már nem a konfigurációs szekcióban található "memoryLimit" tulajdonság határozza meg, hanem az IIS Manager alkalmazáspool konfigurációjának beállításai.
Azonban, még ha ezek a konfigurációk helyesen is be vannak állítva, nincs garancia arra, hogy az OutOfMemoryExceptions teljesen elkerülhető, és az okok változatosak és összetettek lehetnek, például a memória visszatöltési műveletek túl időigényesek lehetnek. A fejlesztőknek mindig szem előtt kell tartaniuk, hogy ne használják és pazarolják a memóriát a kódjukban. :)
Ha van egy szervered nagy memóriával, és frusztrálja a t="on" >2G memória használata a Win32 operációs rendszerben, két alternatív megoldás létezik:
- Indítsd el a számítógépet /3GB módban, és kövesd a linket a módszer részvételi cikk után
- Használd Windows Server 2003 64bits Edition-t
Több elem a memóriatúlcsordulás elkerülésére
Ha tömböt akarsz létrehozni, győződj meg róla, hogy a megfelelő méretű legyen.
Győződj meg róla, hogy legyen elég memóriád belső használathoz és új hostelt objektumokhoz.
Ha a .NET Compact Framework-en programozol, a nyilvános nyelvi runtime ezt a kivételt adja, ha nincs elég memória belső használathoz vagy új menedzselt objektumhoz. Ennek elkerülésére kerüld a nagy metódusokat írni, amelyek 64KB vagy annál nagyobb memóriát foglalnak.
A túlzott menedzselt memóriahasználatot gyakran az oka:
- Olvasd fel a nagy adathalmazokat a memóriába.
- Túl sok gyorsítótározott bejegyzést hoznak létre.
- Tölts fel vagy tölts le nagy fájlokat.
- Túl sok reguláris kifejezést vagy stringet használj fájlok elemzésekor.
- Túlzott nézeti állapot.
- Túl sok adat vagy túl sok ülés van az ülésállapotban.
- Ez a kivétel akkor merülhet fel, ha egy metódusot egy COM objektumon hívnak meg, és a metódus egy felhasználó által definiált típust ad vissza, amely biztonságos tömböt (határozatlan méretű tömböt) tartalmaz, további üzenettel: "Nincs elég tárolóhely ennek a műveletnek a befejezéséhez". Ennek oka, hogy a .NET keretrendszer nem tudja rendszerezni a strukturális mezőket biztonságos tömbtípusokkal.
Egy példa egy memóriatúlterhelésre, amelyet a bájttömbök helytelen használata okoz
Ha a kimeneti fájl különösen nagy, közvetlenül jelentheti a System.OutOfMemoryException fájlt. A helyes módja, ha a fájl bájtfolyamát szegmensekben adjuk ki, de létezik asp.net kész módszer, a Response.WriteFile(filePath), ami pontosan ezt teszi.
Az alábbiakban a helyes írásmód:
Amikor egy asp.net memóriatúlterhelést tapasztal, egy egyszerű megoldás, ha azonnal visszaszerezzük az alkalmazáskészletet. De ez nem oldotta meg teljesen a problémát.
Memóriatúlterhelés képtípus létrehozásakor (System.OutOfMemoryException)
Hibakód: System.Drawing.Image myimg=System.Drawing.Image.FromFile(file. Teljes név);
Kivételek, amelyek akkor kerülnek létre, ha egy nyitott fájl nem képfájl:
MSDN: Ez a módszer OutOfMemoryException kivételt ad meg, ha a fájl nem érvényes képformátumú, vagy ha a GDI+ nem támogatja a fájl pixel formátumát.
Az ilyen rendellenes információk könnyen félrevezetőek.
<processModel> elem
Konfigurálja a ASP.NET folyamatmodell beállításait az Internet Information Services (IIS) webszerverén. A szakasz csak a Machine.config fájlban állítható, <processModel> és az összes szerveren futó ASP.NET alkalmazást érint.
Figyelmeztetés Erről az elemről információért kérjük, olvassa el a "Jegyzetek" szekciót.
Példa a szerkezet konfigurálására:
egzegézis
A kezelt kódkonfigurációs rendszer nem olvassa <processModel> fel a konfigurációs beállításokat. Ehelyett közvetlenül a kezeletlen DLL aspnet_isapi.dll olvassa fel. A változások ebben a részben akkor lépnek életbe, amikor újraindítod az IIS-t.
Ha ASP.NET telepítesz egy domain kontrollerre, különben a telepítés nem fog működni. További információért lásd: Hely inhttp://support.microsoft.comA Microsoft cikke a Knowledge Base-ben CHS315158 "ASP.NET nem használhatod az alapértelmezett ASPNET fiókot domainvezérlőkön".
Amikor ASP.NET IIS 6-os verziójú natív módban fut, az IIS 6 folyamatmodellt használja, és figyelmen kívül <processModel> hagyja a szekcióban szereplő beállításokat. A folyamatidentitás, újrahasznosítás vagy más folyamatmodell értékek konfigurálásához használja az Internet Services Manager felhasználói felületét az IIS munkafolyamatok konfigurálásához az alkalmazásához.
Az időérték úgy van formázva: "óra:perc:másodperc". Ha csak egyetlen számot adunk meg kettős nélkül, akkor az értéket perceknek számítjuk; Ezért az időkérés="4" egyenértékű a timeout="00:04:00"-val.
Ha egy ASP.NET alkalmazás ASP.NET munkafolyamatokat (Aspnet_wp.exe Windows 2000-en és Windows XP Professional-on, valamint W3wp.exe Windows Server 2003-on) újraindítja, és hibaüzenetet ad ki, jelezve, hogy az újraindítás gyanús holtpont miatt van, akkor nőnie kell responseDeadlockInterval beállítás.
Tárold a felhasználóneveket és jelszavakat a nyilvántartásban
Tárold a felhasználóneveket és jelszavakat a nyilvántartásban
A felhasználónevek és jelszavak titkosításához, valamint a nyilvántartásban való tárolásához állítsd be a felhasználónevet és jelszót az alábbiak szerint.
userName="registry:HKLM\Software\AspNetProcess,Name"
password="registry:HKLM\Software\AspNetProcess,Pwd"
A láncsorban a kulcsszó registry után és a vessző előtt megjelenő rész jelzi a ASP.NET megnyitott regiszterkulcs nevét. A vessző utáni rész tartalmaz egy string érték nevet, amelyből a ASP.NET olvassa fel a hitelesítéseket. Vesszőt kell használni, és a hitelesítéseket a HKLM konfigurációs egységben kell tárolni. Ha a konfiguráció rosszul van formázva, ASP.NET nem indítja el a munkafolyamatot, és később megjelenik a jelenlegi fiók létrehozási hibakód útvonalán.
A hitelesítéseknek REG_BINARY formátumban kell lenniük, és tartalmazniuk kell a Windows API funkció CryptProtectData hívásának kimenetét. Titkosítási hitelesítéseket hozhat létre és tárolhatod a nyilvántartásban a ASP.NET Settings Registry Console alkalmazással (Aspnet_setreg.exe), amely a CryptProtectData segítségével fejezi be a titkosítást. A Aspnet_setreg.exe és a Visual C++ forráskód letöltéséhez és segítségéhez látogasson el a weboldalrawww.asp.netés keress rá a "aspnet_setreg" szóra.
Be kell állítani a hozzáférést a titkosított hitelesítési adatokat tároló regisztrációs kulcsokhoz úgy, hogy a hozzáférés csak az adminisztrátorok és a SYSTEM számára legyen elérhető. Mivel a regisztrációs kulcsot a SYSTEM-ként futó ASP.NET folyamat fogja olvasni, a következő jogosultságokat kell beállítani:
Administrators:F
SYSTEM:F
ALKOTÓ TULAJDONOS: F
ProcessAccount:R
Ez két védelmi vonalat biztosít az adatok védelmére:
Az ACL jogosultságokhoz hozzáférés szükséges adatokhoz, amelyek adminisztrátor identitással rendelkeznek. A támadónak a szerveren futtatnia kellene kódot (CryptUnprotectData) a fiók hitelesítési adatainak helyreállításához.
példa
Az alábbi példa több <processModel> konfigurációs beállítást is megad.
Az alábbi példa azt mutatja, hogy a titkosított felhasználónév és jelszó a regisztráció által definiált AspNetProcess elem alatt tárolódva van.
Követelmények
- Tartalmazza: <system.web>
- Webplatform: IIS 5.0, IIS 5.1, IIS 6.0
- Konfigurációs fájlok: Machine.config, Web.config
- Konfigurációs szekció kezelő: System.Web.Configuration.ProcessModelConfigurationHandler
http://doc.51windows.net/iismmc/ ... essmodelelement.htm
|
Előző:C# határozza meg, hogy a feltöltött fájl kép-e, és megakadályozza a Trójai Horse feltöltéstKövetkező:C nyelvű e-könyv gyűjtemény megosztása
|