IIS에서 호스팅되는 WCF 서비스 앱이 있습니다. 시작 시 로컬 캐시로 사용하기 위해 매우 비싼(시간 및 CPU 측면에서) 리소스를 가져옵니다.
불행하게도 IIS는 상당히 정기적으로 프로세스를 재활용하는 것 같습니다. 그래서 IIS가 응용 프로그램을 재활용하지 않도록 응용 프로그램 풀의 설정을 변경하려고 합니다. 지금까지 다음을 변경했습니다.
- CPU의 간격을 5에서 0으로 제한합니다.
- 프로세스 모델의 유휴 시간 제한이 20에서 0으로 변경되었습니다.
- 1740년에서 0으로 재활용되는 정규 시간 간격입니다.
이 정도면 충분할까요? 그리고 변경한 항목에 대해 구체적인 질문이 있습니다.
- CPU에서 제한 간격 설정은 구체적으로 무엇을 의미합니까? 특정 CPU 사용량을 초과하면 응용 프로그램 풀이 재활용된다는 뜻인가요?
- "재활용"이란 정확히 무엇을 의미하나요? 애플리케이션이 완전히 종료되었다가 다시 시작되었나요?
- "작업자 프로세스 종료"와 "응용 프로그램 풀 재활용"의 차이점은 무엇입니까? 프로세스 모델의 유휴 시간 초과에 대한 문서에서는 작업자 프로세스 종료에 대해 설명합니다. 재활용 아래의 정규 시간 간격에 대한 문서에서는 응용 프로그램 풀 재활용에 대해 설명합니다. 나는 둘 사이의 차이점을 잘 이해하지 못합니다. 나는 w3wp.exe가 응용 프로그램 풀을 실행하는 작업자 프로세스라고 생각했습니다. 누군가 둘 사이의 응용 프로그램의 차이점을 설명할 수 있습니까?
IIS7 및 IIS7.5 태그가 있는 이유는 앱이 두 버전 모두에서 실행되고 버전 간에 답변이 동일하기를 바라기 때문입니다.
참고용 이미지:
답변1
재활용
재활용은 일반적으로* IIS가 응용 프로그램의 컨테이너로 새 프로세스를 시작한 다음 이전 프로세스가 ShutdownTimeLimit종료되기 전에 자체 의지로 사라지도록 제공하는 것입니다.
*- 일반적으로: DisallowOverlappingRotation"중복 재활용 비활성화" 설정 참조
그것은파괴적인, 원래 프로세스와 모든 상태 정보가 삭제된다는 점입니다. out-of-process 세션 상태(예: 상태 서버나 데이터베이스 또는 상태가 작은 경우 쿠키)를 사용하면 이 문제를 해결할 수 있습니다.
하지만 이는 기본적으로겹쳐진ShutdownTimeLimit- 이전 프로세스에 "[ ]초 남았습니다. 준수하십시오."라는 메시지가 표시되기 전에 새 프로세스가 시작되고 요청 대기열에 연결되므로 중단 기간이 최소화된다는 의미입니다.
설정
귀하의 질문에 따르면 해당 페이지의 모든 설정은 어떤 방식으로든 재활용을 제어합니다. "종료"는 "사전적 재활용"으로 설명될 수 있습니다. 즉, 프로세스 자체가 종료 시간을 결정하고 질서정연하게 종료됩니다.
반응적 재활용은 WAS가 문제를 감지하고 프로세스를 시작하는 곳입니다(적절한 대체 W3WP를 확립한 후).
이제 어떤 형태로든 재활용을 일으킬 수 있는 몇 가지 사항은 다음과 같습니다.
- 건강에 해롭다고 판단하는 ISAPI
- 모든 모듈 충돌
- 유휴 시간 초과
- CPU 제한
- 앱 풀 속성 조정
- 너의 엄마로서5월어느 순간 "그만해"라고 소리쳤어요.선발그렇지 않으면 결코 나아지지 않을 것입니다!"
- "ping" 실패 * 실제로는 ping을 실행하는 것이 아닙니다. 명명된 파이프를 사용하기 때문입니다. - "생명 감지"가 더 많습니다.
- 위 스크린샷의 모든 설정
해야 할 일:
일반적으로:
장애를 입히다유휴 시간 초과. 20분 동안 활동이 없으면 = 쾅! 이전 프로세스가 사라졌습니다! 다음에 들어오는 요청에 대한 새로운 프로세스입니다. 0으로 설정하세요.
장애를 입히다정규 시간 간격- 29시간 기본 설정은 다양한 당사자들에 의해 "미친", "짜증나는", "영리한" 것으로 묘사되었습니다. 실제로 그 중 두 가지만 사실입니다.
선택적으로켜다DisallowRotationOnConfigChange(위에,구성 변경에 대한 재활용 비활성화) 사용을 멈출 수 없는 경우 이를 통해 작업자 프로세스에 종료해야 한다는 신호를 즉시 보내지 않고도 앱 풀 설정을 변경할 수 있습니다. 설정을 적용하려면 앱 풀을 수동으로 재활용해야 합니다. 이를 통해 미리 설정한 다음 변경 창을 사용하여 재활용 프로세스를 통해 해당 설정을 적용할 수 있습니다.
일반적인 원칙으로는,떠나다핑활성화됨. 그것이 당신의 안전망입니다. 사람들이 이 기능을 끄고 사이트가 무기한 정지되어 패닉 상태에 빠지는 경우를 본 적이 있습니다. 따라서 응답 속도가 매우 느린 앱에 대해 설정이 너무 공격적이라면 설정을 조금 취소하세요. 전원을 끄는 대신 무엇을 얻는지 확인하세요. (자체 모니터링 프로세스를 통해 정지된 W3WP에 대해 자동 충돌 모드 덤핑을 설정하지 않은 경우)
이는 올바르게 작동하는 프로세스가 영원히 지속되도록 하는 데 충분합니다. 죽으면 당연히 교체됩니다. 중단되면 핑으로 이를 선택하고 2분 이내에 새 시작을 시작해야 합니다(기본적으로 최악의 경우 계산은 다음과 같아야 합니다).핑 빈도+핑 시간 초과+시작 시간 제한요청이 다시 작동하기 전에).
CPU 제한이 아닙니다.보통흥미로운 점은 기본적으로 꺼져 있고 어쨌든 아무것도 하지 않도록 구성되어 있기 때문입니다. 프로세스를 종료하도록 구성된 경우 재활용이 유발될 것입니다. 그만 두세요. IIS 8.x의 경우 CPU 조절도 옵션이 됩니다.
(IIS) AppPool은 (.Net) AppDomain이 아닙니다(그러나 하나 또는 일부를 포함할 수 있음).
하지만... 그런 다음 .Net 영역에 들어가고 App도메인재활용으로 인해 상태가 손실될 수도 있습니다. (보다:https://blogs.msdn.microsoft.com/tess/2006/08/02/asp-net-case-study-lost-session-variables-and-appdomain-recycles/)
짧은 버전에서는 콘텐츠 폴더(다시 따기로!) 또는 해당 폴더에 폴더를 생성하거나 ASPX 파일을 생성하거나... 기타 등등...~에 대한앱 풀 재활용만큼 파괴적입니다.마이너스네이티브 코드 시작 비용(순전히 관리 코드(.Net) 개념이므로 여기서는 관리 코드 초기화 작업만 발생합니다).
바이러스 백신은 web.config 파일을 검사할 때 이를 트리거하여 변경 알림을 발생시킬 수도 있습니다....
답변2
꼭 확인해주세요,
응용 프로그램 풀이 주기적으로 자동 재활용되도록 구성되어 있는 이유를 찾기 위해 웹을 검색하면,메모리 문제와 관련되지 않은 합리적인 답변을 찾기가 어려울 것입니다. 이는 일반적으로 커뮤니티가 우리 웹 애플리케이션이(또는 IIS에서 호스팅되는 서비스 계층)은 메모리 문제를 방지하기 위해 재활용되어야 합니다.
나는 항상 그런 생각을 해왔습니다.코드가 올바르게 작동하기 위해 주기적으로 다시 시작해야 한다면 뭔가 분명히 잘못된 것입니다. 버그가 있습니다문제를 '사라지게' 만들기 위해 가끔 프로세스를 다시 시작하는 대신 코드 어딘가에 문제를 해결해야 합니다.
정말로 더 집중하기 시작해야 해요메모리 관리.NET에서 우리 애플리케이션이 문제 없이 계속 실행될 수 있는지 확인하는 것입니다.
답변3
OP 시나리오(시작 시 긴 초기화/워밍업)에 따라 확인해야 할 또 다른 사항은시작 시간 제한(초) 기본값은 90초입니다. 초기화에 시작 시간 제한보다 오래 걸리는 경우 작업자 프로세스가 종료될 수 있습니다.
답변4
대답은 당신입니다.~할 수 있다AppPool이 재활용되는 것을 방지하지만안 된다.
그 이유는 메모리 누수가 발생하면 결국 서버의 메모리를 모두 소모하게 되고 Windows에서는 동일한 IIS 서버의 다른 사이트를 중단시키는 블루 스크린이나 메모리 부족 예외가 발생하기 때문입니다.
따라서 해당 사이트에서 사용하도록 허용되는 메모리 양을 결정하고 해당 한도에 도달하면 재활용되도록 위의 설정을 지정하십시오.
일반적으로 재활용은 정상적으로 수행되므로 최종 사용자는 이를 인식하지 못합니다. 그러나 Blazor Server를 사용하는 경우 모든 세션이 서버에서 실행되고 모든 상태가 손실됩니다. 실제로 Blazor 앱은 재활용이 발생하는 동안 약 5초 동안 "connecting..." 메시지를 표시합니다. 즉, 서버 측 Blazor 앱에는 적합하지 않습니다.
이야기의 교훈은 앞서 언급한 바와 같습니다. 사이트에서 메모리가 누출되지 않도록 하세요. 개발 프로세스 초기에 메모리를 테스트하세요. Blazor 서버는 메모리 집약적이며 제 경험에 따르면 메모리 문제를 디버깅하는 데 꽤 많은 시간을 소비해야 했기 때문에 활성화될 때까지 기다리지 마세요. 이는 Blazor의 잘못이 아니며 Blazor 서버 앱의 특성상 매우 엄격한 코드가 필요합니다. .net 초기에는 GC가 모든 것을 처리하므로 메모리에 대해 전혀 걱정하지 않았지만 IIS 내부에서 실행하는 것은 다른 이야기입니다.