Linux 개념 | AWS Linux 2023에서 THP Disable 방법
본문 바로가기

Linux

Linux 개념 | AWS Linux 2023에서 THP Disable 방법

728x90
반응형

최근 Splunk, Elasticsearch, Kafka, DB 환경을 AWS에서 구성하는 사례가 많아지면서,

성능 튜닝 중 하나인 THP(Transparent Huge Pages) 비활성화가 다시 주목받고 있습니다.

 

이 글에서는 Amazon Linux 2023 기준으로 THP를 어떻게 disable 하는지,

그리고 예전에 자주 사용하던 tuned-adm 방식이 왜 사라졌는지를 쉽게 정리해봅니다.


1. THP(Transparent Huge Pages)가 뭐길래 끄는 걸까?

리눅스 메모리는 기본적으로 4KB 단위로 관리되지만, THP는 커널이 자동으로 큰 2MB 단위 페이지로 묶어주는 기능입니다.

계산 위주의 HPC나 AI/ML 작업에서는 이득이 있지만,

 

JVM 기반 + latency-sensitive + mmap 기반 + query workload에서는 다음 문제가 발생할 수 있습니다:

  • page promotion 시 latency spike
  • GC pause 증가
  • mmap I/O jitter
  • p99~p999 응답성 저하

대표적으로 THP를 끄라고 권장하는 서비스는 다음과 같습니다:

  • Splunk (Indexer & Search Head)
  • Elasticsearch / Lucene 계열
  • Kafka / Zookeeper
  • MySQL / MongoDB / PostgreSQL
  • Spark / Hadoop / Presto

즉, "계산형 → 켜도 됨" / "검색·DB형 → 꺼라"가 기본 가이드입니다.


2. Amazon Linux 2023에서 THP 상태 확인하기

$ cat /sys/kernel/mm/transparent_hugepage/enabled
$ cat /sys/kernel/mm/transparent_hugepage/defrag

 

THP 목표 상태는 아래처럼 [never]가 선택된 상태입니다:

always madvise [never]

3. Amazon Linux 2023에서 THP를 비활성화하는 방법

Amazon Linux 2023에서는 tuned-adm 기반 방식이 사라졌기 때문에, systemd 방식이 현재 가장 권장됩니다.

방법: systemd service 방식 (가장 깔끔)

서비스 파일 생성:

$ sudo vi /etc/systemd/system/disable-thp.service

 

내용 추가:

[Unit]
Description=Disable Transparent Huge Pages
After=sysinit.target

[Service]
Type=oneshot
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/enabled"
ExecStart=/bin/sh -c "echo never > /sys/kernel/mm/transparent_hugepage/defrag"

[Install]
WantedBy=multi-user.target

 

적용:

$ sudo systemctl daemon-reload
$ sudo systemctl enable --now disable-thp

 

확인:

$ cat /sys/kernel/mm/transparent_hugepage/enabled

 

[never]가 앞에 있으면 성공입니다.


4. “그런데 tuned-adm은 어디 갔어?”

많은 운영자들이 Amazon Linux 2 시절에 아래 명령으로 성능 프로파일링을 했습니다:

$ tuned-adm profile throughput-performance

 

하지만 Amazon Linux 2023에서는 다음 이유로 tuned 자체가 제공되지 않습니다:

  • 운영모델이 “프로파일 기반 성능 튜닝”에서
  • cgroup + systemd 기반 리소스 제어 모델로 변경됨

즉 AWS는 성능 제어를 커널이 아니라 워크로드 단위에서 제어하는 방향으로 설계를 변경한 것입니다.


5. 왜 이런 변화가 생겼을까?

이유는 3가지입니다:

1) Cloud-native workload 증가

컨테이너 / Kubernetes / microservice 환경에서는 단일 서버 전체를 “throughput-mode”로 바꾸는 방식이 맞지 않습니다.

2) Hypervisor가 이미 CPU/Power/Scheduling을 제어

AWS는 CPU scaling / P-state / governor를 이미 관리합니다.

3) 리소스 제어가 cgroup v2 + systemd로 이동

대표 파라미터:

CPUQuota=
MemoryMax=
TasksMax=
IOWeight=

 

결론적으로:

성능 프로파일링 = OS 레벨 → Workload 레벨로 이동

6. Splunk 환경 기준 결론

Splunk는 latency-sensitive + mmap + JVM + search workload 특성이 강하기 때문에,

Amazon Linux 2023에서도 아래가 최적 조합입니다:

  • THP = never (필수)
  • nofile ulimit 조정 (필수)
  • sysctl 커널 파라미터 조정 (권장)
  • EBS I/O 셋업 (아주 중요)
  • systemd/cgroup 기반 리소스 제한 (권장)

 

728x90
반응형