lockstat 사용법 — /proc/lock_stat으로 커널 락 경합 지점 찾기
멀티코어에서 처리량이 코어 수만큼 늘지 않고 어느 지점부터 오히려 떨어질 때, 원인이 락 경합(lock contention)인 경우가 많다. perf lock은 배포판 커널 그대로도 쓸 수 있어 편하지만 트레이스포인트를 기록하는 방식이라 "측정하는…
리눅스 시스템 디버깅
멀티코어에서 처리량이 코어 수만큼 늘지 않고 어느 지점부터 오히려 떨어질 때, 원인이 락 경합(lock contention)인 경우가 많다. perf lock은 배포판 커널 그대로도 쓸 수 있어 편하지만 트레이스포인트를 기록하는 방식이라 "측정하는…
스레드를 늘렸는데 처리량이 비례해서 오르지 않고, 프로파일을 떠보면 _int_malloc이나 __lll_lock_wait 같은 함수가 상위에 올라오는 경우가 있다. glibc의 malloc은 아레나(arena) 단위로 락을 잡기 때문에, 짧은 객체를 자주 할당·해제하는 코드에서는 이 락이…
스레드를 늘렸는데 처리량이 그대로이거나 오히려 떨어질 때, top은 sys 시간이 높다는 것까지만 알려준다. perf top으로 어느 함수가 CPU를 쓰는지 좁혀도 "락을 기다리느라 잠들어 있던 시간"은 CPU 프로파일에 잡히지 않는다. perf…
프로덕션에서 프로세스가 Segmentation fault로 죽었는데 로그에는 아무것도 안 남았다. 재현도 안 되고, 붙어 있던 디버거도 없다. 이럴 때 유일한 단서가 코어 덤프(core dump)다. 그런데 Ubuntu 24.04를 기본 설정 그대로 쓰면…
CPU 사용률은 낮은데 응답이 느린 서비스를 만나면 perf top이 별 도움이 안 된다. 화면에 뜨는 건 지금 CPU를 쓰고 있는 함수뿐이라, 정작 시간을 잡아먹는 대기 구간은 아무 데도 나오지 않고…
운영 서버가 커널 패닉으로 죽으면 그 순간의 메모리 상태를 확인해야 원인을 알 수 있는데, 재부팅이 끝나면 그 상태는 그대로 사라진다. dmesg에 남는 마지막 몇 줄만으로는 콜스택 전체나 락 상태 같은…
커널 내부에서 어떤 프로세스가 어떤 파일을 열고, 어떤 시스템 콜을 얼마나 호출하는지 확인하고 싶을 때 strace는 대상 프로세스 하나에 붙어야 하고 오버헤드도 커서 운영 중인 서버에서 시스템 전체를 훑어보기엔 부담스럽다.…
클라우드 VM이나 컨테이너에서 perf stat -e cycles를 돌리면 "not supported"만 뜨고 아무것도 안 나오는 경우가 흔하다. 하이퍼바이저가 하드웨어 성능 카운터(PMU)를 게스트에 노출하지 않기 때문인데, IPC나 캐시 미스 같은 마이크로아키텍처 지표는…
버퍼링된 쓰기(write())는 대부분 페이지 캐시에만 반영되고 바로 리턴되지만, dirty 페이지가 일정 기준을 넘으면 커널이 그 프로세스의 write() 호출 자체를 블로킹시켜 디스크가 따라잡을 때까지 강제로 기다리게 한다. 영상 인코더나 로깅 스레드처럼…
최신 커널은 블록 장치마다 기본으로 mq-deadline을 쓰지만, /sys/block/<dev>/queue/scheduler를 열어보면 bfq, kyber 같은 대안이 함께 나열돼 있다. 이름만 봐서는 언제 바꿔야 하는지 감이 안 오는데, 셋은 애초에 최적화하는 목표 자체가 다르다.…