Aspnetcore: Asp.net Core가 쓰레기를 수집하지 않음

@rynowak

내가 간과하고 있는 것이 있을 수 있지만... 내가 이해하기로는 이 메서드를 호출할 때마다 메모리 사용량이 증가해서는 안 됩니다. 개체가 생성되어 UI로 전송된 후에는 메모리가 해제되어야 합니다.

큰 개체 힙은 여기에서 당신을 물고있을 것입니다. 크기가 85KB보다 큰 개체를 할당하면 LOH에 저장되고 매우 드물게 압축 됩니다. 자세한 내용은 http://stackoverflow.com/questions/8951836/why-large-object-heap-and-why-do-we-care 를 참조하십시오(또는 https://github.com/dotnet/coreclr/blob/master /Documentation/botr/garbage-collection.md#design-of-allocator를 참조하십시오.

Asp.net 코어가 쓰레기를 수집하지 않는 이유를 이해할 수 없습니다. 지난 주에 웹 서비스를 며칠 동안 실행했는데 메모리 사용량이 20GB에 도달했습니다.

그렇게 큰 개체를 만드는 서비스는 무엇입니까? 메모리 덤프가 너무 커지기 전에 시도해야 합니다. 그러면 주변에 붙어 있는 개체와 유지되는 이유를 명확하게 알 수 있습니다(Visual Studio를 사용하여 덤프 또는 windbg 또는 perfview와 같은 고급 도구를 볼 수 있음).

Enumerable.Repeat를 호출하는 대신 처음부터 배열을 할당하십시오.
또는 GCSettings.LargeObjectHeapCompactionMode(.Net Standard에서 지원)를 사용하여 메모리를 압축합니다.

답장을 보내 주신 @davidfowl 과 @MhAllan 에게 감사드립니다. 그러나 이 예는 인위적인 것이었습니다. 나는 스크린샷을 찍을 수 있도록 눈에 띄는 양의 메모리를 사용하는 것을 원했습니다. 진실은 문제의 개체의 크기에 관계없이 응용 프로그램에서 이러한 일이 발생한다는 것입니다. 그리고 귀하의 질문에 답하기 위해 @davidfowl , 내 서비스는 dapper를 사용하여 데이터베이스에서 일부 데이터를 가져오고 결과 개체를 반환했습니다. 각 호출에 대한 한 행의 데이터였습니다. 그래서 메모리가 이만큼 커지는 데 며칠이 걸렸습니다. 이 특성을 발견했을 때 실제로 DB를 테스트하려고했습니다. 나는 계속해서 메서드를 계속 호출하는 작은 콘솔 앱을 작성했습니다.

@zorthgo 확실히 Dapper가 아닌가요? PHP에서와 같이 SQL 스크립트에 매개변수를 직접 주입하여 스크립트를 생성하면 캐시된 SQL 스크립트가 많이 남게 됩니다. Dapper가 하는 방법은 다음과 같습니다.
https://github.com/StackExchange/Dapper/blob/fe5c270aceab362c936456087a830e6fe1603cac/Dapper/SqlMapper.cs
메모리 프로파일러를 사용하여 할당된 메모리에 대한 참조를 유지하는 대상을 알려야 합니다. Visual Studio 2017은 앱을 여러 번 호출하기 전과 후에 메모리에서 일부 스냅샷을 찍고 비교할 수 있도록 도와줄 수 있어야 합니다.

@zorthgo 네 저도 봤습니다. 내 .net 코어 콘솔 앱에서 servicestack을 사용하고 있었고 API를 호출할 때마다 메모리 사용량이 50MB 증가했습니다. VS2017 버그인 줄 알았는데 작업관리자에서 사용량이 많은 것을 확인했습니다. zorthgo가 api에 대한 간단한 호출을 통해 언급했듯이 메모리 사용량이 크게 증가하고 메모리를 해제하지 않는 것 같습니다.

이것은 .NET Core의 ASP.NET Core에서만 발생합니까 아니면 .NET Framework의 ASP.NET Core에도 문제가 있습니까?

MVC 5(System.Web에서)를 사용하여 유사한 애플리케이션을 작성하고 동일한 동작이 표시되지 않는지 확인할 수 있습니까?

현재 상태로는 이 문제를 진전시킬 수 없습니다.

제 경우에는 대상 프레임워크 .NetCoreApp 1.1만 사용하고 있었고 콘솔 앱은 공유 프로젝트의 개체 모델을 참조하고 있었습니다.

이것이 누군가에게 도움이 될지 확실하지 않습니다. hellorequest를 호출하는 샘플 앱. 이 앱에서 시작 메모리는 85mb이고 반복적인 요청으로 메모리 사용량을 약 145mb까지 올릴 수 있었습니다. 때때로 125mb로 떨어지지만 그대로 유지됩니다. .Net Core 콘솔 앱에 익숙하지 않기 때문에 이것이 정상적인 동작인지 확실하지 않습니다. 나는 항상 내가 뭔가 잘못하고 있거나 올바르게 인스턴스화하지 않는다고 가정했습니다.

https://drive.google.com/open?id=0B0Gm-m-z_U84TU5keWFTMzc1ZWc

3000-5000명의 활성 사용자가 있는 프로덕션에 배포된 Asp.Net Core 응용 프로그램에서 동일한 문제에 직면했습니다. 어제 서버의 메모리가 15GB로 증가했습니다. 여전히 3시간마다 AppPool을 재활용하도록 IIS를 구성해야 했습니다. 문제가 무엇인지 알아 내려고 노력하십시오.

누군가 메모리 덤프를 가져 와서 특정 응용 프로그램의 모든 메모리를 차지하는 것이 무엇인지 확인 했습니까?

@davidfowl @Pinox
저는 큰 회사에서 일하고 있고 ASP.NET Core로 새 프로젝트를 시작하고 싶습니다. 하지만 이 문제를 봤을 때 저는 두려웠습니다. 이것은 중요한 문제이며 프로젝트의 수명 주기를 차단할 수 있습니다.

ASP.NET Core 또는 .NET Core(CoreCLR)와 관련이 있습니까? 우리는 Full .NET(4.6)을 대상으로 할 것이므로 질문하는 것입니다.

제 경우에는 @ikourfaln .net 코어 콘솔 앱, servicestack(.net 코어 버전) 및 kestrel을 사용했습니다. 이상한 점은 메모리 사용량이 한 수준까지 올라가다가 갑자기 멈추고 다시 올라가지 않는다는 것입니다. 작은 샘플로 측면에서 테스트하고 동작을 확인하는 것이 가장 좋습니다.

아마도 @zorthgo 는 그 메모리에서 비슷한 행동이 특정 수준까지 사용된 다음 내가 보고 있는 행동이므로 증가를 멈춘다면 그의 편에서 확인할 수 있습니다. @zorthgo 예제를 포함하도록 샘플 앱을 업데이트했는데 메모리가 사라지는 것을 볼 수 없습니다. 올라가지만 결국 멈춥니다.

소스를 약간 변경했습니다.

공용 객체 Any(TestGC 요청)
{
const 문자열 메시지 = "테스트";
반환 Enumerable.Repeat(메시지, 100000);
}

@피녹스
감사합니다. 옆에서 행동을 확인하겠습니다.

2.0의 이 버그는 어떻습니까?

이것에 대한 소식이 있습니까? 나는 Net Framework를 통해 Core 2를 사용하고 있는데 이것은 여전히 ​​​​발생합니다. _Controller_를 호출할 때마다 사용된 메모리가 증가했지만 결코 줄어들지 않았습니다. (_WebApi 템플릿을 사용했습니다_)

안녕,

ASP.NET Core 2에서도 동일한 문제가 있습니다. 메모리 덤프를 가져와 분석을 시도했습니다. 내가 볼 때 문제는 OP가 말한 것과 정확히 같습니다. 내 응용 프로그램은 약 75MB 할당으로 시작하여 매우 빠르게 ~750MB까지 이동합니다. 그 중 608MB는 ".NET에 할당된 미사용 메모리"입니다.

앱 시작 시 첫 번째 스냅샷:

3분 및 100개 요청 후 두 번째 스냅샷:

우리도 같은 문제에 직면해 있습니다. 컨트롤러는 많은 양의 데이터를 처리하고 있습니다(이는 잘못된 설계이며 곧 교체될 예정임). 이 컨트롤러에 대한 각 호출은 메모리를 증가시킵니다. 메모리는 40-50%만 감소하지만(50Mb 증가, 30-35Mb 감소) 각 호출은 매번 10-15Mb 범위의 메모리를 증가시킵니다. 서비스는 서비스 패브릭 내부에서 호스팅됩니다.

다음 조합을 사용하여 프로덕션 서비스(20-100 req/s)에 비슷한 문제가 있는 것 같습니다.

• ASP.NET 코어 2.0.4
• 서비스스택.코어 1.0.44
• 스키아샤프 1.59.2
• Docker v17.09.0-ce, Ubuntu 16.04 x64에서 afdb6d4 빌드
• x4 서버 @ 40 CPU, 128GB 메모리
• 서버 GC가 참
• 각 Docker 컨테이너는 12k(mhz) CPU 공유, 8GB 램으로 설정됩니다.

애플리케이션에는 프런트 엔드 웹 서버와 작업자가 있습니다(아래 그래프에 각각 표시됨).

웹 서버(최근 6시간)

작업자(지난 6시간)

서비스가 개체 저장소 프록시로 작동하고 결과적으로 개체를 LOH에 저장하기 때문에 둘 다 큰 바이트 배열을 사용합니다. 제 질문은 이것이 현재 .NET Core의 알려진 제한 사항입니까? LOH가 완전히 정리되거나 조각화되지 않은 것처럼 보입니다.

그렇긴 해도 SOH는 일반적인 웹 API 개체가 정리되기 때문에 제대로 작동하는 것 같습니다. 어떤 제안? 내 설정에 문제가 있습니까? 코드를 분석했지만 눈에 띄는 메모리 누수를 찾을 수 없으며 ServiceStack 라이브러리 외부에서 특별한 것을 사용하지 않습니다.

@sebastienros - 이에 대한 생각이 있습니까? 시스템에서 유사한 동작을 관찰한 적이 있습니까?

• 우리는 이것을 2.1에서만 측정합니다. 2.0에도 같은 것을 추가하는 방법을 살펴보겠습니다.
• 모든 의견은 언급된 LOH 문제와 관련이 있는 것 같으며, 이는 응용 프로그램에서 고려되어야 하고 가능한 한 큰 어레이를 풀링해야 합니다.

@sebastienros , 몇 가지 질문:

1. Ants 프로파일러를 사용하여 메모리 사용량을 측정했는데 이에 따르면 LOH 조각화가 감지되지 않았습니다. 내 애플리케이션에 LOH 조각화 문제가 있는지 어떻게 확인할 수 있습니까?
2. .net core 2.1의 결과는 무엇입니까? Kestrel이 Span을 사용하기 때문에 문제가 해결되었습니까??
3. 어레이를 풀링할 수 없는 경우 해결 방법을 제공할 수 있습니까? GCSettings.LargeObjectHeapCompactionMode.CompactOnce를 사용해야 합니까?

.net core 2.1의 결과는 무엇입니까? Kestrel이 Span을 사용하기 때문에 문제가 해결되었습니까?

우리는 개인적으로 문제가 Kestrel에 있다는 증거를 보지 못했습니다. 여전히 응용 프로그램 문제처럼 보입니다.

어레이를 풀링할 수 없는 경우 해결 방법을 제공할 수 있습니까? GCSettings.LargeObjectHeapCompactionMode.CompactOnce를 사용해야 합니까?

@jkotas @Maoni0 조언이 있으신가요?

동일한 문제가 발생하면 어떻게 조사할 수 있습니까? @sinapis 가 설명하는 것처럼 redgate 메모리 프로파일러에 따른 LOH는 거의 비어 있지만 한 명의 사용자에 대해 여전히 1GB 이상을 쉽게 사용하고 있습니다.

추적을 수집하고 perfview를 사용하여 분석합니다. Vance와 다른 사람들이 .NET 메모리 누수를 추적하는 방법에 대한 많은 자습서가 있습니다. https://www.bing.com/search?q=.NET%20memory%20leak%20perfview .

https://github.com/dotnet/coreclr/blob/master/Documentation/project-docs/linux-performance-tracing.md 에는 추적 수집을 위한 Linux 관련 지침이 있습니다.

메모리 누수가 없고 GC가 원하는 만큼만 더 많은 메모리를 유지하고 있다고 생각되면 다음을 시도할 수 있습니다.

• Windows 작업 개체 또는 도커 컨테이너 메모리 제한을 사용하여 프로세스가 사용할 수 있는 메모리 양을 제한합니다. GC는 이러한 제한을 고려하여 제한에 가까울 때 더 적극적으로 실행합니다.
• 또는 서버 GC에서 워크스테이션 GC로 전환합니다. 서버 GC가 훨씬 더 높은 피크 작업 집합을 갖는 것은 드문 일이 아닙니다. Workstation은 더 높은 피크 작업 집합이 낮지만 처리량도 낮습니다.

안녕,

프로덕션에서 .Net Core Web API와 같은 종류의 문제가 있다고 생각합니다.

애플리케이션은 .Net Core 2.0.3이 포함된 Windows Server 2016에서 실행됩니다. 머신은 28개의 CPU 코어와 24GB의 RAM이 있는 Hyper-V VM입니다. IIS 응용 프로그램 풀을 충분히 자주 재활용하지 않으면 결국 사용 가능한 모든 메모리를 사용하게 됩니다. 응용 프로그램이 많은 메모리(전체 시스템 메모리의 >=95%)를 사용하기 시작하면 CPU 사용량도 크게 증가합니다(때로는 2%에서 70%로). OOM 예외가 발생했는지 확실하지 않습니다. 우리는 항상 발생하기 전에 풀을 재활용합니다(내가 본 최대 메모리 사용량은 dotnet.exe가 사용하는 메모리의 98%였습니다).

".Net Memory Porfiler"(SciTech Software)를 사용하여 프로덕션 메모리 덤프를 분석한 결과는 다음과 같습니다.

이 분석이 정확하면 메모리의 약 95%가 "오버헤드 > 사용되지 않음"에 있습니다. 이 메모리 프로파일러 편집기가 포럼에서 이 범주를 설명하는 방법은 다음과 같습니다.
_"Overhead->Unused"는 관리되는 힙에 대해 .NET 런타임에서 커밋된 메모리입니다. 현재 사용되지 않지만 향후 인스턴스 할당에 사용할 수 있습니다. 커밋된 메모리를 유지할지 OS에 해제할지 결정하기 위해 런타임이 사용하는 많은 규칙이 있습니다. 사용 가능한 메모리, 할당 패턴, 프로세서 수, 서버 GC 사용 여부 등과 같은 요인에 따라 다릅니다._

@jkotas 추천해주신 내용(Windows 작업 개체 및 워크스테이션 GC로 전환)을 적용하고 결과를 알려드리겠습니다. 내가 가지고 있는 프로덕션 메모리 덤프에서 다른 유용한 정보를 추출할 수 있는지 알려주십시오.

감사 해요

@sinapis @ronald7
문제를 보여주는 앱을 공유할 수 있는 사람이 있습니까? 재현할 수 있다면 이유를 찾거나 최소한 일부 코드를 하나씩 제거하고 최소한의 재현을 분리할 수 있을 것입니다.

@sebastienros 앱을 공유할 수 없지만 PerfView session + memory dump 에서 세션을 공유할 수 있습니다.
설명: ASP.NET Core 2 Web API가 있고 10초에 걸쳐 동일한 요청을 보내는 200명의 사용자에 대한 부하 테스트를 만들었습니다. 총 775개의 요청이 처리되었습니다.

이 앱은 작업 관리자에서 거의 1GB 메모리 사용량으로 점프하고 그대로 유지되었습니다. 덤프를 보면 약 18MB를 셀 수 있습니다.

그래서 질문은 거의 1GB가 어디로 갔습니까?

@sinapis 감사합니다

설명하는 동작은 예기치 않은 것이 아니며 GC는 최대 부하에서 필요에 따라 일부 메모리를 할당하고 시간이 지남에 따라 해제합니다. GC 서버 모드이며 일반적으로 유휴 기간이 해제되고 앱 성능에 영향을 미치지 않을 때까지 기다립니다. 예약할 메모리 양은 시스템에서 사용 가능한 총 메모리에 따라 다릅니다.

그것이 계속 증가한다면 우리는 확실히 문제를 보게 될 것입니다. 더 이상 요청을 보내지 않고 앱을 실행하면 메모리 사용량이 줄어들 것이라고 가정합니다.

대부분의 시스템 메모리를 소모할 때까지 동일한 작업을 실행할 수 있습니까? 아니면 계속해서 증가하는 것을 보여줄 동일한 부하로 최소한 충분히 길까요? 나는 여전히 당신의 현재 덤프를 볼 것입니다.

또한 작업 중과 작업이 끝날 때 덤프를 가져갈 수 있으므로 세부 사항을 볼 수 있습니다.

안녕하세요 @sebastienros

유감스럽게도 저는 앱이나 메모리 덤프를 공유할 수 없지만 더미 애플리케이션(동일한 아키텍처 및 종속성 사용)을 만들고 동일한 시스템에서 실행하고 이 동작을 재현할 수 있다면 이 애플리케이션을 공유하겠습니다. 메모리 덤프에서 추출할 수 있는 유용한 정보가 있으면 알려주십시오.

하나의 프로덕션 서버에서 GC 모드를 _server_에서 _workstation_으로 업데이트했습니다. 메모리 사용량이 변경되면 지금부터 몇 시간 후에 알려드리겠습니다.

또한 다른 테스트를 수행했습니다. 4개의 가상 머신에서 로드 밸런서 뒤에서 애플리케이션을 실행하고 있습니다. 로드 밸런서 풀에서 머신 중 하나를 제거한 후에도 dotnet.exe에서 사용하는 메모리는 줄어들지 않고 30분이 지나도 동일한 수준을 유지했습니다. (그러나 응용 프로그램은 여전히 ​​몇 가지 요청을 처리하고 있었습니다. SCOM이 30초마다 더미 끝점에서 보낸 하나의 요청). 메모리가 해제되어 시스템으로 반환되지 않았습니다.

감사합니다

@sinapis ETW 추적을 보았습니다. 그것은 나에게 수수께끼입니다. 당신은 마지막으로 유도된 2세대 GC에서 거의 살아남지 못했지만 우리는 여전히 그렇게 많은 메모리를 커밋한 상태로 유지하기로 선택했습니다. 귀하의 응용 프로그램은 극단적인 경우로 보입니다(대부분 LOH 할당으로 인해 백그라운드 GC만 수행했습니다) - 거기에 일부 회계 오류가 있는지 궁금합니다(또 다른 가능성은 보고된 숫자의 오류이지만 이미 그렇게 많이 커밋했음을 확인한 경우 더 작은 가능성). 나와 공유할 수 있는 내용을 재현할 수 있다면 환상적일 것입니다. 그렇지 않으면 GC에서 일부 로깅을 사용하여 앱을 실행할 수 있다면(그렇게 하는 커밋을 줄 수 있음) 그것도 도움이 될 것입니다.

@Maoni0 GC 로깅을 활성화하는 방법을 공유해주세요
회계 오류를 반증하기 위해 제가 제공하고 싶은 다른 데이터가 있다면 무엇을 어떻게 제공해야 하는지 알려주십시오(더 많은 데이터를 수집하도록 perfview에 지시할까요?)
나는 최소한의 재현을 시도할 것이지만 문제가 어디에 있는지 모르기 때문에 성공할지 확신할 수 없습니다.

@sebastienros 바라건대 나는 오늘 더 많은 메모리 소비로 또 다른 덤프를 제공할 것입니다

안녕하세요 @sebastienros @Maoni0 ,

12시간 동안 워크스테이션 GC 모드로 애플리케이션을 실행했지만 결과는 동일했습니다. 또한 단일 프로덕션 노드에서 1시간 동안 .Net 2.1 Preview 2를 사용하여 애플리케이션을 다시 컴파일했습니다. 결과를 알려 드리겠습니다. 하지만 현재로서는 프로세스가 이미 2GB 이상의 RAM을 사용하고 있습니다.

이 동일한 컴퓨터에서 PerfView를 실행 중이고 GC 덤프를 수집 중입니다. OneDrive 링크를 보낼 수 있는 이메일 주소가 있습니까? 불행히도 이 스레드에서 직접 공유할 수 없습니다.

도움이 된다면 더 많은 메트릭이나 GC 로그를 수집할 수도 있습니다. 감사합니다

@ronald7 _redacted_ @ Maoni0에게 전달할 수 있습니다

안녕하세요 @sebastienros @Maoni0 방금 두 개의 PerfView gcdump와 VMMap 파일이 포함된 이메일을 보냈습니다. 이것이 도움이 되기를 바랍니다. 제 쪽에서는 여전히 더미 응용 프로그램을 사용하여 이 높은 메모리 사용량 동작을 재현하려고 합니다.

감사 해요!

저도 같은 문제를 겪고 있습니다. 가비지 컬렉션은 절대 발생하지 않습니다! 스크린샷은 상당히 간단한 dotnet core web api 앱을 사용하여 약 50개의 요청을 수행한 후의 메모리 사용량을 보여줍니다.

방금 Ubuntu 16.04에서 실행되는 ASP.NET Core 앱을 1.1에서 2.0으로 업그레이드했는데 이 문제가 발생했습니다. 꽤 심해서 OOM 오류로 인해 커널이 앱을 자주 죽이는데 1.x로 다시 다운그레이드할까 고민중입니다. 전혀 로드할 수 없는 페이지가 있습니다. Kestrel을 다시 시작한 후에도 앱은 단일 요청 후 사용 가능한 메모리를 즉시 소진합니다! 서버 업그레이드에 대해 생각했지만 사용 가능한 모든 메모리를 사용하는 ASP.NET Core 앱에 대한 여기의 설명에 따르면 도움이 되지 않을 것입니다. 우리의 스택은 기본적으로 ASP.NET MVC Core + EF Core... 너무 멋진 것은 없습니다. 시간이 되면 문제를 재현하기 위해 샘플을 만들려고 합니다. 스택의 단순성을 고려할 때 그렇게 어렵지 않아야 한다고 생각합니다.

FWIW, 내가 업그레이드한 시스템에도 .NET Core 콘솔 앱이 있으며 2.0 업그레이드 후 메모리 문제가 없는 것으로 보이므로 이것은 확실히 ASP.NET Core 관련 문제인 것 같습니다.

관련 가능성: https://github.com/aspnet/KestrelHttpServer/issues/2214

@danports GC.Collect()를 호출하여 메모리 사용량이 급격히 감소하는지 확인해보셨습니까? 그것은 우리가 어디서부터 시작해야 하는지에 대한 단서를 줄 것입니다. GC.Collect()(또는 GC.Collect/GC.WaitingForPendingFinalizers/GC.Collect 시퀀스)가 메모리 사용량을 극적으로 줄일 수 없는 경우 이는 GC가 이를 회수할 수 없도록 라이브에 필요한 메모리가 그만큼 많다는 것을 의미합니다.

@Maoni0 아직 시도하지 않았습니다. 내 문제가 GC에 있다고 생각하지 않습니다. 때때로 메모리 사용량이 감소하는 것을 보았기 때문입니다. 내 .NET Core 2.0 앱이 실행 중일 때와 비교하여 대략 2-3배의 메모리를 소비하는 것 같습니다. .NET 코어 1.1. 😞

지금은 .NET Core 1.1로 다시 다운그레이드했으며 나중에 시간이 더 있을 때, 아마도 .NET Core 2.1이 출시된 후에 다시 방문할 것입니다. (저는 2.0에서 많은 문제에 부딪혔고 이것은 그 중 하나일 뿐입니다.)

GC.Collect() 는 도움이 되지 않습니다. 200k int의 사전을 반환하는 하나의 컨트롤러가 있는 매우 간단한 ASP.NET Core 2.0 및 2.1 Web API를 시도했습니다. 앱이 더 이상 메모리를 사용하지 않더라도 할당된 메모리는 각 요청과 함께 계속 증가합니다.

200K 정수(4B)를 반환 하는 @Serjster 는 800KB가 필요합니다. 이 경우 https://github.com/aspnet/Home/issues/1976#issuecomment -289336916 주석에 설명된 문제가 발생합니다.

이 경우 배열 풀을 사용하여 요청 간에 재사용해야 합니다.

또한 알아두면 좋은 점은 코드가 64비트 모드에서 실행 중인 경우 포인터를 포함하는 배열/목록 등은 32비트에 비해 크기가 두 배라는 것입니다. 내가 올바르게 기억한다면 전체 프레임워크는 기본적으로 64비트 OS에서 모든 CPU 코드 32비트를 실행합니다. 따라서 코드를 마이그레이션하는 사람들은 실수로 LOH 문제에 부딪힐 수 있습니다.

나는 @Serjster 와 함께 일하고 있으며 여기에 내가 찾은 것이 있습니다. asp.net 코어(최신 테스트에서 2.1 사용)를 사용하여 바닐라 웹 API 프로젝트를 생성하면 진단 도구를 실행할 때(또는 코드에 설정된 프로세스 작업 메모리 확인) 바이트 수가 반환됨을 알 수 있습니다. 끝점에 도달하면서 계속 상승합니다. 예를 들어 사전을 반환하는 단일 웹 API 엔드포인트가 있는 경우20,000개의 항목이 있는 경우 다음이 발생합니다.

1. 컨트롤러 메서드를 처음 방문하면 프로세스 메모리가 83MB가 됩니다.
2. 몇 초 기다렸다가 두 번째 방문하면 86MB로 이동합니다.
3. 몇 초 기다리면 세 번째 방문이 90MB로 이동합니다.
4. 다시 - 94MB.
5. 이 작업을 n번 반복하면 결국 약 304MB에 도달합니다. 이 작업을 수행하면 레벨이 낮아집니다.

반환 개체가 다른 크기의 개체인 경우 위의 모든 숫자는 더 크거나 작습니다(레벨 오프 양 포함). 그러나 성장 패턴은 동일합니다(일명, 많은 요청 후에 수평이 될 때까지 성장하고 성장할 것입니다) .

메서드 호출에 GC.Collect를 추가하면(그래서 모든 단일 요청에서 발생하므로 수준은 훨씬 낮지만 수준이 떨어질 때까지 여전히 성장 기간이 있습니다.

다른 흥미로운 세부 사항은 스냅샷을 수행할 때 개체 수와 힙 크기가 방문할 때마다 크게 변경되지 않는다는 것입니다. 그러나 프로세스 메모리 그래프는 계속해서 더 높은 숫자를 보여줍니다(프로세스를 잡고 작업 메모리 설정 값을 가져오는 경우에도 마찬가지입니다).

그래프에 할당된 메모리가 표시되고 있다고 의심되기 시작했지만(이 메모리는 일부 asp.net 코어 사용/수요 예측 논리를 기반으로 커짐) 이것이 반드시 소비/누출된 메모리는 아닙니다. 그래도 확인하기에 충분하지 않으므로 지식이 더 많은 사람이 차임 할 수 있는지 궁금합니다.

편집 - 다시 @davidfowl 의견: 드물게 수집되는 것에 대한 귀하의 의견과 관련하여... 이것은 의미가 있을 수 있습니다. 그러나 일반적으로 얼마나 걸립니까? 요청 사이에 30초 이상 이동할 수 있으며 GC는 진단 차트의 해당 메모리 번호를 다시 낮추지 않는 것 같습니다. 나는 여기에 대해 무지하지만 단지 궁금합니다.

편집 2 - 이제 david가 위에 자세히 게시한 SO 링크를 읽었으므로 이것이 확실히 우리가 보고 있는 문제라고 생각하기 시작했습니다. 메모리가 제한된 환경에서 실행 중이라면(저렴하기 때문에 개발 환경에 있음) 이것에 문제가 발생합니다.

편집 3 - 하나의 느린 질문. 프로세스 메모리가 지속적으로 올라가는데 LOH 문제인 경우 힙 크기가 올라가지 않는 이유는 무엇입니까? 사실 이제야 이해가 가겠네요. 힙은 사용된 메모리입니다. 프로세서 할당 메모리는 사용된 메모리에 사용되지 않은 조각난 메모리 블록을 더한 것입니다.

@RemyArmstro Dictionary<int, int> 을 SortedDictionary<int, int> 로 변경할 수 있습니까? 사전은 아마도 지속적인 메모리를 할당하고 있으며 모든 항목에 추가 데이터를 추가할 수도 있습니다. SortedDictionary가 구현되는 방식은 하나의 큰 할당 대신 많은 작은 할당을 만듭니다.

편집: 응답 출력 스트림에 직접 직렬화하지 않고 문자열로 직렬화하는 경우 LOH 할당이 발생할 수도 있습니다.

@wanton7 귀하의 응답에 요점이 누락되어 있습니다. 사전은 빙산의 일각일 뿐입니다. 목록, 배열 등을 사용할 수 있으며 모두 동일한 작업을 수행합니다. 그러나 LOH가 이것을 일으키는 경우 지적한 것처럼 들리는 것처럼이 동작은 아마도 괜찮습니까? 메모리가 부족하면 어떻게 됩니까? 앱이 충돌합니까?

@Serjster ok 나는 이것이 일어나는 작은 경우가 있다고 생각했습니다. 나에게 큰 목록, 이와 같은 배열이 있고 바이너리가 아닌 경우 하나의 API 호출로 이 많은 데이터를 보내는 것은 매우 이례적인 일입니다. 일반적으로 일종의 웹 API가 있고 그로부터 일부 데이터를 얻을 때 페이징을 사용합니다. 클라이언트 측에 10000개의 항목을 보내면 안 됩니다.
그러나 이와 같은 문제가 많고 API 작동 방식을 변경할 방법이 없다면 자신만의 청크 목록 및 사전 구현을 만들어야 한다고 생각합니다. 이렇게 큰 배열을 실제로 사용한다면 청크 목록으로 바꾸거나 응용 프로그램이 시작될 때 풀링을 시도할 수 있습니다.

마이크로소프트가 이와 같은 상황에서 모든 사람이 사용할 수 있는 청크 구현을 만들면 좋겠습니다.

@wanton7 아직 요점을 놓치고 있습니다. 목록의 크기는 중요하지 않습니다. 단일 항목 또는 작은 목록이라도 이 문제가 발생합니다.

@Serjster 아마도 나는 눈이 멀었을 수도 있지만 단일 항목이나 작은 목록을 보내면 이런 일이 발생한다고 말한 게시물을 보지 못했습니다. 삭제하셨나요?

또는 @RemyArmstro 에서 그는 다양한 크기의 사전에 대해 이야기합니다. 나는 corefx를 확인했고 Dictionary는 배열을 할당하거나 이것들을 할당합니다.

private struct Entry
{
  public int hashCode;    // Lower 31 bits of hash code, -1 if unused
  public int next;        // Index of next entry, -1 if last
  public TKey key;           // Key of entry
  public TValue value;         // Value of entry
}

85000 바이트 할당은 LOH 할당을 일으키므로 int 키와 int 값의 5313 항목의 용량을 가진 Dictionary는 LOH 할당을 유발합니다. 용량이 숫자나 항목과 같지 않고 소수로 용량이 확장된 것 같습니다. private Dictionary의 private Resize 방법을 확인하십시오. 각 구조체는 추가 할당과 메모리 패딩을 가질 수 있으므로 더 낮은 항목도 LOH 할당을 유발할 수 있습니다.

사전 구현 세부 정보 Dictionary.cs

편집: 고정 URL

@wanton7 감사합니다. 나는 우리가 지금 문제가 무엇인지 깨달았다고 생각합니다. 이것에 대한 훌륭하고 간단한 솔루션이 없다는 것은 단지 안타까운 일입니다. 기본적으로 더 많이 인식하고 코드 작성 방법을 조정하는 것으로 귀결됩니다. 단점은 이 관리되지 않는 메모리가 좀 더 관리되는 것처럼 느껴지기 시작한다는 것입니다. :( 결국 이 할당 제한을 실제로 위반하는 영역은 몇 개 밖에 없을 수 있지만 영역 중 하나는 우리 앱의 핵심이므로 현재 많이 볼 수 있습니다. 그 부분을 다시 생각해야 한다고 생각합니다. 모니터링하고 이 크리프가 감지되는 다른 영역을 찾아내십시오. 다시 한 번 감사합니다!

실제로 비슷한 상황이 곧 발생하며 청크 IList<T> 구현을 만들어야 합니다. 비트 시프트가 가능한 청크에 약간의 크기를 사용하여 인덱싱에 비트 시프트와 마스크를 사용할 수 있습니다.

더 큰 청크와 더 작은 청크 중 어느 것이 GC에 더 유익한지 알고 싶습니다. 1KB에서 64KB 사이의 크기. 더 작은 청크는 GC에 대한 더 많은 참조를 의미하지만 더 큰 청크는 압축 및 조각화에 더 나쁠 수 있다고 추측합니다.

당신의 이해는 정확합니다 - 나는 너무 크지 않은 크기로 갈 것입니다. 아마도 4k/8k를 시도하십시오.

@Maoni0 감사합니다!

Mono에서 코드를 실행하더라도 불쾌한 일을 당하지 않도록 4KB를 선택했습니다. http://www.mono-project.com/docs/advanced/garbage-collector/sgen/working-with-sgen/ 을 읽고 LOH 임계값이 Mono에서 8000바이트에 불과하다는 것을 알았습니다.

이 문제에 대한 진전이 있습니까?

힙 크기가 동일하게 유지(또는 감소)함에도 불구하고 프로세스 메모리가 계속 증가하는 동일한 문제를 관찰하고 있습니다.

@sebastienros 이거 한 번 더 볼 수 있나요? 사람들이 시나리오를 더 자세히 조사하는 데 도움이 되는 몇 가지 자세한 지침을 제공할 수 있을까요?

다음은 우리의 상황에서 고려해야 할 몇 가지 항목입니다.

• 1000개의 정수 값이 저장된 Dictionary<int, int> 개체만 반환합니다. 그 이상은 없습니다.
• .NET Core 2.0 --> 2.1에서 프로젝트를 변환했습니다.
• MS Visual Studio 2017에서 이 문제를 보고 있습니다.

다음과 같은 코드:

    public async Task<IActionResult> SampleAction()
    {
        var list = new Dictionary<int, int>();
        for (int n = 0; n < 1000; n++) list.Add(n, n);
        return Ok(list);
    }

재현하려면 적당한 부하 형태를 시뮬레이션해야 합니다. Postman을 사용하여 빠르게 클릭했고 이 동작을 관찰할 수 있었습니다. 로드 시뮬레이션을 중단하고 힙 크기가 감소하는 것을 보았지만 프로세스 메모리는 동일하게 유지되었습니다(GC를 강제 적용한 경우에도).

내 프로젝트 중 하나에서도 이것을 보고 있지만 .Net Core 2.1(SDK 2.1.302)을 대상으로 하는 새로운 .net Core API에서 다시 만들 수도 있습니다.

Visual Studio 15.8.0 Preview 4를 사용하여 생성한 샘플 API 프로젝트를 첨부했습니다. 메모리 증가를 표시하기 위해 .net 코어 콘솔 앱이 0.5초마다 기본값 GET 끝점에 도달하여 2개의 문자열을 가져왔습니다. 프로세스 메모리 사용량은 느리지만 더 많은 데이터를 반환하는 프로젝트에서는 빠르게 증가할 수 있습니다.

WebApplication1.zip

스택 교환에서 이 게시물을 찾았습니다.

https://stackoverflow.com/questions/48301031/why-doesnt-garbage-collector-in-net-core-2-0-free-all-memory

이 동작이 존재하는지 확인하기 위해 릴리스 모드에서 애플리케이션을 프로파일링한 사람이 있습니까? 오늘 한 번 시도해 보고 문제가 지속되는지 확인하겠습니다.

편집 : 릴리스 모드에서 프로파일링을 시도했지만 문제가 여전히 지속됩니다. 나는 심지어 그것이 어떤 영향을 미칠지 GC에게 강제로 확인합니다.

@chrisaliotta 해당 게시물에 링크해 주셔서 감사합니다. 저는 그 행동을 몰랐습니다. 그것이 사람들이 보고 있는 것을 설명하는지 보는 것은 참으로 흥미로울 것입니다.

@Eilon @chrisaliotta 감사합니다. 하지만 이것은 이 토론과 관련이 없습니다. 디버그 모드에서 메모리를 해제하지 않는 .NET은 잘 알려진 동작이며 이것이 릴리스 모드에서 메모리 소비(및 잠재적인 누수)만 측정하는 이유입니다. 또한 릴리스 모드에서도 서버 GC 모드로 인해 시간이 지남에 따라 메모리가 어느 정도 증가하는 것을 볼 수 있습니다. 따라서 이 예는 두 가지 다른 이유로 아무 것도 증명하지 못합니다.

@sebastienros @beef3333 과 내가 관찰하고 있는 동작이 예상되는 것과 일치합니까? 즉, 힙 크기가 감소함에도 불구하고 Private Bytes가 높게 유지되는 곳은 어디입니까? 그렇다면 여유 힙 공간이 있음에도 불구하고 각 증분 요청으로 인해 개인 바이트가 계속 커지는 것이 이상하게 보입니다.

디버그 모드에서는 그렇습니다. 그러니 릴리스 모드를 사용하고 스트레스를 오랫동안 실행하십시오. 메모리가 무한정 증가하면 메모리 누수가 있는 것입니다. 메모리가 재활용되면(상당한 양의 메모리가 필요하더라도) 귀하의 경우에는 문제가 없습니다.

방금 릴리스 모드에서 첨부한 동일한 프로젝트를 사용하여 다시 테스트했는데 동일한 정확한 동작이 표시됩니다.

그러면 응용 프로그램을 테스트하겠습니다. 감사합니다.

@beef3333 이 제공하는 애플리케이션을 2시간 동안 로컬에서 5K RPS의 속도로 실행했으며 메모리는 안정적입니다(32GB가 있는 컴퓨터에서 400MB에서 전체적으로 1MB 차이). GC는 정기적으로 올바르게 호출됩니다. 또한 초과 근무 시간에 여러 덤프를 검사했으며 예상대로 다양한 인스턴스가 생성되고 수집되었습니다. 2.1.1을 사용하고 있습니다.

@sebastienros 찾아 주셔서 감사합니다. 이 모든 것의 핵심은 다음과 같습니다.

• 메모리 관리는 .NET Core 웹 애플리케이션과 일반 데스크톱 애플리케이션에서 다르게 작동합니다.
• 개발자는 일정 기간 동안 초당 함수 요청(RPS)으로 평균 메모리 소비에 집중해야 합니다.
• 전용 바이트의 증가가 항상 메모리 누수를 나타내는 것은 아닙니다.

내가 틀렸다면 정정해 주세요. 하지만 가장 빠른 응답 시간을 보장하기 위해 .NET Core가 평균 요청을 기반으로 할당된 메모리를 늘리는 것으로 보입니까? true인 경우 응용 프로그램 풀이 재설정될 때까지 할당된 메모리를 해제하지 않을 가능성이 있다고 가정하는 것이 안전합니까? 아니면 시간이 지남에 따라 RPS가 감소하면 할당된 메모리를 해제할 것입니까?

같은 문제입니다.
asp.net webapi 백엔드 서비스가 있습니다.
스택은 asp.net mvc, autofac, automapper, castle.dynamicproxy, 엔티티 프레임워크 코어입니다.
모든 메모리를 먹은 다음 서비스 충돌이 발생합니다.

버전은 2.1.0입니다.

@atpyk 2.1.1로 업데이트. 그것이 도움이 되지 않는다면 그 기억을 유지하고 있는 것이 무엇인지 정말로 프로파일링해야 합니다. 나는 https://www.jetbrains.com/dotmemory/ 를 사용했지만 아마도 이것을 할 수 있는 다른 도구도 있을 것입니다. LOH(Large Object Heap)에 실제로 할당된 항목을 표시할 수 있습니다.

32비트 모드로 실행 중이신가요? 대형 개체 힙 할당(~85000바이트 이상)은 조각화로 인해 32비트 모드에서 메모리 부족 예외를 유발할 수 있기 때문입니다. Dictionary를 사용하면 이 한계를 매우 쉽게 극복할 수 있습니다.. 이 댓글을 확인 하세요 https://github.com/aspnet/Home/issues/1976#issuecomment -393833505

전체 .Net Framework에서 코드를 실행하는 경우 기본 동작은 32비트 모드에서 모든 CPU 코드를 실행하는 것입니다. 프로젝트 설정에서 32비트 선호를 선택 취소하거나 서버 레지스트리의 일부 레지스트리 설정을 기본 64비트로 설정해야 합니다.

@wanton7 감사합니다. 나는 당신의 솔루션을 시도합니다.

2.1.2로 업데이트하고 win-x64를 사용하여 Microsoft Azure 웹앱에 배포했지만 효과가 없습니다. @wanton7

@atpyk 메모리 스냅샷(dump_)을 만들고 분석(Visual Studio, MemoScope)하여 어떤 개체가 모든 메모리를 사용하고 있는지 또는 카운트가 증가하는지 확인하세요. 두 개를 가져와 시간이 지남에 따라 비교할 수도 있습니다.

@sabastienros 충분한 사람들이 이에 대해 우려를 제기하여 귀하/MS가 실제로 직접 분석을 시작해야 한다고 생각합니다. 아마도 이것은 의도한 대로 작동하지만 디자인에 결함이 있습니다.

우리 앱은 결국 메모리 부족과 충돌을 일으키며 이 모든 것이 프로덕션 Azure 환경에서 실행됩니다. 이것은 허용되지 않습니다.

@atpyk 그러면 메모리 누수처럼 들립니다. @sebastienros 가 말한 것처럼 메모리를 유지하는 것이 무엇인지 보려면 메모리를 프로파일링하십시오.

한 가지 질문은 ASP.NET Core를 사용하고 있습니까? 첫 번째 댓글을 다시 읽고 ASP.NET MVC에 대해 언급했습니다. ASP.NET MVC와 ASP.NET Core는 완전히 다른 두 제품입니다. 이러한 문제와 ASP..NET Core에 대한 이 리포지토리입니다.

편집: 버전 번호에서 ASP.NET Core를 사용하는 것처럼 들리지만 확인하고 싶었습니다.

우리는 .net 코어 MVC를 사용합니다. @wanton7
기억을 분석하고 있습니다. Castle Dynamic Proxy가 메모리 누수를 일으킬 수 있습니다.

@Serjster 프로그램이 32비트 .NET Core에서 실행되고 메모리 부족 예외로 인해 충돌합니까? 코드가 많은 LOH 할당을 수행하는 경우 메모리 조각화가 원인일 수 있습니다.
32비트 환경에서 실행 중인 경우 두 가지 선택이 있습니다. 코드를 수정하여 LOH를 피하거나 64비트 환경으로 전환하십시오.

저는 Azure에 익숙하지 않지만 약간의 인터넷 검색 후에 https://blogs.msdn.microsoft.com/webdev/2018/01/09/64-bit-asp-net-core-on-azure-app 를 찾았습니다.

@Serjster 여기에 있는 모든 보고서가 동일하지는 않으며 각각의 다른 사례의 유효성을 확인하는 것을 선호합니다. "내 앱에 메모리 누수가 있습니다"와 같은 것은 프레임워크 때문이 아니라는 것을 의미하므로 각 경우가 실제인지 확인하는 것을 선호합니다.

예를 들어 당신의 기억이 증가하는 이유에 대해 "나는 믿습니다"라고 대답했습니다. 제 설명 후에 해결되셨나요? 또는 문제가 해결되지 않았으며 이 경우 문제를 재현하기 위해 로컬에서 실행할 수 있는 응용 프로그램을 제공할 수 있습니까?

@sebastienros 우리가 결국 찾은 것은 메모리 소비가 증가하지 않았음에도 불구하고 메모리 할당이 계속 증가했다는 것입니다. ASP.NET 코어가 더 많은 것을 잡아야 한다는 것을 알리기 위해 몇 가지 경험적 방법을 수행하고 있다는 것을 알고 있지만 각 요청에 대해 지속적으로 더 많은 것을 할당하는 것 같았습니다. 이 점에서 거의 나에게 탐욕스러워 보이지만 내가 틀릴 수 있습니다.

어느 쪽이든, @Serjster 요점은 여기에 분명히 약간의 혼란이 있기 때문에 이 스레드가 계속 성장하고 있다는 것입니다. 이전 ASP.NET 랜드(코어 1 이전)에서는 이 동작을 볼 필요가 없었습니다(적어도 이 정도는 아닙니다. 실제로 버그/문제가 아닐 수도 있지만 분명히 많은 사람들에게 원인이 되는 것입니다. 같은 질문을 계속해서 던집니다.

이 스레드를 원래대로 순환하는 대신 위에서 아래로 실제로 다루는 공식 기사가 있다면 좋을 것입니다. 그것이 명확히하는 데 도움이되기를 바랍니다.

이 스레드를 원래대로 순환하는 대신 위에서 아래로 실제로 다루는 공식 기사가 있다면 좋을 것입니다. 그것이 명확히하는 데 도움이되기를 바랍니다.

나는 두 번째. .NET Core 2.1이 이전 버전보다 메모리 관리와 관련하여 더 "기회적"인 이유를 아는 것이 좋습니다.

@sebastienros 여기에서 문제에 대한 요약 정보를 얻을 수 있습니까? 81개의 댓글이 있습니다 - 나는 그것들이 문제에 대한 전부가 아니라는 인상을 받고 있습니다. 그렇다면 여기에 모든 고유한 문제를 나열하고 각각에 대한 재현이 있는지 확인할 수 있습니까? 메모리 증가를 언급한 사람들이 충분히 있습니다. 제 생각에는 이것이 우리가 재현을 얻고 이것이 일반적인 문제인지 여부를 파악하는 것을 정당화한다고 생각합니다.

확신하는. 현재 이 모든 스레드를 식별하고 각 스레드의 상태를 확인하려고 합니다. 이 단일 스레드는 더 이상 지속 가능하지 않기 때문에 결국 이 문제를 닫고 각 보고서에 중점을 둔 보다 구체적인 문제를 다시 열 것입니다. 이 스레드에서 팔로우하려는 사람들을 위해 여기에 링크하겠습니다.

동시에 모든 권장 사항, 알려진 메모리 문제(LOB, HttpClient, ...) 및 이러한 문제를 분석하고 보고하는 방법이 나열된 문서를 작성합니다.

이 문제에 관심을 갖고 메모리 누수를 사전에 감지하기 위해 지난 6개월 동안 Linux 및 Windows 모두에서 Azure에서 ASP.NET 애플리케이션을 24시간 및 7일 동안 계속 실행해 왔습니다. 이러한 테스트는 매일 또는 매주 반복할 때마다 최신 ASP.NET 소스를 가져옵니다. RPS, 대기 시간, CPU 및 메모리 사용량을 측정합니다. 애플리케이션은 EF Core, MVC 및 Razor를 사용하며 상당한 부하를 시뮬레이션하기 위해 50% CPU로 유지됩니다.

당신은 (매일 보고서를 찾으려면 찾아보기)이 사이트에 공개적으로 여기에 결과를 볼 수 있습니다 https://msit.powerbi.com/view?r=eyJrIjoiYTZjMTk3YjEtMzQ3Yi00NTI5LTg5ZDItNmUyMGRlOTkwMGRlIiwidCI6IjcyZjk4OGJmLTg2ZjEtNDFhZi05MWFiLTJkN2NkMDExZGI0NyIsImMiOjV9&pageName=ReportSectioneeff188c61c9c6e3a798

이를 통해 과거의 일부 문제를 해결할 수 있었고 현재 시스템에 근본적인 누수가 없다는 확신을 가질 수 있습니다. 그러나 우리가 제공하는 모든 구성 요소를 사용하는 것과 거의 거리가 없으며 식별해야 하는 문제가 있을 수 있습니다. 문제를 재현하는 덤프 및 응용 프로그램을 제공하는 것이 우리를 도울 수 있는 주요 방법입니다.

@sebastienros 업데이트에 감사드립니다. 나는 우리의 경우 문제가 새로운 "탐욕적인 메모리 할당" 문제에 더 가깝다는 것을 알고 있습니다. 지금 문제가 있는지 확실하지 않습니다. 새로운 최적화 추론이 훨씬 더 공격적일 수 있습니다. 확실하지 않습니다... 하지만 이 스레드를 실제로 평가하고 사람들이 보고/오해하고 있는 것에 대한 몇 가지 통합된 설명/요약을 제시하는 올바른 길을 가고 있다고 생각합니다. 행운을 빕니다!

모든 개별 보고서는 격리되었으며 개별 후속 조치를 취하고 이미 해결된 경우 닫힙니다. 루프에 보관하려면 자유롭게 구독하십시오.

동시에 모든 권장 사항, 알려진 메모리 문제(LOB, HttpClient, ...) 및 이러한 문제를 분석하고 보고하는 방법이 나열된 문서를 작성합니다.

이것은 나에게 엄청난 +1입니다. 여기에서 가장 큰 문제 중 하나는 정보를 수집한 다음 _무엇이_ 문제인지 결정하는 데 도움이 되는 '느낌'입니다. (i) 수집, (ii) 자가 진단 시도 및 (iii) 덤프/결과를 MS 팀에 효율적인 방식으로 게시하기 위해 몇 가지 지침을 따를 수 있는 훌륭한 문서가 있으면 두 가지 모두에 실제로 도움이 됩니다. 울타리의 측면.

우리(개발자)가 정보를 더 잘 진단 및/또는 제공할 수 있다면 이는 모두에게 윈-윈(win-win)입니다.

@sebastienros 를 들어주셔서 다시 한 번 감사드립니다. 대단히 감사합니다.

아래 그림의 상황에 대해 어떻게 생각하십니까?

동일한 플랜 내에서 4개의 WebApp을 실행합니다. 초기에는 B1이었고 S2로 확장되었으며 배고픈 webapp csproj로 설정할 때까지 메모리가 계속 증가했습니다.

<ServerGarbageCollection>false</ServerGarbageCollection>

또한 Application Insights를 비활성화합니다.

1. 위의 설정으로 메모리를 제어할 수 있으므로 메모리 여유가 없다고 생각합니다. 옳은?
2. 제시된 행동은 정상입니까?

@alexiodan 과 같은 상황에서 microsoft/dotnet :2.1-runtime AS 기반에서 Kube에서 호스팅되는 일부 IHostedServices를 실행하는 .net core 2.1 콘솔이 있습니다. HealthChecks를 활성화하기 위해 HealthChecks 미들웨어만으로 asp.net을 추가하고 기본 이미지를 microsoft/ dotnet:2.1-aspnetcore-runtime으로 변경했습니다. 결과는 OOM이었습니다. 다음을 추가하여 메모리 할당을 안정화했습니다.거짓 csproj에서

우리의 분석은 asp.net 앱에서 GC가 덜 자주 수집하고 Finalizer Queue도 덜 자주 통과하는 것으로 나타났습니다.

또한 파이프라인에 다음을 추가하여 GC가 종료자 대기열을 수집하고 통과하도록 강제하면

System.GC.Collect();
System.GC.WaitForPendingFinalizers();
System.GC.Collect();

메모리 할당이 안정적으로 유지되었습니다.

아래 그림의 상황에 대해 어떻게 생각하십니까?

동일한 플랜 내에서 4개의 WebApp을 실행합니다. 초기에는 B1이었고 S2로 확장되었으며 배고픈 webapp csproj로 설정할 때까지 메모리가 계속 증가했습니다.

<ServerGarbageCollection>false</ServerGarbageCollection>

또한 Application Insights를 비활성화합니다.

1. 위의 설정으로 메모리를 제어할 수 있으므로 메모리 여유가 없다고 생각합니다. 옳은?
2. 제시된 행동은 정상입니까?

안녕하세요 @alexordan

AI(net core 2.1의 웹 앱)를 사용할 때도 매우 유사한 메모리 프로필이 표시됩니다. 이 문제를 해결하는 데 더 진전이 있습니까? 분명히 우리는 앱에 AI를 유지하기를 원합니다.

요청할 때마다 사용량이 증가하는 것이 이상하지만 위를 false로 설정하면 중지되는 것 같습니까? true가 그것을 가능하게 하는 가치라고 생각하기 때문에 이상하지만 그 반대인 것 같습니다...

이 스레드에 설명된 문제에 대한 기사를 작성하겠다는 의도를 발표한 직후에 실제로 작성했다는 사실을 언급하는 것을 잊었습니다. 여기에서 볼 수 있습니다: https://github.com/sebastienros/memoryleak

차트의 패턴을 실시간으로 렌더링하는 작은 응용 프로그램과 함께 제공됩니다.

그러나 위의 것을 false로 설정하는 것이 나를 위해 중지되는 것 같습니까? true가 그것을 가능하게 하는 가치라고 생각하기 때문에 이상하지만 그 반대인 것 같습니다...

클라이언트 가비지 수집(많은 앱과의 메모리 공유 및 메모리 여유 유지에 최적화됨)은 서버 가비지 수집(처리량 및 동시성에 최적화됨)보다 더 공격적입니다.

SGC를 false로 설정하면 내 asp.net 핵심 API가 150mb에서 48mb로 떨어졌고 그 이후에는 각 요청에 따라 증가하지 않았습니다. 그렇다면 현재로서는 이것이 프로덕션에 가장 적합한 설정입니까?

@kgrosvenor 실제로는 다릅니다. 우수한 @sebastienros 기사에서 인용:

일반적인 웹 서버 환경에서는 CPU 리소스가 메모리보다 더 중요하므로 서버 GC를 사용하는 것이 더 적합합니다. 그러나 일부 서버 시나리오는 Workstation GC에 더 적합할 수 있습니다(예: 메모리가 부족한 리소스가 되는 여러 웹 응용 프로그램을 호스팅하는 고밀도).

매우 편리합니다. 감사합니다. 명심하겠습니다. 이 스레드를 따라가면 더 많은 업데이트가 표시됩니다. 즉, 저는 asp.net 코어를 절대적으로 사랑합니다. :)

또한 .net core 2.1 콘솔 앱으로 이 문제를 겪습니다. 지속적인 메모리 성장. 도커 컨테이너를 낮은 최대값으로 설정하여 적중하고 다시 시작하므로 제대로 작동하지만 보기 흉합니다.

이쪽에 소식이 있나요? ASP.Net Core v2.1에서도 동일한 동작이 있습니다. 커밋 https://github.com/aspnet/AspNetCore/commit/659fa967a1900653f7a82f02624c7c7995a3b786 에서 볼 수 있듯이 v3.0에서 수정될 메모리 관리 문제가 있었던 것 같습니까?

@flo8 2.2로 업그레이드를 시도하고 동작을 확인 했습니까? https://dotnet.microsoft.com/download

최신 2.2를 실행하고 이 문제도 있습니다. 100만 int 목록을 만들고 emptyResult()를 반환하면 메모리가 부족해질 때까지 요청마다 힙이 수백 MB 증가합니다. ServerGarbageCollection을 false로 설정하면 올바른 수정이 아닌 것 같지만...

@dre99gsx 쉽게 재현한 것 같으니 로컬에서 동일한 작업을 수행할 수 있도록 프로젝트와 단계를 공유해 주시겠습니까?

이 경우 LOB를 채워야 하지만 gen2에서 수집해야 합니다. 또한 이것을 재현할 수 있는 환경, OS, 메모리, 로드를 공유하십시오.

애매한 답변 죄송합니다. 꽤 쉬운:
(Windows 7 64비트, 16GB 램, http 요청용 Google 크롬, VS2017 커뮤니티) - 이 스레드에 코드를 추가하는 데 여전히 익숙해지고 있습니다.

• 새 .NET Core 2.2 웹 앱 시작
• 컨트롤러 생성자에 범위가 지정된(특별하지 않은..) 서비스 클래스를 삽입합니다.
• 컨트롤러의 Index() 작업이 이 서비스 클래스의 메서드를 호출하도록 합니다.
• 하나의 속성으로 모델 클래스(DumbClass)를 만듭니다. public int ID {get; 세트;}
• 서비스 클래스 메서드에서 목록을 인스턴스화하고 채웁니다.
  var lst = 새 목록();
  for (i=0; i<10000000; i++) <--- 참고: 천만 번 반복
  {
  lst.add(새로운 DumbClass(){ID=i});
  }
• 메서드에서 반환하면 아무 것도 다시 전달할 필요가 없지만 해당 목록도 다시 전달할 수 있습니다...
• index()는 새로운 EmptyResult()를 반환합니다.

이제 8초마다 작업을 호출하고 프로파일러 메모리가 올라가는 것을 지켜보십시오. 내 시스템에서 Private Bytes에서 볼 수 있는 내용은 다음과 같습니다.

애플리케이션 시작: 155MB
첫 번째 http 요청 받기: 809MB
두 번째: 1.2GB
3위: 1.4GB
4위: 1.8GB
5위: 2.1GB... 2.3GB.. 2.6GB...

이제 어느 시점에서 GC가 시작되는 것처럼 보이지만 이 예에서는 3GB 아래로 떨어지지 않습니다. 언급했듯이 ServerGC를 false로 설정하면 1GB 이상으로 올라가지 않지만 여전히 올라가서 1GB에 머물고 있습니다.

도움이 되는지, 재현할 수 있는지 알려주십시오. 오, 나는 당신의 github 게시물을 읽었습니다: "ASP.NET Core의 메모리 관리 및 패턴", 환상적인 글, 기고해주셔서 감사합니다!

@dre99gsx 👋

나는 여전히 이러한 스레드에 코드를 추가하는 데 익숙해지고 있습니다.

문제가 전혀 없습니다 :) 질문: 전체 샘플 애플리케이션을 GitHub (무료 저장소) 또는 유사한 곳에 실제로 올릴 수 있습니까? 그것은 다른 사람이 당신이 가지고 놀았던 _전체_ 정확한 샘플 앱/리포지토리를 빠르게 복제/다운로드할 수 있는 가장 간단한 방법입니다.

또한 TaskManager 를 사용하는 메모리 사용량의 스크린샷이 도움이 됩니다(Windows의 경우 - 또는 *nix의 경우 .. top 명령 ??)

지금까지 대단한 노력!

/me는 조용히 이 스레드를 진지하게 시청하는 것으로 돌아갑니다.

https://github.com/sebastienros/memoryleak 스레드에 설명된 모든 증상에 대한 일부 데모 및 설명을 볼 수 있다는 알림

또한 이러한 각 문제는 개별적으로 처리되었으며 dotnet core __지금까지__에서 버그로 입증된 것은 없지만 예상되는 동작입니다.

@dre99gsx 이제 최근 댓글로 돌아가서 이 스레드와 별도의 문제를 제출할 것을 촉구합니다. 내 전화에 나는 그것이 "이것"이라는 것을 깨닫지 못했습니다 ;). 귀하의 첫 번째 의견에서 귀하는

메모리가 부족할 때까지

그래서 나는 OutOfMemory 예외를 예상할 것이고, 이것이 내가 재현을 요청한 이유입니다. 그러나 다음 의견에서 다음과 같이 말합니다.

이제 어느 시점에서 GC가 시작되는 것처럼 보이지만 이 예에서는 3GB 아래로 떨어지지 않습니다.

따라서 메모리 문제가 없습니다. 이것은 많은 코어와 사용 가능한 메모리가 많은 시스템에서 일반적입니다. GC는 관리되는 힙을 해제하지만 커밋을 취소할 이유가 없으므로 메모리는 여전히 커밋됩니다(사용 가능한 메모리가 많음). 이것은 .NET의 표준 동작이며 내가 지적한 기사에서 이를 시연합니다. https://blogs.msdn.microsoft.com/maoni/2018/11/16/running-with-server-gc-in-a-small-container-scenario-part-0/ 도 읽을 수 있습니다.

런타임 팀은 현재 컨테이너에서 실행되는 .NET 애플리케이션을 제한하는 방법을 연구 중이므로 일부 마이크로서비스 시나리오를 해결하기 위해 3.0을 대상으로 하는 많은 메모리를 사용하지 않습니다.

그리고 스스로 알아낸 것처럼 응용 프로그램이 서버에서 사용 가능한 모든 메모리를 사용할 수 없으면 워크스테이션 GC 모드를 사용해야 합니다.

맞습니다. "메모리 부족"이라고 말했을 때 Windows Private Working Set(작업 관리자)를 통해 다른 응용 프로그램에 사용할 수 있는 메모리가 없다는 것을 시각적으로 보고 있는 것입니다. "메모리 부족 예외"가 아닙니다.

당신이 옳다. 이것은 예상되는 동작과 점점 더 유사해지며 사용 가능한 메모리가 너무 많으면 다른 사람이 필요로 하지 않는데 리소스를 사용하여 메모리를 확보하는 이유는 무엇입니까! 알겠어. 다른 응용 프로그램이 제한되지 않도록 GC가 메모리를 확보할 수 있을 만큼 똑똑한 한 저는 그대로 유지하고 제 역할을 하도록 할 것입니다. 다시 한번 감사합니다!

나는 Asp.net core 2.2에서 내 응용 프로그램을 개발했으며 메모리 릴리스와 관련된 동일한 문제에 직면했습니다.
각 호출은 해제되지 않을 때마다 40-50Mb 범위의 메모리를 증가시킵니다.

또한 언급된 태그 ServerGarbageCollection>false 를 추가했습니다.
50명의 사용자에 대해 여전히 동일한 문제에 직면하고 있으며 In-Process 모드에서 약 2GB RAM을 사용하고 있습니다(w3wp iis 작업자 프로세스)

도와주세요.

도와주세요 !! ankitmori14 와 동일한 문제

@ankitmori14 , @ikourfaln - https://github.com/aspnet/AspNetCore/issues/1976#issuecomment -449675298에서 @sebastienros 의 의견을 읽었지만 여전히 메모리 문제가 있다고 생각되면 새 문제를 제출하세요. 문제를 재현하기 위한 자세한 단계와 함께 해당 동작에 대한 기타 정보 및 추적 정보를 제공합니다. 앱/프로세스에 실제로 오류가 있지 않는 한 버그가 있을 가능성은 거의 없습니다(그러나 불가능하지는 않음). 기본 '서버' 가비지 컬렉터는 가능한 최소한의 메모리를 사용하려고 하지 않습니다. 메모리가 실제로 부족할 때와 같이 필요할 때 시작됩니다. 따라서 작은 앱이라도 2GB 메모리를 사용할 수 있으며 여전히 4GB의 여유 공간이 있기 때문에 문제가 되지 않습니다.

안녕,

이 문제가 발생했습니다: https://stackoverflow.com/questions/53868561/dotnet-core-2-1-hoarding-memory-in-linux

기본적으로 메모리는 구성된 제한 512Mb에 도달하기 때문에 Kubernetes가 메모리를 종료할 때까지 프로세스에서 며칠 동안 증가합니다. 흥미롭게도 프로세스를 다시 시작하거나 다른 작업 없이 메모리 덤프를 수행하는 동안 메모리가 급격히 떨어졌습니다. 메모리 덤프를 조사하면서 루트가 없는 많은 개체를 보았습니다.

어제 동시 GC(즉, 백그라운드 GC)도 비활성화했고 지금은 더 좋아 보이지만 확인하려면 적어도 일주일은 기다려야 합니다.

<PropertyGroup>
  <ServerGarbageCollection>false</ServerGarbageCollection>
  <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection>
</PropertyGroup>

@vtortola 질문, 애플리케이션에 대해 512Mb 제한을 구성할 때 처리하려는 동시 요청 수에 대한 아이디어가 있었거나 앱이 넘어지기 전에 처리할 수 있는 동시 요청 수를 테스트했습니까?

우리는 몇 가지 예비 및 대략적인 테스트를 수행하고 512Mb를 사용하여 포드당 500개의 동시 웹 소켓을 처리할 수 있는지 확인했습니다. 메모리가 150Mb 미만인 상태에서 2개의 포드와 1000개의 동시 연결로 몇 시간 동안 실행했습니다. 2개의 포드가 있는 배포된 애플리케이션은 150~300개의 동시 연결을 가지며 메모리는 처음 며칠 동안 100Mb 미만에서 약 2주 후에 512Mb에 도달할 때까지 다양합니다. 연결 수와 사용된 메모리 사이에는 상관 관계가 없는 것 같습니다. 연결의 70% 이상이 10분 동안 지속됩니다.

100MB와 512MB일 때 메모리 덤프를 공유하여 어떤 인스턴스가 아직 살아 있는지 확인할 수 있습니까?

쿠키, 토큰 및 많은 개인 데이터가 포함되어 있으므로 덤프를 공유할 수 없습니다.

그러면 현지에서 비교할 수 있습니까? 어떤 개체가 가장 많은 메모리를 사용하는지, 그리고 해당 개체의 수가 부하와 상관 관계가 없는지 여부와 관련하여. 300개의 연결이 있는 경우 3K 연결 개체가 없어야 합니다.

불행히도 <ConcurrentGarbageCollection>false</ConcurrentGarbageCollection> 설정 테스트는 도움이 되지 않았고 프로세스가 여전히 메모리를 비축하고 있습니다.

우리는 프로세스의 Linux 덤프를 가지고 있으며 이를 분석해야 하는 유일한 도구는 lldb이고 우리는 이 문제에 대해 매우 멍청합니다.

벨이 울릴 경우에 대비한 몇 가지 데이터는 다음과 같습니다.

(lldb) eeheap -gc
Number of GC Heaps: 1
generation 0 starts at 0x00007F8481C8D0B0
generation 1 starts at 0x00007F8481C7E820
generation 2 starts at 0x00007F852A1D7000
ephemeral segment allocation context: none
         segment             begin         allocated              size
00007F852A1D6000  00007F852A1D7000  00007F853A1D5E90  0xfffee90(268430992)
00007F84807D0000  00007F84807D1000  00007F8482278000  0x1aa7000(27947008)
Large object heap starts at 0x00007F853A1D7000
         segment             begin         allocated              size
00007F853A1D6000  00007F853A1D7000  00007F853A7C60F8  0x5ef0f8(6222072)
Total Size:              Size: 0x12094f88 (302600072) bytes.
------------------------------
GC Heap Size:            Size: 0x12094f88 (302600072) bytes.

그리고 dumpheap -stat 의 결과 : https://pastebin.com/ERN7LZ0n

https://stackoverflow.com/questions/53868561/dotnet-core-2-1-hoarding-memory-in-linux 에서 Grafana가 메모리 상태를 보고하는 방법을 찾을 수 있습니다.

우리는 웹 소켓을 사용하지 않지만 완벽하게 작동하는 dotnet 코어의 또 다른 서비스를 가지고 있습니다.

@vtortola 는 이 문제를 분기하지 않도록 새 문제를 만들어 주시겠습니까? WebSocket을 사용한다는 사실이 그것을 독특하게 만든다고 생각합니다. 그리고 우리는 적어도 당신처럼 동작하고 장기간에 걸쳐 스트레스를 주는 샘플 앱을 만들어야 합니다. 클라이언트가 웹 소켓으로 무엇을 하는지, 웹 소켓에 연결하는 방법과 시간을 설명할 수 있습니까? 이와 같은 앱을 설정하고 며칠 동안 실행할 수 있으며 메모리가 증가하는 것을 보면 메모리 덤프를 수행할 수 있습니다.

또한 GC가 포드 제한에 가깝다는 경고를 받지 않는 방식으로 GC와 Kubernetes 간에 충돌이 발생할 수 있습니다.

@richlander 도 비슷한 문제를 해결하기 위해 노력하고 있습니다. Rich는 이 경우(마지막 6개의 댓글만 읽으십시오)가 현재 작업 중인 작업과 관련될 수 있습니까?

차이가 있는 경우 동일한(또는 매우 유사한) 문제가 있습니다. 도커에서 실행되는 12개 이상의 .net 코어 2.1 및 2.2 콘솔 앱이 있습니다. 각 컨테이너에는 512mb 메모리 제한이 있고 웹 소켓(클라이언트)도 사용하며 앱은 ~3일마다 컨테이너 메모리 제한에 도달합니다. 그런 다음 컨테이너가 종료되고 다시 시작됩니다.

모든 것이 인증된 서비스를 사용하고 있으므로 제가 가지고 있는 것을 제공할 수 없지만 테스트 사이트를 사용하여 문제를 재현하는 무언가를 조합할 수 있습니다.

메모리 제한을 설정하기 위해 어떤 매개변수를 사용합니까? 그냥 --memory 또는 --memory-swap ?

테스트할 때 16MiB와 같은 초저한도에서도 내가 설정한 한도를 초과하지 않고 아주 잘 고려되었음을 알 수 있지만 디스크에서 미친 듯이 스왑됩니다. 그리고 db 쿼리(EF) 및 Razor 보기 렌더링을 수행하는 앱으로 테스트하고 있습니다.

@sebastienros 절대적으로, 나는 https://github.com/aspnet/AspNetCore/issues/6803 을 만들었습니다.

추가 정보가 필요하면 알려주십시오.

현재 메모리 문제가 발생하고 있습니다.

프로덕션에서 한 시간 후에 모든 메모리는 w3wp.exe 프로세스(.NET Core InProcess 실행)에서 사용됩니다. GC를 Workstation으로 변경해도 문제가 해결되지 않았습니다.

메모리 덤프를 분석한 후 이와 유사한 문제( https://github.com/aspnet/AspNetCore/issues/6102)를 발견했습니다.

최신 .NET Core 런타임(현재 2.2.3)으로 업그레이드한 후 오늘 나중에 프로덕션에서 테스트하기를 바랍니다. 어떻게 되는지 알려 드리겠습니다.

메모리 사용에 비슷한 문제가 있습니다. 내 Linux 컨테이너에 제한을 설정하면 OOM이 더 빨라집니다. Visual Studio의 기본 템플릿을 사용하는 경우에도 발생합니다. 내가 찾은 한 가지 - Core 2.1 및 2.2가 영향을 받습니다. Core 2.0은 아니지만 EOL입니다 :(

위 참조

런타임 팀은 현재 컨테이너에서 실행되는 .NET 애플리케이션을 제한하는 방법을 연구 중이므로 일부 마이크로서비스 시나리오를 해결하기 위해 3.0을 대상으로 하는 많은 메모리를 사용하지 않습니다.

그리고 스스로 알아낸 것처럼 응용 프로그램이 서버에서 사용 가능한 모든 메모리를 사용할 수 없으면 워크스테이션 GC 모드를 사용해야 합니다.

슬프게도 워크스테이션 모드는 전혀 도움이 되지 않습니다. 슬프게도 저는 3.0 미리보기 또는 이와 유사한 것을 시도할 위치에 있지 않습니다.

@PrefabPanda System.Runtime.GCSettings.IsServerGC 이 false 인지 확인하여 실제로 워크스테이션 GC 모드에서 실행 중인지 확인하십시오.

그렇다면 이것은 진정한 메모리 누수가 될 수 있습니다. 별도의 문제를 여는 것이 가장 좋은 단계일 수 있습니다.

@wanton7 - 감사합니다. 다시 확인했는데 확실히 설정되었습니다.

@DallanCarr - 할 것입니다

나는 그것이 메모리 누수가 아니라고 거의 확신합니다. Docker 설정이 올바르게 적용되지 않을 수 있으며 한도에 도달하기 전에 GC가 시작되지 않습니다. 나는 3.0이 이런 의미에서 수정 사항을 도입한다는 것을 알고 있습니다.

@richlander 이 문제가 2.2에서 작동하지 않는 것으로 알려진 문제처럼 보입니까?

@PrefabPanda 사용 중인 정확한 도커 버전과 도커 작성 파일을 공유해 주시겠습니까? 재현하려고 하지만 docker와 docker-compose 버전 간에 이 문제를 로컬로 복제하는 데 어려움이 있습니다.

@sebastienros , @richlander - 다시 찾아주셔서 감사합니다. 정말 감사.

내 Docker 버전:

도커 데스크톱 커뮤니티
버전 2.0.0.2(30215)

엔진: 18.09.1
작성: 1.23.2

첨부된 전체 테스트 프로젝트 참조:
WebApplication1.zip

테스트 컬 요청.zip

만일을 대비하여 내 Dockerfile:

mcr.microsoft.com/dotnet/core/aspnet:2.2 AS 기반에서
WORKDIR /앱
노출 80
노출 443

mcr.microsoft.com/dotnet/core/sdk:2.2 AS 빌드에서
작업 디렉토리 /src
복사 ["WebApplication1/WebApplication1.csproj", "WebApplication1/"]
dotnet 복원 "WebApplication1/WebApplication1.csproj" 실행
복사 . .
작업 디렉터리 "/src/WebApplication1"
dotnet 빌드 "WebApplication1.csproj" 실행 -c 릴리스 -o /app

FROM 빌드 AS 게시
RUN dotnet publish "WebApplication1.csproj" -c 릴리스 -o /app

FROM 베이스 AS 최종
WORKDIR /앱
복사 --from=게시 /app .
ENTRYPOINT ["닷넷", "WebApplication1.dll"]

docker-compose.yml:

버전: '2.4'

서비스:
웹 애플리케이션1:
이미지: ${DOCKER_REGISTRY-}웹 애플리케이션1
mem_reservation: 128m
mem_limit: 256m
memswap_limit: 256m
CPU: 1
짓다:
문맥: .
dockerfile: WebApplication1/Dockerfile

docker-compose-override.yml:

버전: '2.4'

서비스:
웹 애플리케이션1:
환경:
- ASPNETCORE_ENVIRONMENT=개발
- ASPNETCORE_URLS=https://+:443;http://+:80
- ASPNETCORE_HTTPS_PORT=44329
- DOTNET_RUNNING_IN_CONTAINER=참
- DOTNET_SYSTEM_GLOBALIZATION_INVARIANT=참
- ASPNETCORE_preventHostingStartup=true
포트:
- "50996:80"
- "44329:443"
볼륨:
- ${APPDATA}/ASP.NET/Https:/root/.aspnet/ https:ro
- ${APPDATA}/Microsoft/UserSecrets:/root/.microsoft/us ersecrets:ro

@sebastienros - GC가 보도록 별도의 환경 변수를 컨테이너에 넣을 수 있는 방법이 있더라도 저에게 잘 작동합니다.

명시적으로 호출하려고 시도했지만 도움이 되지 않습니다. 코드에서 호출하더라도 컨테이너/머신의 잘못된 메모리 크기가 여전히 표시된다고 가정합니다.

@PrefabPanda 가 "명시적으로 호출하려고 시도했습니다"라고 말했을 때 정확히 무슨 뜻인지 자세히 설명해 주시겠습니까? GC는 자연적으로 트리거되었는지 유도되었는지 여부에 관계없이 지정된 컨테이너 메모리 제한이 있는 경우 올바른 컨테이너 메모리 제한을 확인합니다. GC.Collect()를 호출하면 전체 차단 컬렉션을 수행합니다. GC.Collect(2, GCCollectionMode.Default, true, true) 를 수행하면 전체 압축 GC를 수행합니다. 이렇게 하면 컨테이너 제한이나 다른 것에 관계없이 힙이 가능한 가장 작은 크기로 반환됩니다.

안녕하세요 @Maoni0 - GC.Collect(2, GCCollectionMode.Default, true, true)를 시도했습니다.

256MB는 2.2에서는 너무 작지만 3.0에서는 '고정'될 수 있다는 또 다른 의견을 보았습니다. 좀 더 실험을 해봐야 할 것 같습니다...

GC.Collect(2, GCCollectionMode.Default, true, true)를 시도했지만 메모리가 예상대로 감소하지 않으면 실제 메모리 누수가 있다는 의미입니다. 귀하의 환경에서 얼마나 많은 도구를 사용할 수 있는지 확실하지 않습니다. sos 명령을 전혀 실행할 수 있습니까? 그렇다면 유도된 GC 후에 힙에 무엇이 남아 있는지 항상 확인할 수 있습니다.

@Maoni0 에게 감사드립니다. Visual Studio에서 템플릿을 사용하고 있음을 명심하십시오. 말 그대로 내가 첨부한 이 테스트 프로젝트에는 내 코드가 없습니다. 해결해야 할 다른 피드백이 있습니다. 연락드리겠습니다. 감사합니다.

@Maoni0 - 더 높은 한도를 설정하려고 시도했지만 차이가 없었습니다. 3.0 프리뷰 해봐야 알듯

이 문제는 모든 사례가 별도의 문제로 처리된 아주 오래된 문제이므로 이 문제에 대한 의견을 잠그고 싶습니다. https://github.com/aspnet/AspNetCore/issues/10200 에 댓글을 달고 있다고 생각하여 실수로 이것에 댓글을 달았습니다.

감사 해요