OutOfMemonryException은 언제 발생하나요? 만약 새 객체를 만들려고 하는데 가비지 콜렉터가 빈 메모리를 찾지 못하면, 예외를 잡을 수 있습니다; 또 다른 경우는 CLR이 메모리를 필요로 하지만 시스템이 이를 제공할 수 없을 때, 예외 명령도 실행됩니다. 하지만 이 시점에서 저희 애플리케이션은 오류를 잡아내지 못합니다.
메모리 오버플로우(OutOfMemoryException)에 대한 디버그 분석.
32비트 운영체제의 주소 지정 공간은 4G이며, 이 중 2G는 운영체제가 차지하므로 사용자 프로세스에 남는 메모리는 2G뿐입니다(이 경우 프로그램이 로드될 때 이미지가 차지하는 공간 일부를 차감하며, 일반적으로 약 1.6G~1.8G만 사용할 수 있습니다). 프로세스가 실행 중에 메모리를 요청해야 할 때 운영체제가 메모리 공간을 할당할 수 없으면, .net에서 System.OutOfMemoryException이라는 메모리 초과 예외를 생성합니다(프로그램 실행을 계속할 만큼 충분한 메모리가 없을 때 던지는 예외). 최종 증상은 OutOfMemoryException이지만, 원인은 다를 수 있으며, 이 문제를 해결하기 전에 프로세스의 현재 메모리 사용 상태를 분석하여 올바른 원인을 찾아야 올바른 처방을 결정할 수 있습니다. 이런 문제를 디버깅하는 몇 가지 팁을 소개합니다.
자세한 내용은 다음을 참고하시기 바랍니다:http://blog.csdn.net/lazyleland/article/details/6704661
ii 애플리케이션 풀 메모리 오버플로우 오류 시스템.OutOfMemoryException
ASP.NET 웹 서버에서는 ASP.NET 가 사용할 수 있는 메모리 양이 보통 전체 메모리와 같지 않습니다. machine.config 설정 <processModel>파일의 구성 섹션에 "memoryLimit"이라는 속성이 있는데, 이 속성의 값은 백분율 값이고 기본값은 "60"입니다. 즉, ASP.NET 프로세스(작업 관리자에서 ASP.NET 프로세스를 볼 수 있고, IIS5에서 aspnet_wp, IIS6에서 w3wp를 볼 수 있음)는 전체 물리적 메모리의 60%를 사용할 수 있습니다. ASP.NET 가 사용하는 메모리 양이 이 한계를 초과하면 IIS는 자동으로 프로세스를 재활용하기 시작하며, 이는 Http 요청을 처리하기 위한 새로운 프로세스를 생성하고 이전 프로세스가 차지한 메모리를 회수하는 것입니다.
서버가 대용량 메모리를 가지고 있을 때는 "memoryLimit" 값을 적절히 조정해야 합니다. 예를 들어, Chemas-microsoft-com 마트태그" />t="on"> 4G 메모리를 준비하면, t="on">4G×60%=t="on">2.4G. 하지만 Win32 운영체제에서는 프로세스가 차지할 수 있는 모든 메모리 공간이 t="on">2G에만 할당됩니다. ASP.NET 프로세스가 차지하는 메모리가 t="on">2G에 도달하기 시작하면, t="on">2.4G의 "재활용 임계값"에 도달하지 못하면 IIS는 재활용 프로세스 작업을 시작하지 않지만, Win32의 한계로 인해 이 프로세스에 더 많은 메모리를 할당하는 것은 사실상 불가능하므로 OutOfMemoryException이 실행될 가능성이 높습니다. 이를 방지하기 위해 IIS가 더 빨리 처리할 수 있도록 "memoryLimit"을 적절히 줄여야 했습니다.
마이크로소프트는 ASP.NET 프로세스가 메모리의 60%를 초과하지 않도록 권장하며, 계산된 실제 값은 t="on">800M을 넘지 않는 것이 최선입니다. 다만, 4G 메모리> t="on"을 가진 서버의 경우, "memoryLimit" 속성을 "20"으로 설정하는 것이 가장 좋습니다. IIS가 적시에 프로세스를 재활용할 수 있도록 적절한 재활용 임계값을 설정하는 것은 전체 서버의 안정적 작동을 보장하고 OutOfMemoryException을 방지하는 데 매우 중요합니다.
IIS6에서는 ASP.NET 프로세스의 재활용 임계값이 더 이상 구성 섹션의 "memoryLimit" 속성에 의해 결정되지 않고, IIS 관리자의 애플리케이션 풀 설정에 의해 결정됩니다.
하지만 이러한 구성이 올바르게 설정되더라도, OutOfMemoryExceptions가 완전히 피할 수 있다는 보장은 없으며, 메모리 회수 작업이 너무 오래 걸릴 수 있는 등 그 이유는 다양하고 복잡할 수 있습니다. 개발자들은 항상 코드에서 불필요하게 메모리를 낭비하거나 사용하지 않도록 주의해야 합니다. :)
만약 서버가 대용량이고 Win32 운영체제에서 t="on" >2G 메모리 사용 제한에 답답함을 느낀다면, 두 가지 대안이 있습니다:
- 컴퓨터를 /3GB 모드로 시작하고, 방법 참여 기사 뒤의 링크를 따라가세요
- Windows Server 2003 64비트 에디션 사용
메모리 오버플로우를 방지하기 위한 여러 요소
배열을 만들고 싶다면, 그 크기가 맞는지 꼭 확인하세요.
내부 사용과 새로운 호스팅 객체를 위한 충분한 메모리를 확보하세요.
.NET Compact 프레임워크에서 프로그래밍할 경우, 내부 메모리나 새로운 관리형 객체가 부족할 때 퍼블릭 언어 런타임이 이 예외를 던집니다. 이 예외를 피하려면 64KB 이상의 메모리를 차지하는 큰 메서드를 작성하지 않는 것이 좋습니다.
과도한 관리 메모리 사용은 종종 다음과 같은 원인으로 발생합니다:
- 대용량 데이터셋을 메모리에 읽어주세요.
- 너무 많은 캐시 항목을 생성하는 것.
- 큰 파일을 업로드하거나 다운로드하세요.
- 파일을 분석할 때 너무 많은 정규 표현식이나 문자열을 사용하세요.
- 과도한 조회 상태.
- 세션 상태에 데이터가 너무 많거나 세션이 너무 많을 때가 있습니다.
- 이 예외는 COM 객체에서 메서드가 호출되었을 때 메서드가 보안 배열(무정 크기의 배열)을 포함하는 사용자 정의 타입을 반환하고 추가 메시지인 "이 작업을 완료할 저장 공간이 부족하다"는 메시지를 반환할 때 발생할 수 있습니다. 이는 .NET 프레임워크가 구조 필드를 안전한 배열 타입으로 마샬링할 수 없기 때문입니다.
바이트 배열의 부적절한 사용으로 인한 메모리 오버런의 예
출력 파일이 특히 큰 경우, System.OutOfMemoryException을 직접 보고할 수 있습니다. 이것을 올바르게 하는 방법은 파일의 바이트 스트림을 구간으로 출력하는 것이지만, 바로 그 기능을 제공하는 Response.WriteFile(filePath) asp.net 이미 만들어진 메서드가 있습니다.
다음은 올바른 글쓰기 방법입니다:
asp.net 가 메모리 오버플로우를 경험하면, 이를 해결하는 쉬운 방법 중 하나는 즉시 애플리케이션 풀을 되찾는 것입니다. 하지만 이것이 문제를 완전히 해결하지는 못했습니다.
이미지 유형 생성 시 메모리 오버플로우 발생 (System.OutOfMemoryException)
오류 코드: System.Drawing.Image myimg=System.Drawing.Image.FromFile(file. FullName);
열린 파일이 이미지 파일이 아닐 때 발생하는 예외:
MSDN: 이 방법은 파일이 유효한 이미지 포맷이 아니거나 GDI+가 해당 파일의 픽셀 포맷을 지원하지 않을 경우 OutOfMemoryException 예외를 발송합니다.
이런 비정상적인 정보는 쉽게 오해를 불러일으킬 수 있습니다.
<processModel> 원소
인터넷 정보 서비스(IIS) 웹 서버에서 ASP.NET 프로세스 모델 설정을 설정하세요. 이 섹션은 Machine.config 파일에서만 설정할 수 있으며 <processModel> , 서버에서 실행되는 모든 ASP.NET 애플리케이션에 영향을 줍니다.
경고: 이 요소에 대한 정보는 "노트" 섹션을 읽어주세요.
구조 구성 예시:
주석
관리 코드 구성 시스템은 설정 설정을 읽지 않습니다 <processModel> . 대신 관리되지 않은 DLL aspnet_isapi.dll에서 직접 읽습니다. 이 섹션의 변경 사항은 IIS를 재시작한 후에 적용됩니다.
도메인 컨트롤러에 ASP.NET 를 설치할 경우, 특별한 조치를 취하지 않으면 설치가 작동하지 않습니다. 자세한 내용은 Location inhttp://support.microsoft.com지식 베이스에 실린 마이크로소프트 기사에는 "도메인 컨트롤러에서 기본 ASPNET 계정을 사용할 수 없다"ASP.NET CHS315158 있습니다.
ASP.NET 가 IIS 버전 6 네이티브 모드로 실행될 때는 IIS 6 프로세스 모델을 사용하고 <processModel> 섹션의 설정을 무시합니다. 프로세스 식별, 재활용 또는 기타 프로세스 모델 값을 설정하려면 Internet Services Manager 사용자 인터페이스를 사용하여 애플리케이션에 맞게 IIS 워커 프로세스를 구성하세요.
시간 값은 "hours:minutes: seconds"로 포맷되어 있습니다. 콜론 없이 단일 숫자만 주면 그 값은 분으로 간주됩니다; 따라서 timeout="4"는 timeout="00:04:00"과 동등합니다.
ASP.NET 애플리케이션이 워커 프로세스(Windows 2000과 Windows XP Professional의 Aspnet_wp.exe, Windows Server 2003의 W3wp.exe)ASP.NET 재시작을 유발하고, 재시작이 교착 상태 때문이라는 오류 메시지를 보낸다면, 해당 과정은 증가해야 합니다 responseDeadlockInterval 설정.
사용자 이름과 비밀번호를 레지스트리에 저장하세요
사용자 이름과 비밀번호를 레지스트리에 저장하세요
사용자명과 비밀번호를 암호화하여 레지스트리에 저장하려면 사용자 이름과 비밀번호를 다음과 같이 설정하세요.
userName="registry:HKLM\Software\AspNetProcess,Name"
password="registry:HKLM\Software\AspNetProcess,Pwd"
키워드 레지스트리 뒤와 쉼표 앞에 오는 문자열 부분은 ASP.NET 가 열어주는 레지스트리 키의 이름을 나타냅니다. 쉼표 뒤에는 ASP.NET 가 자격 증명을 읽을 수 있는 문자열 값 이름이 있습니다. 쉼표가 필요하며, 자격 증명은 반드시 HKLM 구성 장치에 저장되어야 합니다. 만약 구성이 잘못 포맷되면 ASP.NET 워커 프로세스가 시작되지 않고 이후 현재 계정 생성 실패 코드의 경로에 나타납니다.
자격 증명은 REG_BINARY 형식이어야 하며, Windows API 함수인 CryptProtectData에 대한 호출 결과가 포함되어야 합니다. 암호화 자격증명은 ASP.NET 설정 레지스트리 콘솔 애플리케이션(Aspnet_setreg.exe)을 통해 암호화 증명을 생성하고 저장할 수 있으며, 이 애플리케이션은 CryptProtectData를 사용해 암호화를 완료합니다. Aspnet_setreg.exe 및 Visual C++ 소스 코드를 다운로드하고 도움을 원하시면 웹사이트를 방문하세요www.asp.net그리고 "aspnet_setreg"를 검색하세요.
암호화된 자격 증명을 저장하는 레지스트리 키에 대한 접근 권한을 관리자와 SYSTEM만 허용하도록 설정해야 합니다. 레지스트리 키는 SYSTEM으로 실행되는 ASP.NET 프로세스에서 읽히므로, 다음과 같은 권한을 설정해야 합니다:
Administrators:F
SYSTEM:F
창작자 소유자: F
ProcessAccount:R
이를 통해 데이터를 보호하기 위한 두 가지 방어선이 제공됩니다:
ACL 권한은 관리자 신원을 가진 데이터에 접근해야 합니다.
공격자는 계정의 자격 증명을 복구하기 위해 서버에서 코드(CryptUnprotectData)를 실행해야 합니다.
본보기
다음 예시는 여러 구성 설정을 명시합니다 <processModel> .
다음 예시는 암호화된 사용자 이름과 비밀번호가 레지스트리 사용자 정의 항목 AspNetProcess 아래에 저장된다고 명시합니다.
요구 사항
- 포함: <system.web>
- 웹 플랫폼: IIS 5.0, IIS 5.1, IIS 6.0
- 구성 파일: Machine.config, Web.config
- 구성 섹션 핸들러: System.Web.Configuration.ProcessModelConfigurationHandler
http://doc.51windows.net/iismmc/ ... essmodelelement.htm
|
게시됨 2019. 3. 14. 오후 9:47:39
|
|
|
|
