운영체제 시니어 트러블슈팅 면접

D state 프로세스는 I/O 작업을 기다리며 인터럽트할 수 없는 상태로, 디스크나 네트워크 I/O 병목을 의미합니다. iostat, iotop으로 디스크 I/O 대기 시간과 iowait%를 확인하고, vmstat으로 블록 I/O 통계를 분석해야 합니다. /proc/[pid]/stack을 통해 커널 스택 트레이스를 확인하여 어떤 시스템 콜에서 블로킹되는지 파악합니다. 스토리지 레이어에서는 디스크 큐 깊이, RAID 컨트롤러 상태, 파일시스템 메타데이터 경합을 점검해야 합니다. 단기 해결책으로는 I/O 스케줄러 변경(deadline, noop), 장기적으로는 스토리지 업그레이드나 애플리케이션의 I/O 패턴 최적화(배치 처리, 비동기 I/O)를 고려해야 합니다. 재발 방지를 위해 iowait, disk latency에 대한 알림을 설정하고 I/O 부하 테스트를 정기적으로 수행해야 합니다.

glibc malloc은 작은 메모리는 arena에서 관리하고, MMAP_THRESHOLD(기본 128KB) 이상은 mmap으로 직접 할당합니다. 64MB 단위 할당은 mmap 영역이며, malloc_trim()이 호출되지 않으면 해제 후에도 OS에 반환되지 않습니다. /proc/[pid]/smaps에서 각 메모리 영역의 Rss, Pss, Referenced 값을 비교하여 실제 사용 중인 메모리와 할당만 된 메모리를 구분해야 합니다. malloc_stats(), mallopt()로 arena 개수와 메모리 할당 정책을 확인하고, MALLOC_MMAP_THRESHOLD_ 환경변수로 threshold를 조정할 수 있습니다. strace로 mmap/munmap 시스템 콜 패턴을 추적하고, valgrind나 AddressSanitizer로 실제 메모리 누수 여부를 검증해야 합니다. 해결책으로는 주기적인 malloc_trim() 호출, jemalloc이나 tcmalloc 같은 대체 allocator 사용, 또는 메모리 풀 패턴으로 애플리케이션 재설계를 고려할 수 있습니다.

ext4에서 대량의 파일이 있는 디렉토리는 dir_index(HTree) 기능이 활성화되어 있어도 디렉토리 엔트리 조회 시 성능 저하가 발생할 수 있습니다. dumpe2fs나 tune2fs로 dir_index 플래그 활성화 여부를 확인하고, debugfs의 htree 명령으로 디렉토리 인덱스 구조를 분석해야 합니다. stat 시스템 콜이 느리다면 getdents64 호출 시 대량의 디렉토리 엔트리를 순회하는 것이 원인이며, strace로 시스템 콜 레이턴시를 측정할 수 있습니다. 단기 해결책으로는 디렉토리를 해시 기반 서브디렉토리로 재구성하거나(예: 파일명 첫 2자로 분산), 파일 접근 패턴을 최적화하여 stat 호출을 줄여야 합니다. 장기적으로는 XFS 파일시스템 마이그레이션(더 나은 대용량 디렉토리 처리), 또는 객체 스토리지나 데이터베이스 기반 메타데이터 관리로 아키텍처를 변경하는 것을 고려해야 합니다. 재발 방지를 위해 디렉토리당 파일 수 제한 정책과 모니터링을 수립해야 합니다.

CLOSE_WAIT 상태는 원격에서 FIN을 보냈지만 애플리케이션이 소켓을 close()하지 않아 발생하며, 이는 애플리케이션의 소켓 누수를 의미합니다. netstat의 overflowed는 accept 큐가 가득 차서 SYN+ACK를 받은 연결을 처리하지 못한 경우이며, somaxconn과 애플리케이션의 listen backlog 설정을 확인해야 합니다. lsof나 ss -p로 CLOSE_WAIT 소켓을 소유한 프로세스를 식별하고, 애플리케이션 코드에서 연결 종료 처리 로직(finally 블록, connection pool 관리)을 점검해야 합니다. /proc/sys/net/ipv4/tcp_abort_on_overflow를 1로 설정하면 큐 오버플로우 시 명시적으로 RST를 보내며, net.core.somaxconn과 net.ipv4.tcp_max_syn_backlog를 증가시켜 연결 대기 큐를 확장할 수 있습니다. 근본 원인은 애플리케이션이 accept()를 충분히 빠르게 호출하지 못하거나 소켓을 제대로 닫지 않는 것이므로, 비동기 I/O 모델 도입, 워커 스레드 증설, graceful shutdown 로직 개선이 필요합니다. 재발 방지를 위해 CLOSE_WAIT 소켓 수와 accept queue overflow를 모니터링해야 합니다.

pthread_mutex는 커널의 futex(fast userspace mutex)를 사용하며, 경합 시 futex 시스템 콜로 대기 큐에 들어갑니다. strace -f -e futex로 각 스레드의 futex 대기 상태를 추적하고, 어떤 주소의 뮤텍스를 기다리는지 확인할 수 있습니다. gdb로 모든 스레드의 백트레이스를 수집하고(thread apply all bt), 각 스레드가 보유한 락과 대기 중인 락을 매핑하여 순환 대기 그래프를 그려야 합니다. /proc/[pid]/task/[tid]/wchan으로 각 스레드가 대기 중인 커널 함수를 확인하고, perf record -g로 스택 샘플을 수집하여 락 경합 핫스팟을 식별할 수 있습니다. 사후 분석을 위해서는 ulimit -c unlimited 설정 후 kill -ABRT로 코어 덤프를 생성하거나, gcore로 라이브 프로세스의 코어를 덤프해야 합니다. 근본 해결책은 락 획득 순서를 일관되게 강제하거나(lock ordering), 타임아웃 기반 락(pthread_mutex_timedlock), 또는 락 프리 자료구조 도입을 고려해야 합니다. 재발 방지를 위해 ThreadSanitizer나 Helgrind 같은 데드락 탐지 도구를 CI에 통합해야 합니다.

컨텍스트 스위치 급증은 과도한 스레드 경합, 인터럽트 처리 부하, 또는 스케줄러 정책 변경이 원인일 수 있습니다. pidstat -w로 프로세스별 voluntary/involuntary 컨텍스트 스위치를 구분하여, voluntary가 높으면 I/O 대기나 락 경합, involuntary가 높으면 CPU 시간 만료나 우선순위 선점을 의미합니다. /proc/interrupts로 인터럽트 분포를 확인하고, 특정 CPU 코어에 인터럽트가 집중되는지 점검해야 하며, irqbalance 데몬 상태와 /proc/irq/[num]/smp_affinity 설정을 확인합니다. perf sched record로 스케줄링 이벤트를 기록하고 perf sched latency로 스케줄 지연을 분석하여 어떤 프로세스가 CPU를 과도하게 경합하는지 파악합니다. 네트워크 카드의 인터럽트 코어레싱이나 NUMA 노드 배치 문제도 확인해야 하며, ethtool -l로 NIC의 RX/TX 큐 수와 CPU 매핑을 점검합니다. 해결책으로는 IRQ affinity 조정, 애플리케이션 스레드 풀 크기 최적화, CPU pinning으로 캐시 지역성 개선, 또는 인터럽트 통합(interrupt coalescing) 설정을 고려할 수 있습니다.

커널 패닉 분석은 crash 유틸리티로 vmcore와 디버그 심볼(debuginfo 패키지)을 로드하여 시작합니다. crash 내에서 bt(backtrace) 명령으로 패닉 시점의 커널 스택을 확인하고, dis(disassemble)로 RIP 주소의 어셈블리 코드를 분석하여 어떤 명령에서 실패했는지 파악합니다. log 명령으로 커널 메시지 버퍼를 확인하고, mod 명령으로 로드된 모듈 목록과 주소를 점검하여 문제 모듈을 식별합니다. NULL 포인터 역참조라면 해당 모듈의 버그이므로 커널 버전과 모듈 버전을 확인하고, 알려진 버그인지 upstream 패치가 있는지 검색해야 합니다. 단기 대응으로는 문제 모듈을 블랙리스트에 추가하거나(/etc/modprobe.d/blacklist.conf), 모듈 파라미터를 조정하여 회피할 수 있습니다. kdump 설정을 점검하여 향후 패닉 시 자동으로 덤프가 수집되도록 하고, kernel.panic 파라미터로 패닉 후 자동 재부팅 시간을 설정합니다. 재발 방지를 위해 커널과 드라이버를 최신 안정 버전으로 유지하고, 하드웨어 오류 가능성도 함께 점검해야 합니다.