kgdb로 원격 시스템 라이브 디버깅하기
커널이 패닉 없이 그냥 멈추거나, 특정 syscall 경로에서만 간헐적으로 이상 동작을 보이는 경우 printk만으로는 원인을 좁히기 어렵다. dmesg에 로그를 더 찍고 재현하고 다시 빌드하는 사이클은 타이밍에 민감한 버그일수록 무력해진다. 이럴…
리눅스 시스템 디버깅
strace -f로 멀티프로세스/스레드 시스템 콜 한 번에 추적하기
strace nginx나 strace sh script.sh로 걸어보면 부모 프로세스의 fork/execve까지만 잡히고, 실제 작업을 하는 워커/자식 프로세스 내부는 안 보인다. -f(--follow-forks)가 이 문제를 해결한다. 이 글에서는 -f/-ff/-e trace=로 멀티프로세스·멀티스레드 프로그램을 추적하는 방법을…
pahole과 BTF로 구조체 메모리 레이아웃 확인하기 — 패딩부터 커널 라이브 구조체까지
구조체 필드 순서가 메모리 낭비와 캐시 효율에 영향을 준다는 건 다들 안다. 문제는 "그래서 지금 이 구조체가 얼마나 낭비하고 있는지"를 눈으로 확인하기가 쉽지 않다는 것이다. pahole은 DWARF 디버그 정보나 커널의…
GDB record full로 역방향 디버깅하기 — 하드웨어 카운터 없이 되감는 rr 대안
워치포인트로 "이 변수가 언제 바뀌는지"는 잡을 수 있어도, 그 값이 왜 그렇게 됐는지 되짚어 올라가려면 결국 브레이크포인트를 다시 걸고 처음부터 재실행하기를 반복하게 된다. Mozilla의 rr 같은 record-and-replay 디버거는 실행을 통째로…
KFENCE: Kernel Electric-Fence
KASAN은 힙 오버플로우나 use-after-free를 잡아내는 데 강력하지만, 모든 할당에 리다이렉션 존(redzone)과 섀도 메모리 검사를 붙이는 방식이라 오버헤드가 크고 프로덕션에 상시 켜두기는 부담스럽다. KFENCE(Kernel Electric-Fence)는 이 문제를 확률적 샘플링으로 우회한다 —…
perf top으로 실시간 락 함수 프로파일링하는 방법
락 경합(lock contention)은 멀티코어 시스템에서 흔한 성능 병목 원인이다. CPU 사용률은 높은데 실제 작업 처리량은 그대로거나 오히려 떨어진다면, 스레드들이 실제 일을 하는 대신 서로 락을 기다리며 시간을 보내고 있을 가능성이…
topdown-tool로 Arm Neoverse 성능 분석하기
perf stat로 cycles, instructions, cache-misses 몇 개를 조합해 IPC와 미스율을 계산하는 건 코어 하나짜리 애플리케이션이라면 충분하다. 그런데 병목이 프론트엔드인지 백엔드인지까지 확인한 다음, 백엔드라면 그게 L1인지 L2인지 라스트레벨 캐시인지 TLB인지까지 계속…
delayacct 사용법
CPU 사용률은 낮은데 프로세스가 유독 느리게 느껴질 때가 있다. top이나 ps는 프로세스가 CPU를 얼마나 썼는지는 보여주지만, 그 프로세스가 CPU를 기다리느라 얼마나 시간을 날렸는지, 디스크 I/O나 스왑·메모리 회수 때문에 얼마나 블로킹됐는지는…
bpftrace로 리눅스 시스템 콜과 지연시간 디버깅하기
특정 프로세스가 어떤 시스템 콜을 얼마나 자주 호출하는지, 혹은 파일 하나를 여는 데 왜 갑자기 수십 밀리초가 걸리는지 알아내야 할 때 strace부터 떠올리기 쉽다. 하지만 strace는 매 시스템 콜마다 대상…
LOCKDEP 사용법
여러 개의 락(lock)을 다루는 드라이버나 서브시스템을 작성하다 보면, 어떤 경로에서는 lock_a를 먼저 잡고 lock_b를 나중에 잡는데 다른 경로에서는 반대로 lock_b를 먼저 잡는 실수를 저지르기 쉽다. 이런 ABBA 데드락은 두 경로가…