CPU 사용률이 거짓말하는 이유 — Utilization vs Saturation

모니터링 대시보드의 CPU 사용률이 20~30%인데 애플리케이션 응답은 계속 느려지는 상황을 겪어본 적이 있을 것이다. 흔히 보는 시스템 전체 평균 %CPU는 여러 코어를 뭉뚱그린 값이라, 일부 코어만 100% 포화된 상태를 "아직…

Continue ReadingCPU 사용률이 거짓말하는 이유 — Utilization vs Saturation

ftrace로 만드는 경량 트레이싱 실전

특정 syscall이나 함수 하나가 얼마나 걸리는지, 그 안에서 어떤 하위 함수가 시간을 잡아먹는지 알고 싶을 때 perf는 샘플링 기반이라 호출 빈도가 낮은 함수는 놓치기 쉽다. ftrace의 function_graph 트레이서는 지정한 함수의…

Continue Readingftrace로 만드는 경량 트레이싱 실전

IRQ 스레드화(threaded IRQ)로 실시간성 확보하기

인터럽트 핸들러(hard IRQ)는 인터럽트 컨텍스트에서 실행되기 때문에 sleep이 불가능하고, 처리하는 동안 로컬 CPU의 인터럽트가 막혀 그 코어의 실시간 태스크가 우선순위와 무관하게 끼어들 수 없다. PREEMPT_RT 계열 커널이나 지연시간에 민감한 워크로드가…

Continue ReadingIRQ 스레드화(threaded IRQ)로 실시간성 확보하기

tc/netem으로 네트워크 장애 재현하기

애플리케이션이 네트워크 장애 상황(지연 증가, 패킷 유실, 순서 뒤바뀜)에서도 제대로 재시도·타임아웃 처리를 하는지 확인하려면 실제로 그런 상황을 만들어봐야 하는데, 막상 회선을 끊거나 라우터를 조작하는 식으로 재현하기는 번거롭다. 리눅스 커널에는 이런…

Continue Readingtc/netem으로 네트워크 장애 재현하기

TCP 송수신 버퍼 튜닝과 처리량

같은 애플리케이션, 같은 네트워크 대역폭인데 서버 위치나 커널 파라미터만 바뀌었을 뿐인데 처리량이 절반으로 떨어지는 경우가 있다. 원인이 대역폭이 아니라 TCP 송수신 버퍼 크기인 경우가 많다. TCP는 상대가 확인응답(ACK)을 보내기 전까지…

Continue ReadingTCP 송수신 버퍼 튜닝과 처리량

cgroups v2 Memory 컨트롤러로 메모리 고갈 상황 재현하기

컨테이너 하나에 메모리 제한 512Mi를 걸어놓고 배포했는데, 실제 트래픽이 몰리면 그 한도를 넘길 때 서비스가 어떻게 반응할지 로컬에서 미리 확인해보고 싶을 때가 있다. 스왑이 있으면 조용히 스왑아웃되다 끝날 수도 있고,…

Continue Readingcgroups v2 Memory 컨트롤러로 메모리 고갈 상황 재현하기

USE Method로 리눅스 성능 문제 진단하기

"서버가 느려요"라는 신고가 들어오면 vmstat, top, iostat을 순서 없이 아무거나 띄워보다가 우연히 눈에 띈 수치에 매달리기 쉽다. Brendan Gregg가 정리한 USE Method(Utilization / Saturation / Errors)는 이런 무작위 삽질 대신,…

Continue ReadingUSE Method로 리눅스 성능 문제 진단하기

오픈AI “패치 더 플래닛” — GPT-5.5-Cyber, 리눅스 커널서 취약점 32건 자동 발견

오픈소스 프로젝트 메인테이너들은 최근 몇 년간 두 가지 상반된 AI 문제를 동시에 겪어 왔습니다. 한쪽에는 AI가 대충 만들어낸 가짜 버그 리포트가 버그 바운티 채널을 스팸으로 채우는 문제가 있었고(curl 프로젝트가 대표적으로…

Continue Reading오픈AI “패치 더 플래닛” — GPT-5.5-Cyber, 리눅스 커널서 취약점 32건 자동 발견