CHAAANY ARCHIVE
486개의 기록을 주제별로 둘러보세요.
Linux 네트워크가 느릴 때는 용어를 많이 아는 것보다 데이터가 어느 큐에서 기다리고 어느 계층에서 다시 보내지는지를 순서대로 확인하는 편이 유용하다. 애플리케이션 → 소켓 → TCP → qdisc → NIC → 네트워크 경로로 내려가며 같은 시각의 지표를 모으면 “네트워크가 느리다”는 증상을 구체적인 후보로 바꿀 수 있다.브렌던 그렉의 시스템 성능 관점으로 네트워크 용어를 정리하다 보니 ICMP, CIDR, 쿠키, backlog와 오프로드가 한 글에 섞였다. 다시 보니 이 개념들은 같은 진단 단계에 있지 않았다. 여기서는 Linux 호스트의 지연·손실·연결 실패를 좁히는 흐름에 필요한 내용만 남긴다.증상을 먼저 네 종류로 나눈다측정 전에 사용자가 겪는 실패를 구분한다.연결 자체가 느리거나 실패한다: ..
MySQL 복합 인덱스는 여러 단일 인덱스를 합친 목록이 아니라 왼쪽 컬럼부터 정렬된 하나의 키다. 따라서 “선택도가 높은 컬럼을 항상 앞에 둔다”거나 “등호·정렬 컬럼을 차례대로 붙인다”는 규칙만으로 설계하면 실제 쿼리와 어긋날 수 있다.아래 예제는 MySQL 8.4와 InnoDB의 B-tree 인덱스를 기준으로 한다. 먼저 자주 실행되는 쿼리를 고정하고, 후보 인덱스마다 읽는 행과 정렬 비용을 실행 계획으로 비교하는 것이 출발점이다.복합 인덱스는 어떻게 정렬되는가다음 인덱스는 (user_id, status, created_at) 튜플 순서로 정렬된다.CREATE INDEX idx_orders_user_status_createdON orders (user_id, status, created_at);먼저..
MySQL 단일 인덱스는 컬럼 하나를 기준으로 검색 범위를 빠르게 줄일 때 유효하다. WHERE에 등장한 컬럼이라고 모두 인덱스를 만들 필요는 없다. 조건을 적용한 뒤 남는 행의 수, 실제로 반환할 열, 정렬 방식과 쓰기 비용을 함께 봐야 한다.아래 설명은 MySQL 8.4와 InnoDB의 일반 B-tree 보조 인덱스를 기준으로 한다.단일 인덱스는 어떤 일을 하는가사용자를 이메일로 자주 찾는다면 다음 인덱스를 생각할 수 있다.CREATE INDEX idx_users_email ON users (email);이 인덱스는 email 값을 정렬된 검색 키로 저장한다. InnoDB의 보조 인덱스 엔트리에는 행을 찾기 위한 기본 키도 포함된다. 다음 쿼리는 보조 인덱스에서 이메일을 찾은 뒤 기본 키로 전체 행을..
MySQL 인덱스가 빠른 이유를 한 문장으로 줄이면 조건에 맞는 행을 찾기 위해 읽어야 할 페이지를 줄이기 때문이다. 다만 “인덱스가 있으면 B+Tree를 몇 번 내려가 바로 한 행을 찾는다”는 설명만으로는 부족하다. 실제 비용은 저장 엔진, 인덱스 종류, 조건이 반환하는 행 수, 버퍼 풀 적중 여부와 테이블 행을 다시 읽는 횟수에 따라 달라진다.이 글의 예제는 MySQL 8.4의 기본 저장 엔진인 InnoDB와 일반 B-tree 인덱스를 기준으로 한다. 전문 검색·공간 인덱스·MEMORY 엔진의 해시 인덱스는 동작 방식이 다르다.풀 테이블 스캔은 언제 일어나는가다음 테이블에서 email에 별도 인덱스가 없다고 가정해 보자.CREATE TABLE users ( id BIGINT PRIMARY KEY..
RSS 증가, cgroup OOM, latency spike가 함께 보이면 memory leak부터 의심하기 쉽다. 하지만 RSS 하나만으로 원인을 정할 수는 없다. 먼저 관측 범위와 memory pressure를 확인하고, mapping의 backing을 나눈 뒤, application allocation 경로로 내려가야 한다.분석 순서는 다음 다섯 질문으로 정리할 수 있다.증상이 실제인가 → 어떤 memory 종류가 늘었나 → 어느 mapping·cgroup에서 늘었나 → 어떤 code 경로가 만들고 유지하나 → 수정 후 같은 지표가 좋아졌나0단계: host·container·process 범위를 고정한다같은 ‘memory 사용량’이라도 host MemAvailable, cgroup memor..
eBPF 프로그램은 혼자 실행되지 않고 커널이나 사용자 공간에서 발생하는 특정 event에 연결된다. 이 연결 지점을 흔히 hook이라고 부른다. 같은 함수 호출을 관찰하더라도 tracepoint, kprobe, fentry, uprobe는 대상과 안정성, 인자 해석 방식이 다르다.“커널이면 kprobe, 애플리케이션이면 uprobe”만으로 고르면 배포 뒤 symbol이 사라지거나 context 구조가 달라지는 문제를 놓치기 쉽다. 먼저 관찰하려는 event의 의미와 유지해야 할 kernel·binary 범위를 정한다.Hook을 고르는 기준Hook관찰 대상연결 기준변경에 민감한 지점tracepoint커널이 미리 정의한 eventcategory와 event nameevent 제공 여부와 context fi..
eBPF C source를 작성했다고 해서 그 C code가 그대로 kernel에서 실행되는 것은 아니다. compiler가 BPF instruction으로 변환하고, loader가 필요한 relocation을 처리해 kernel에 전달한다. kernel verifier의 검사를 통과한 program만 hook에 attach할 수 있으며, 실행은 interpreter 또는 architecture별 JIT compiler가 만든 native code로 이뤄질 수 있다.전체 흐름을 먼저 연결하면 다음과 같다.restricted C source ↓ clang/LLVMBPF instructions in ELF (+ BTF) ↓ libbpf: open · relocate · loadkernel ..
malloc 호출을 eBPF로 추적한 실습 뒤에는 자연스럽게 이런 질문이 남았다.kernel 안에서 실행되는 program을 사용자가 올릴 수 있다면, system을 망가뜨리지 않는다는 보장은 어디에서 오는가?짧게 답하면 eBPF program은 load 단계에서 verifier의 검사를 받아야 하고, 허용된 program type·attach point·helper의 경계 안에서 실행된다. 하지만 이를 “verifier가 모든 위험을 막는다”거나 “eBPF는 관찰만 하므로 안전하다”로 줄이면 중요한 부분이 빠진다.eBPF의 안전성은 정적 검증, 권한, kernel이 제공한 interface, 운영 통제가 함께 만드는 결과다.load부터 실행까지의 경로일반적인 흐름을 단순화하면 다음과 같다.eBPF by..
/proc//smaps로 익명 메모리가 늘어나는 매핑을 찾았다면 다음 질문은 “어느 호출 경로가 할당을 만들었는가?”다. 이때 eBPF 기반 도구로 사용자 공간 allocator 함수에 uprobe를 붙여 호출 스택과 요청 크기를 관찰할 수 있다.중요한 경계부터 말하면, malloc 호출 횟수만 세어서는 메모리 누수를 증명할 수 없다. 반환된 주소와 크기를 기록하고 대응하는 free를 제거한 뒤, 일정 시간 남아 있는 outstanding allocation을 봐야 누수 후보에 가까워진다.smaps와 할당 추적이 답하는 질문도구답하기 좋은 질문/proc/PID/smaps어떤 매핑과 메모리 성격이 커졌는가?heap profiler언어·런타임이 아는 객체와 할당 지점은 어디인가?eBPF uprobe실행 중인..
프로세스 RSS가 늘었다고 바로 메모리 누수라고 결론 내릴 수는 없다. RSS에는 익명 메모리, 실행 파일과 공유 라이브러리의 파일 매핑, 공유 메모리 등 현재 RAM에 올라온 여러 페이지가 함께 잡힌다.Linux의 /proc//smaps는 이 합계를 가상 메모리 매핑별로 나눠 보여 준다. 원인을 확정하는 도구라기보다, 다음 조사 대상을 좁히는 도구에 가깝다.smaps와 smaps_rollup의 차이pid=1234sudo cat "/proc/$pid/smaps_rollup"sudo less "/proc/$pid/smaps"smaps_rollup: 프로세스 전체의 주요 항목을 합산해 빠르게 본다. 커널에서 제공하는 경우에 사용할 수 있다.smaps: 주소 범위와 권한, 파일 경로를 포함해 매핑 하나씩 본다..
free(ptr)를 호출한 뒤에도 top이나 ps의 RSS가 그대로인 경우가 있다. 이른바 free RSS 문제를 볼 때 그 자체만으로 memory leak이라고 결론 내릴 수도, allocator가 memory를 정상 반환했다고 단정할 수도 없다.핵심은 free()가 보장하는 범위와 RSS가 세는 범위가 다르다는 데 있다. 아래 내용은 Linux에서 glibc allocator를 사용하는 process를 기준으로 한다.free는 allocation의 수명을 끝내는 API다유효한 pointer를 free()하면 application은 그 allocation을 더 이상 사용하면 안 된다. 이후 같은 주소의 byte를 읽거나 쓰는 것은 undefined behavior다.allocator 관점에서는 해당 c..
malloc() 호출은 같은 크기를 요청해도 매번 같은 비용으로 끝나지 않는다. thread-local cache에서 즉시 재사용하는 호출이 있는 반면, arena lock·free chunk 탐색·새 mapping·page fault까지 이어지는 호출도 있다.그래서 malloc 성능을 “O(1)이니 빠르다”로 요약하면 중요한 질문을 놓친다. C API는 malloc()의 시간 복잡도를 보장하지 않으며, 실제 지연은 allocator 구현과 당시 상태에 달려 있다.O(1)은 malloc의 성능 보증이 아니다Big-O는 입력 크기가 커질 때 연산량이 어떻게 증가하는지를 표현한다. 특정 호출의 실제 nanosecond, lock 대기, cache miss, system call 횟수를 보장하지 않는다.더구나..