리눅스 OOM Killer 동작 원리와 oom_score_adj 튜닝
메모리가 정말 바닥나면 커널은 프로세스 하나를 희생시켜서라도 시스템 전체가 멈추는 걸 막는다. 문제는 OOM Killer가 고르는 희생양이 항상 원하는 프로세스가 아니라는 점이다 — 메모리를 많이 쓴다는 이유만으로 DB가 먼저 죽고,…
cgroups v2 CPU 컨트롤러로 코어 리소스 제한하기
같은 서버에서 여러 서비스를 돌리다 보면 배치 작업 하나가 CPU를 독차지해 다른 서비스 응답 속도가 같이 떨어지는 경우가 생긴다. nice는 우선순위만 조정할 뿐 상한을 강제하지 못한다. cgroups v2의 cpu 컨트롤러는…
taskset/cpuset으로 코어 바인딩하기
CPU 시간을 얼마나 쓸지(cpu.max/cpu.weight)와 어느 코어에서 실행될지는 별개 문제다. NUMA 지역성이 중요하거나 특정 코어를 인터럽트 처리용으로 비워둬야 한다면 사용량 제한이 아니라 실행 코어 자체를 고정해야 한다. 이 글에서는 프로세스 하나를…
irqbalance vs 수동 IRQ affinity 설정
이전 글에서는 smp_affinity로 IRQ를 특정 코어에 수동 고정해 쏠림을 해결했다. 그런데 코어가 수십 개고 트래픽 패턴이 계속 바뀌는 서버라면 매번 손으로 재배치하는 대신, 대부분의 배포판이 기본 설치해두는 irqbalance 데몬이 자동으로…
softirq/NAPI와 RPS/RSS 패킷 분산
NIC가 패킷을 받을 때마다 매번 하드웨어 인터럽트를 걸면, 트래픽이 조금만 몰려도 CPU가 인터럽트 처리에만 매달리는 인터럽트 폭풍이 발생한다. 리눅스 네트워크 스택은 NAPI(poll 기반 수신)로 이 문제를 완화하는데, NAPI만으로는 NIC 큐가…
CPU 사용률이 거짓말하는 이유 — Utilization vs Saturation
모니터링 대시보드의 CPU 사용률이 20~30%인데 애플리케이션 응답은 계속 느려지는 상황을 겪어본 적이 있을 것이다. 흔히 보는 시스템 전체 평균 %CPU는 여러 코어를 뭉뚱그린 값이라, 일부 코어만 100% 포화된 상태를 "아직…
ftrace로 만드는 경량 트레이싱 실전
특정 syscall이나 함수 하나가 얼마나 걸리는지, 그 안에서 어떤 하위 함수가 시간을 잡아먹는지 알고 싶을 때 perf는 샘플링 기반이라 호출 빈도가 낮은 함수는 놓치기 쉽다. ftrace의 function_graph 트레이서는 지정한 함수의…
IRQ 스레드화(threaded IRQ)로 실시간성 확보하기
인터럽트 핸들러(hard IRQ)는 인터럽트 컨텍스트에서 실행되기 때문에 sleep이 불가능하고, 처리하는 동안 로컬 CPU의 인터럽트가 막혀 그 코어의 실시간 태스크가 우선순위와 무관하게 끼어들 수 없다. PREEMPT_RT 계열 커널이나 지연시간에 민감한 워크로드가…
tc/netem으로 네트워크 장애 재현하기
애플리케이션이 네트워크 장애 상황(지연 증가, 패킷 유실, 순서 뒤바뀜)에서도 제대로 재시도·타임아웃 처리를 하는지 확인하려면 실제로 그런 상황을 만들어봐야 하는데, 막상 회선을 끊거나 라우터를 조작하는 식으로 재현하기는 번거롭다. 리눅스 커널에는 이런…
TCP 송수신 버퍼 튜닝과 처리량
같은 애플리케이션, 같은 네트워크 대역폭인데 서버 위치나 커널 파라미터만 바뀌었을 뿐인데 처리량이 절반으로 떨어지는 경우가 있다. 원인이 대역폭이 아니라 TCP 송수신 버퍼 크기인 경우가 많다. TCP는 상대가 확인응답(ACK)을 보내기 전까지…
- 1
- 2
- 3
- 4
- …
- 9
- Go to the next page