전체 글134 IRQ와 SoftIRQ 로 인한 성능 저하 판단 IRQ와 SoftIRQ의 기본 개념 및 동작 메커니즘리눅스 커널에서 하드웨어 장치(NIC, NVMe, 타이머 등)와 CPU가 상호작용할 때 핵심이 되는 인터럽트 처리 구조는 Top-half(Hard IRQ)와 Bottom-half(SoftIRQ)로 나뉜다.[Hardware Event] ──> (Top-half: Hard IRQ) ──> [Pending Bit 설정] │ ▼ (CPU 인터럽트 활성화 및 스케줄링) (Bottom-half: SoftIRQ / NAPI) ──> [실제 데이터 처리 / sk_buff 생성] 1. Hard IRQ (Top-half)정의: 하드웨어가.. 2026. 8. 31. 파일시스템의 이해 1. 가상 파일 시스템 (VFS): 리눅스의 위대한 통합 계층리눅스는 ext4, XFS, NFS, FAT32 등 성격이 완전히 다른 파일 시스템들을 동시에 지원한다. 사용자가 read() 시스템 콜을 호출할 때, 대상이 하드디스크인지 네트워크 드라이브인지 신경 쓰지 않아도 되는 이유는 바로 VFS(Virtual File System) 덕분이다.VFS는 일종의 객체 지향적 추상화 계층인데, 커널 내부적으로 파일 시스템이 가져야 할 공통적인 구조체를 정의하고, 실제 파일 시스템은 이 구조체의 함수 포인터(인터페이스)를 자신의 구현체로 채우는 방식이다.VFS를 지탱하는 4대 객체VFS는 다음 네 가지 핵심 객체를 중심으로 돌아갑니다.슈퍼블록 (Super Block): 특정 파일 시스템 전체에 대한 정보를 담고.. 2026. 5. 2. 2. ebpf 활용 이슈 해결 굳이 적는이유태어나서 잡은 원인중에 진짜 레전드로 어려워서 안적으면 서러워서....... eBPF 활용 시스템콜 추적 및 원인규명0. 본 문서의 역할포렌식 보고서 가 답한 것: "무엇이 깨졌는가" (재현 가능한 코드 버그, 3-region 패턴, sparse hole 존재).본 문서가 답하는 것: "어떻게 깨졌는가" — 어떤 syscall 이 호출됐고, 언제, 왜 호출됐는지를 커널 레벨에서 실시간 관측 한 결과.핵심 결론 한 줄:두 개의 fd 가 같은 파일(inode)을 동시에 가리키는 race 가 있었고, 두 번째 open 의 O_TRUNC 가 기존 파일을 날린 직후 첫 번째 fd 의 stale offset 으로 write 가 들어가면서 sparse hole 이 생성됨.1. 왜 eBPF 를 썼나1-1... 2026. 4. 28. 1. 레전드 이슈 발생 압축파일 손상 관련 해결 해보자~~1. 배경TPS 1,000 이상 나올시 해당 데이터들을 압축하고 전송하는 쓰레드에서 문제가 생김.2. 첫 증상2-1. 상황조건: TPS 500 × 60s (트래픽 body size = 4.3kb)Loader 결과: 29,761 요청 전송, 100% 성공2-2. 관측클라이언트(loader) 정상, 서버상태는 극히 정상손상은 agent 단일 파일. 같은 run 의 다른 파일은 정상gzip 자체는 decompress 가 일부 가능 — 앞부분은 valid gzip stream, 뒷부분이 이상한 상태 ->? 뭐임 압축파일 자체의 문제2-3. 이 시점에 세운 가설 (나중에 틀렸음을 확인)"파일이 특정 크기를 넘으면 뭔가 터진다"이 가설에 기반해 duration 을 60s → 30s.. 2026. 4. 28. 이전 1 2 3 4 ··· 34 다음