#dotNET gc datas #성능최적화 #메모리관리
.NET 10 GC (DATAS) 준비 가이드
개요
.NET 10에서는 DATAS(Dynamic Adaptation To Application Sizes)가 기본적으로 활성화됩니다. DATAS는 기존 GC 기능과 달리 사용자 개입이 필요할 수 있는 특별한 기능으로, Server GC를 사용하는 경우 이전 런타임 업그레이드보다 눈에 띄게 다른 성능 프로파일을 경험할 수 있습니다.
주요 변경사항:
- 메모리 사용량이 크게 감소할 수 있음 (매우 가능성 높음)
- 이러한 변화가 바람직한지 여부는 트레이드오프가 눈에 띄는지, 그리고 최적화 목표와 일치하는지에 따라 달라짐
- 애플리케이션 성능 메트릭을 빠르게 확인하여 변경 결과에 만족하는지 검토 권장
용어 정리
핵심 용어:
- GC (Garbage Collector): 애플리케이션의 메모리 할당 및 해제를 관리
- DATAS (Dynamic Adaptation To Application Sizes): 애플리케이션 크기에 동적으로 적응하는 GC 기능
- TCP (Throughput Cost Percentage): GC 일시정지 및 할당 대기를 포함한 GC 오버헤드 측정 지표
- BCD (Budget Computed via DATAS): generation 0 할당 예산의 상한선
- LDS (Live Data Size): 애플리케이션 크기, 즉 가장 공격적인 GC를 수행했을 때 애플리케이션이 사용하는 메모리 양
- UOH (User Old Heap): 사용자 코드가 할당하는 old generation들 (LOH와 POH 포함)
- LOH (Large Object Heap): 85,000바이트 이상의 객체용 힙 (GCLOHThreshold 설정으로 변경 가능)
- POH (Pinned Object Heap): 할당 시 고정(pin)으로 표시된 객체 전용 힙 영역
GC 성능 기능 추가의 일반 정책
기존 GC 기능의 특징:
- 대부분의 GC 성능 기능은 새로운 런타임 버전으로 업그레이드하면 자동으로 활성화됨
- 사용자 조치가 필요 없도록 설계됨
- 광범위한 시나리오를 개선하도록 의도됨
- 수백만 명이 사용하는 프레임워크에서는 일부 회귀(regression)가 불가피함
최근 사례 - UOH 무료 영역 처리 변경:
- 예산 기반 트리밍 정책에서 연령 기반 정책으로 변경
- 더 견고한 일반적 성능 제공
- 하지만 마이크로벤치마크에서 동작이 크게 변경될 수 있음
- 이전: 1회 GC.Collect() 호출 후 메모리 감소
- 현재: 3회 GC.Collect() 호출 필요 (UOH 무료 영역이 2회 gen2 GC에서 노화되고, 3번째에서 decommit 리스트에 추가됨)
DATAS의 특별함:
DATAS는 정의상 광범위한 시나리오를 위한 것이 아님을 알고 있었습니다.
DATAS가 목표로 하는 2가지 특정 시나리오:
-
메모리 제약 환경에서 실행되는 버스티 워크로드
- 애플리케이션이 메모리를 덜 필요로 할 때 힙 크기를 축소하고, 더 필요할 때 확장
- 메모리 제한이 있는 컨테이너에서 실행되는 앱에 특히 중요
- 중요한 점: 비피크 시간에 메모리가 해제되었을 때 이 메모리를 실제로 어떻게 활용할지 계획이 있어야 함
- 오케스트레이션 환경 활용이 일반적 (예: Kubernetes의 HPA를 위한 적절한 request/limit 값 설정)
-
Server GC를 사용하는 소규모 워크로드
- 예: 작은 ASP.NET Core 앱을 테스트하려는 경우
- 작은 앱이 실제로 필요로 하는 것과 더 일치하는 힙 크기 제공
DATAS를 기본값으로 만들기 어려운 이유:
- 많은 팀이 처리량(throughput)을 전혀 희생하고 싶어하지 않음
- 해제된 메모리를 활용하지 않는 팀도 많음
- 전용 머신 플릿을 보유하고 피크 시간에 처리량을 최대화하려는 팀들은 DATAS의 대상이 아님
DATAS와 기존 Server GC의 성능 차이
정책 차이점
Server GC의 특성:
- 애플리케이션 크기에 적응하지 않음 (설계 목표가 아니었음)
- 주로 각 generation의 생존율(survival rate)을 보고 GC를 수행
- 프로세스가 사용할 수 있는 코어 수만큼 동일한 수의 힙을 생성
- 따라서 동일한 앱을 다른 코어 수로 실행하면 매우 다른 힙 크기가 나타날 수 있음
DATAS의 특성:
- 애플리케이션 크기에 적응하는 것을 목표로 함
- 코어 수가 크게 달라도 유사한 힙 크기를 보여야 함
- "DATAS는 메모리를 X% 줄인다"는 고정된 비율이 없음 (Server GC와 비교 시)
벤치마크 사례
ASP.NET 벤치마크 - Max heap size 비교 (DATAS 이전):
28코어(28c) vs 12코어(12c) 머신에서 Server GC는 매우 다른 동작을 보임:
- MultipleQueriesPlatform의 경우 12c에서 max heap size가 28c보다 훨씬 큼
- 이는 초기 단계에서 발생한 힙 크기 급증 때문
- 28c의 경우: 28개 힙이 있어 첫 번째 GC 전에 훨씬 많은 할당 발생 → GC 후 더 작은 생존율 관찰 → gen0 예산이 12c보다 훨씬 작아짐
- 정상 상태(steady state)에서는 이러한 벤치마크가 28c에서 훨씬 높은 힙 크기를 보임
측정 시 주의사항:
- "max heap size"만 측정하면 비정상 상태 동작의 영향을 쉽게 받을 수 있음
- 힙 크기는 테스트가 실행되는 머신에 따라 크게 달라질 수 있음
DATAS 적용 후:
- 28c와 12c의 max heap size가 매우 유사함
- 이것이 정확히 DATAS의 목적 - 애플리케이션 크기에 적응
Workstation GC 사용자를 위한 고려사항
변경이 필요 없는 경우:
- 워크로드가 Server GC를 전혀 필요로 하지 않는 경우
- 앱이 단일 스레드이거나 할당이 스트레스를 주지 않는 경우
- 하나의 스레드로 수집 작업을 수행하는 것에 만족하는 경우
→ Workstation GC가 정확한 선택임
DATAS가 매력적일 수 있는 경우:
- Server GC의 메모리 사용량이 너무 커서 Workstation GC를 사용 중이었다면
- DATAS를 통해 메모리 사용량 제한과 더 낮은 GC 일시정지 (더 많은 GC 스레드가 수집 작업 수행) 모두 달성 가능
DATAS 작동 원리
목표와 접근 방식
핵심 목표: 애플리케이션 크기(LDS, Live Data Size)에 적응
LDS 근사치:
- .NET GC는 세대별(generational)이므로 전체 힙을 자주 수집하지 않음
- 대부분의 전체 GC는 압축하지 않는 백그라운드 GC임
- LDS를 old generation에서 객체가 차지하는 공간(총 크기 - 단편화)으로 근사
- 전체 GC가 완료될 때 승격된(promoted) 크기를 보는 것도 유용
주요 구성 요소
DATAS의 2가지 핵심 구성 요소:
-
BCD (Budget Computed via DATAS)
- 애플리케이션 크기를 기반으로 계산
- 해당 크기에 대한 gen0 예산의 상한선 제공
- 고정(pinning) 때문에 gen0 generation 크기와 정확히 일치하지 않을 수 있음
-
합리적인 성능 유지하면서 메모리 추가 감소
- 목표 TCP(Throughput Cost Percentage)로 “합리적인 성능” 정의
- GC 일시정지와 할당 스레드 대기 시간 모두 고려
- 정상 상태에서 TCP를 GC 일시정지 시간 비율(% pause time in GC)로 근사 가능
- 기본 목표 TCP: 2% (GCDTargetTCP 설정으로 변경 가능)
- 워크로드가 가벼워지면 gen0 예산을 더 줄여 TCP를 목표치 근처로 유지
시나리오 예시
시나리오 A - 전자상거래 앱:
기본 설정:
- 전체 카탈로그를 메모리에 저장 (LDS)
- 각 요청마다 메모리 할당, 요청 기간 동안만 사용
피크 시간:
- 많은 동시 요청 처리
- 최대 예산(BCD) 도달: 1GB
- 1GB 할당마다 GC 수행
- 초당 1GB 할당, 20ms 일시정지 발생
- GC 시간 비율: 20ms / 1초 = 2% (목표 TCP와 동일)
비피크 시간:
- 초당 ~200MB 할당
- 1GB 예산 유지 시: 5초마다 GC 수행
- GC 시간 비율: 20ms / 5초 = 0.4% (목표 2%보다 훨씬 낮음)
- 목표 TCP 도달을 위해 예산을 200MB로 축소
- 다시 2% TCP 달성
결과: 비피크 시간에 힙 크기가 ~800MB 감소 (총 힙 크기에 따라 매우 큰 감소일 수 있음)
시나리오 B - 캐시 포함:
시나리오 A에 캐시 추가:
- 캐시가 LDS의 일부지만 가벼운 워크로드 시 작아짐
- LDS가 작아지면 BCD도 작아짐 (LDS의 함수이므로)
- 가벼운 워크로드 시 gen0 예산이 더 감소
- 크기 적응 특성을 더욱 반영
- conserve memory 메커니즘도 작동하여 old generation 예산과 크기를 적절히 조정
중요: 지금까지 힙 수에 대해 전혀 언급하지 않음! 이는 DATAS 자체가 완전히 처리하므로 걱정할 필요 없음.
이전 방식:
- 일부 고객은 GCHeapCount 설정을 사용하여 Server GC의 힙 수를 지정
- DATAS는 더 견고함:
- 필요 시 더 많은 힙 활용 가능 (일반적으로 개별 일시정지 시간이 더 짧음)
- LDS가 감소할 때 힙 크기 축소
- 직접 힙 수를 지정할 필요 없음
DATAS 전용 이벤트
프로그래밍 방식으로 접근:
- DATAS는 실제 TCP와 LDS를 정확하게 나타내는 이벤트를 발생시킴
- TraceEvent 라이브러리를 통해 프로그래밍 방식으로 가져와야 함
- 대부분의 성능 조사에는 앞서 언급한 근사치로 충분함
LDS와 TCP 조회:
// LDS
gc.DynamicEvents().SizeAdaptationTuning?.TotalSOHStableSize
// TCP
gc.DynamicEvents().SizeAdaptationTuning?.TcpToConsider
참고:
- SizeAdaptationTuning 이벤트는 매 GC마다 발생하지 않음
- DATAS 튜닝 변경이 필요한지 몇 번의 GC마다 확인함
DATAS가 적용되지 않을 수 있는 시나리오
1. 여유 메모리를 사용할 계획이 없는 경우
DATAS가 필요 없는 상황:
- 해제된 메모리를 어떻게 활용할지 계획이 없다면 DATAS가 필요 없음
- GCDynamicAdaptationMode 설정으로 DATAS 비활성화 가능
실제 사례:
- 전용 머신에서 프로세스를 실행하는 일부 팀
- 머신에서 다른 것을 실행할 계획이 없어 여유 메모리를 사용할 계획이 없음
- 한 팀의 의견: “이제 아마도 여유 메모리를 활용하는 것에 대해 생각해보고 싶다” (Server GC가 메모리 사용량 감소에 공격적이지 않아서 생각하지 않았음)
- 현재는 DATAS를 비활성화하지만, 비피크 시간에 메모리를 활용할 수 있게 되면 활성화할 예정
2. 시작 성능이 중요한 경우
DATAS의 시작 특성:
- DATAS는 항상 1개의 힙으로 시작
- 워크로드가 얼마나 스트레스를 줄지 예측할 수 없음
- 크기 최적화를 위해 가장 작은 힙 수인 1로 시작
- 1개 힙에서 여러 개로 가는 데 시간이 걸림
결론: 시작 성능이 중요하다면 회귀를 보게 되므로 DATAS는 적합하지 않음
3. 처리량 회귀를 전혀 용인하지 않는 경우
시작 처리량 포함:
- 시작 처리량을 포함한다면 DATAS는 적합하지 않음
시작 성능에 관심이 없는 경우:
- DATAS가 바람직할 수도, 아닐 수도 있음
- 예: Server GC로 GC 일시정지 시간 비율이 1%인 경우
- GCDTargetTCP 설정을 1로 설정 가능
- 힙 수를 제한하고 있었다면 DATAS로 성능 개선 가능 (더 짧은 일시정지 시간)
- 크기 적응 측면이 유익하다면 DATAS가 훨씬 나은 선택일 수 있음
- 하지만 해제된 메모리를 사용할 계획이 없다면 DATAS에 시간을 투자할 정당성이 없음
4. 대부분 gen2 GC를 수행하는 경우
튜닝이 덜 된 케이스:
- 시나리오가 주로 gen2 GC를 수행하는 경우 (거의 항상 임시 대형 객체의 과도한 할당 때문)
- DATAS를 시도했지만 결과에 만족하지 못했다면 비활성화 권장
- 시간을 투자할 가치가 있다면 튜닝 섹션을 따라 작동하게 만들 수 있는지 조사 가능
DATAS 튜닝 (필요한 경우)
고객 사례 1: 서버 앱 (전용 머신)
배경:
- 전용 머신에서 실행되는 서버 앱
- 컨테이너화 진행 중이므로 DATAS 사용에 장점이 있음
DATAS 적용 결과:
- 처리량 6.8% 회귀
- 작업 세트(working set) 10% 감소
- 현재는 DATAS 비활성화 상태
디버깅 방법:
- DATAS 사용/미사용 GC 추적(trace) 캡처
- 더 많은 GC가 트리거되는지 확인 → BCD 한계에 도달했다는 의미
- TCP를 “% Pause Time” 열로 근사
- gen0 예산을 “Gen0 Alloc MB” 열로 근사
- % pause time이 가장 높은 단계를 찾아 더 많은 GC가 트리거되는지 확인
GC 통계 비교 (발췌):
DATAS 미사용:
- gen0 예산: 4.22 GB
- % pause time: 1.2%
DATAS 사용:
- gen0 예산: 1.64 GB
- % pause time: 2.1%
분석:
- DATAS 미사용 시 gen0 예산이 DATAS 사용 시보다 2.6배 큼
- % Pause Time이 목표 TCP인 2%와 거의 정확히 일치 → DATAS 관점에서 설계대로 작동
- DATAS 미사용 시 2.6배 예산으로 GC를 덜 자주 트리거 → % pause time 1.2%
튜닝 방법:
DATAS를 활성화하고 이 단계에서 처리량을 회귀시키지 않으려면 더 큰 gen0 예산 사용 필요.
BCD 결정 방식 이해:
승수(multiplier) 공식:
m = constant / sqrt(LDS);
실제 공식 (conserve memory 포함):
m = (20 - conserve_memory) / sqrt(LDS / 1000 / 1000);
단순화 (MB 단위):
m = (20 - 5) * 1000 / sqrt(LDS);
m = 15000 / sqrt(LDS);
// 또는 MB 단위로 15를 사용
승수 클램핑:
- max_m (기본값: 10)와 min_m (기본값: 0.1) 사이로 제한
- 매우 작은 LDS(예: 2MB)일 때는 큰 승수 필요 (예: 10)
- 매우 큰 LDS(예: 20GB)일 때는 작은 승수 필요
LDS별 승수 예시:
| LDS (MB) | m | m (클램핑) | BCD (MB) |
|---|---|---|---|
| 1 | 15.00 | 10.00 | 10 |
| 5 | 6.71 | 6.71 | 34 |
| 10 | 4.74 | 4.74 | 47 |
| 50 | 2.12 | 2.12 | 106 |
| 100 | 1.50 | 1.50 | 150 |
| 500 | 0.67 | 0.67 | 335 |
| 1,000 | 0.47 | 0.47 | 474 |
| 5,000 | 0.21 | 0.21 | 1,061 |
| 10,000 | 0.15 | 0.15 | 1,500 |
| 15,000 | 0.12 | 0.12 | 1,837 |
| 30,000 | 0.09 | 0.10 | 3,000 |
| 50,000 | 0.07 | 0.10 | 5,000 |
이 사례의 솔루션:
LDS 근사치: 15GB (gen2 GC의 “Promoted (mb)” 열에서 확인)
DATAS 미사용 시 gen0 예산: 4.22GB
원하는 min_m: 4.22 / 15 = 0.28
설정 조정:
- GCDGen0GrowthPercent: 상수를 2.6배로 증가
- GCDGen0GrowthMinFactor: min_m을 300으로 설정 (0.3 LDS, 클램핑 제한 요소가 되지 않도록)
고객 사례 2: ASP.NET 앱 (스테이징 서버)
기존 GC 설정:
- GCHeapCount: 2개 힙 사용
- GCNoAffinitize: 친화성(affinity) 비활성화
기존 설정의 문제:
- GCHeapCount가 지정되면 DATAS가 비활성화됨 (힙 수 변경하지 말라는 의미)
- 다른 프로세스와 공존하는 프로세스이므로 메모리 사용량 제한을 위해 2개 힙 선택
- 하지만 유연하지 않음:
- 부하가 높아지면 2개 힙으로 처리량이 저하될 수 있음
- 2개 GC 스레드만 수집하므로 GC 일시정지가 눈에 띄게 높을 수 있음
- GC 힙 수를 조정할 수 있지만 더 많은 작업 필요
- Server GC가 메모리 사용량 감소에 공격적이지 않아 부하가 가벼울 때 원하는 것보다 훨씬 큰 힙이 될 수 있음
DATAS 활성화 방법:
- GCHeapCount 설정 제거 (GCNoAffinitize는 유지)
- 높은 부하에서 % pause time이 여전히 높음 (BCD 사용해도 GC가 자주 트리거됨)
- GCDGen0GrowthPercent 설정으로 BCD를 기본값의 2배로 설정
DATAS 튜닝 후 개선된 특성:
-
% pause time 극적으로 감소
- 기본 DATAS: % pause time 비슷하지만 힙 크기 눈에 띄게 감소
- 더 작은 예산과 더 많은 GC 스레드가 수집 작업 수행하여 달성
- 최적화 목표에 따라 정확히 원하는 것일 수 있음
- 이 고객의 경우 처리량에 영향을 주므로 % pause time이 이렇게 높지 않기를 원함
- 더 작은 목표 TCP 사용도 가능하지만 이 경우 기본 TCP가 충분함
-
개별 GC 일시정지 훨씬 낮음
- 훨씬 많은 GC 스레드가 수집하므로 개별 GC 일시정지가 훨씬 낮음
-
부하가 가벼워질 때 힙도 작아짐
- 동시 클라이언트 스레드 수: 200 → 100
- 힙이 작아지면서도 훨씬 낮은 % pause time과 개별 GC 일시정지 유지
튜닝 설정 요약
조정 가능한 주요 설정:
- GCDynamicAdaptationMode: DATAS 활성화/비활성화
- GCDTargetTCP: 목표 TCP 조정 (기본값: 2%)
- GCDGen0GrowthPercent: BCD 계산의 상수 조정
- GCDGen0GrowthMinFactor: min_m 조정 (승수 하한)
- GCDGen0GrowthMaxFactor: max_m 조정 (승수 상한)
실용적인 팁
성능 조사 시
메트릭 확인 방법:
- TCP 근사: “% Pause Time” 열 사용
- gen0 예산 근사: “Gen0 Alloc MB” 열 사용
- LDS 확인: 전체 GC 완료 시 “Promoted (MB)” 열 확인
- 가장 높은 % pause time 단계를 찾아 분석
GC 추적 캡처:
- DATAS 사용/미사용 GC 추적을 각각 캡처하여 비교
- 더 많은 GC가 트리거되는지 확인 → BCD 한계 도달 의미
의사 결정 프로세스
DATAS 활성화를 고려할 때:
- 여유 메모리를 어떻게 활용할 계획인지 명확히 하기
- 애플리케이션 성능 메트릭을 최소한 빠르게 확인
- 트레이드오프가 최적화 목표와 일치하는지 평가
DATAS가 적합하지 않다고 판단되면:
- 당황하지 말고 GCDynamicAdaptationMode 설정으로 비활성화
- 약간의 튜닝으로 유리하게 작동할 수 있는지 고려
힙 수 관리
DATAS 사용 시:
- 힙 수를 직접 지정할 필요 없음
- DATAS가 자동으로 조정:
- 필요 시 더 많은 힙 활용 (더 짧은 일시정지)
- LDS 감소 시 힙 크기 축소
- 이전에 GCHeapCount를 사용했다면 제거 고려
친화성(Affinity) 설정:
- GCNoAffinitize 설정은 DATAS와 별도로 유지 가능
- GC 스레드를 특정 코어에 고정하지 않으려면 활성화
오케스트레이션 환경
Kubernetes 사용 시:
- 적절한 request와 limit 값 결정 가능
- 비피크 및 피크 워크로드 모두에 대해 설정
- HPA(Horizontal Pod Autoscaler) 활용 개선
작업 스케줄링:
- 머신/VM에 여유 메모리가 있을 때 작업 실행 스케줄링 가능
- 더 복잡하지만 더 많은 제어 제공
- 전담 성능 엔지니어 팀이 있는 조직에 적합
주의사항
성능 회귀 가능성
예상되는 회귀:
- 시작 성능: 1개 힙에서 시작하므로 회귀 가능
- 처리량: 처리량 극대화가 목표인 경우 거의 항상 회귀
- 마이크로벤치마크: 극단적인 동작으로 인해 큰 변동 가능
회귀 최소화:
- 목표 TCP 조정 (GCDTargetTCP)
- BCD 계산 파라미터 조정 (GCDGen0GrowthPercent, GCDGen0GrowthMinFactor)
힙 크기 변화
메모리 사용량:
- 매우 작아질 가능성이 높음
- 바람직한지 여부는 상황에 따라 다름
- 예상치 못한 동작으로 보일 수 있지만 설계대로 작동하는 것
모니터링:
- 메모리 사용량 패턴 변화 주시
- 워크로드 변화에 따른 힙 크기 적응 확인
- 예상 범위 내에 있는지 검증
코어 수 영향
DATAS 이전:
- 동일한 앱을 다른 코어 수로 실행하면 매우 다른 힙 크기
- 벤치마크 결과 해석 시 주의 필요
DATAS 이후:
- 코어 수에 관계없이 유사한 힙 크기
- 더 예측 가능하고 일관된 동작
일시적 대형 객체
gen2 GC 빈도가 높은 경우:
- 거의 항상 임시 대형 객체(temporary large objects)의 과도한 할당이 원인
- DATAS 튜닝이 덜 된 영역
- 결과에 만족하지 못하면 비활성화 권장
- 시간 투자 가치가 있다면 튜닝 섹션 참조
학습 리소스 및 참고 자료
원문 출처
- Maoni’s Medium 블로그: 원본 게시글 “Preparing for the .NET 10 GC”
- Microsoft 공식 블로그: 크로스 포스트 (2025년 10월 8일)
관련 문서
- GC 설정 페이지: 상세한 설정 설명
- TraceEvent 라이브러리: 프로그래밍 방식으로 GC 정보 가져오기
예제 코드
GC 정보를 TraceGC 객체 목록으로 가져오기:
TraceEvent 라이브러리를 사용하여 추적에서 GC 정보를 프로그래밍 방식으로 검색하는 방법 참조
DATAS 이벤트 필드 접근:
// LDS 확인
gc.DynamicEvents().SizeAdaptationTuning?.TotalSOHStableSize
// TCP 확인
gc.DynamicEvents().SizeAdaptationTuning?.TcpToConsider
관련 블로그 게시물
- 이전 DATAS 블로그 포스트: .NET 8에서의 DATAS 소개 및 초기 구현
GC 통계 도구
PerfView:
- GC 추적 캡처 및 분석
- GCStats 뷰에서 메트릭 확인
- 이벤트 뷰 (DATAS 전용 이벤트는 프로그래밍 방식으로만 접근 가능)
벤치마크 데이터
ASP.NET 벤치마크:
- 28코어 vs 12코어 비교 데이터
- DATAS 적용 전후 힙 크기 비교
- 실제 워크로드 시뮬레이션 결과
추가 참고 자료
BCD 계산 예시:
- Gist 링크: LDS별 승수 및 BCD 계산 CSV 데이터
결론
DATAS는 .NET 10에서 기본적으로 활성화되는 중요한 GC 기능으로, 애플리케이션 크기에 동적으로 적응하여 메모리 사용량을 최적화합니다. 하지만 모든 시나리오에 적합한 것은 아니므로, 자신의 워크로드 특성과 최적화 목표를 고려하여 DATAS 활성화 여부와 튜닝 방법을 결정해야 합니다.
핵심 요약:
- 메모리 제약 환경과 버스티 워크로드에 특히 유용
- 코어 수에 관계없이 일관된 힙 크기 제공
- 해제된 메모리를 활용할 계획이 있어야 최대 효과
- 시작 성능이 중요하거나 처리량 회귀를 용인할 수 없다면 비활성화 고려
- 필요 시 TCP, BCD 관련 설정으로 세밀한 튜닝 가능
애플리케이션 성능 메트릭을 확인하고, 변경 결과가 최적화 목표와 일치하는지 평가한 후 적절한 결정을 내리시기 바랍니다.