Linux 시니어 성능 최적화 면접

Linux 시니어 (7년+) 성능 최적화 5문항 조회수 6 · 2026-09-21 (월) 07:41:21
1 시스템 I/O 성능 최적화
Hard

Q. 프로덕션 환경에서 특정 애플리케이션의 응답 속도가 갑자기 느려졌습니다. 모니터링 결과 CPU는 30%, 메모리는 50% 사용 중이지만 디스크 I/O wait가 80%에 달합니다. 이 상황에서 병목 지점을 정확히 진단하고 최적화하는 과정을 단계별로 설명해주세요.

iostat, iotop, blktrace 등의 도구를 활용해 어떤 프로세스가 어떤 종류의 I/O를 발생시키는지 분석하는 것부터 시작하세요.

A. 모범답안

먼저 iostat -x 1로 디바이스별 I/O 패턴을 확인하고, iotop으로 I/O를 유발하는 프로세스를 특정합니다. 그 후 해당 프로세스에 대해 strace -e trace=file,desc를 사용해 시스템 콜 레벨에서 어떤 파일에 접근하는지 파악합니다. blktrace와 blkparse로 블록 레이어의 I/O 패턴을 분석해 랜덤 I/O인지 순차 I/O인지 확인합니다. 진단 결과에 따라 파일시스템 마운트 옵션 튜닝(noatime, barrier 설정), I/O 스케줄러 변경(deadline, noop), 애플리케이션 레벨의 배치 처리나 비동기 I/O 적용, 또는 SSD 도입 등의 최적화 전략을 수립합니다. 최종적으로 fio 벤치마크로 개선 효과를 정량적으로 측정합니다.

핵심 포인트
  • • iostat, iotop, blktrace 등 다층적 진단 도구 활용
  • • 시스템 콜 레벨 추적으로 근본 원인 파악
  • • I/O 패턴 분석 후 파일시스템 및 스케줄러 튜닝
  • • 정량적 측정을 통한 개선 효과 검증
답변에 넣으면 좋은 키워드
iostat iotop blktrace I/O scheduler noatime fio strace
실무에서는

데이터베이스나 로그 처리 서버에서 디스크 I/O 병목은 가장 흔한 성능 저하 원인으로, 체계적 진단과 튜닝이 필수입니다.

Follow-up 질문

만약 애플리케이션 코드 수정 없이 인프라 레벨에서만 개선해야 한다면 어떤 우선순위로 접근하시겠습니까?

2 메모리 성능 및 캐싱 전략
Hard

Q. 64GB 메모리를 가진 서버에서 대용량 데이터를 처리하는 애플리케이션이 OOM Killer에 의해 주기적으로 종료됩니다. free 명령 결과 available 메모리는 충분해 보이지만 문제가 반복됩니다. 메모리 사용 패턴을 분석하고 페이지 캐시, 스왑, 메모리 할당 정책을 고려한 최적화 방안을 제시해주세요.

커널의 메모리 관리 메커니즘과 cgroup 메모리 제한, 페이지 캐시 동작 원리를 함께 고려해야 합니다.

A. 모범답안

먼저 /proc/meminfo와 vmstat으로 페이지 캐시, 버퍼, slab 메모리 분포를 확인하고, smem이나 pmap으로 프로세스별 실제 물리 메모리(RSS, PSS) 사용량을 측정합니다. OOM Killer 로그(/var/log/messages)를 분석해 어떤 프로세스가 메모리를 과다 사용했는지 확인합니다. cgroup을 사용 중이라면 memory.limit_in_bytes와 실제 사용량을 비교해 컨테이너 레벨 제한을 점검합니다. vm.swappiness 값을 조정해 페이지 캐시와 스왑 간 균형을 맞추고, transparent hugepage 설정을 검토합니다. 애플리케이션이 대용량 파일을 다룬다면 madvise나 fadvise를 활용해 페이지 캐시 힌트를 제공하거나, 직접 I/O(O_DIRECT)를 고려합니다. 근본적으로는 메모리 프로파일링(valgrind massif, heaptrack)으로 메모리 누수나 과도한 할당을 찾아 애플리케이션을 개선합니다.

핵심 포인트
  • • 프로세스별 실제 메모리 사용량(RSS, PSS) 정확한 측정
  • • 페이지 캐시와 cgroup 메모리 제한의 상호작용 이해
  • • 커널 파라미터 튜닝과 애플리케이션 힌트 제공
  • • 메모리 프로파일링으로 근본 원인 해결
답변에 넣으면 좋은 키워드
OOM Killer RSS PSS cgroup vm.swappiness transparent hugepage madvise smem
실무에서는

컨테이너 환경에서 메모리 제한과 커널 페이지 캐시의 상호작용은 예상치 못한 OOM을 유발하는 주요 원인입니다.

Follow-up 질문

NUMA 아키텍처 환경에서 메모리 성능을 최적화하려면 추가로 어떤 점을 고려해야 합니까?

3 네트워크 처리량 최적화
Hard

Q. 10Gbps 네트워크 인터페이스를 사용하는 서버에서 실제 처리량이 3Gbps를 넘지 못합니다. CPU 사용률은 한 코어만 100%이고 나머지는 유휴 상태입니다. 네트워크 스택의 병목을 진단하고 멀티코어를 활용해 처리량을 개선하는 방법을 설명해주세요.

인터럽트 처리와 패킷 수신 큐의 분산, 그리고 커널의 네트워크 스택 병렬 처리 메커니즘을 살펴보세요.

A. 모범답안

먼저 /proc/interrupts로 네트워크 인터럽트가 특정 CPU에 집중되는지 확인합니다. ethtool -l eth0으로 NIC의 수신 큐 개수를 확인하고, 필요시 ethtool -L로 큐를 늘려 여러 CPU에 분산시킵니다. irqbalance 데몬이 동작 중인지 확인하거나, 수동으로 /proc/irq/IRQ번호/smp_affinity를 설정해 인터럽트를 코어별로 분산합니다. RPS(Receive Packet Steering)와 RFS(Receive Flow Steering)를 활성화해 소프트웨어 레벨에서 패킷 처리를 분산시킵니다. ethtool -g로 링 버퍼 크기를 확인하고 필요시 증가시키며, net.core.netdev_max_backlog과 net.ipv4.tcp_max_syn_backlog 등 커널 네트워크 파라미터를 튜닝합니다. 애플리케이션 레벨에서는 SO_REUSEPORT 소켓 옵션으로 여러 워커 프로세스가 동일 포트를 리스닝하게 해 로드를 분산시킵니다.

핵심 포인트
  • • NIC 멀티큐와 인터럽트 affinity 설정으로 CPU 분산
  • • RPS/RFS를 통한 소프트웨어 레벨 패킷 분산
  • • 링 버퍼 및 커널 네트워크 파라미터 튜닝
  • • SO_REUSEPORT로 애플리케이션 레벨 병렬화
답변에 넣으면 좋은 키워드
ethtool RPS RFS irqbalance smp_affinity SO_REUSEPORT 멀티큐 링 버퍼
실무에서는

고성능 네트워크 서비스에서 단일 코어 병목은 흔한 문제로, 멀티큐와 인터럽트 분산 설정이 필수입니다.

Follow-up 질문

DPDK나 XDP 같은 커널 바이패스 기술을 도입할 때의 트레이드오프는 무엇입니까?

4 파일시스템 및 스토리지 최적화
Medium

Q. 수백만 개의 작은 파일을 저장하는 스토리지 시스템에서 파일 검색과 메타데이터 조회 성능이 크게 저하되고 있습니다. ext4, XFS, Btrfs 등 파일시스템별 특성을 고려해 이 상황에 적합한 최적화 전략과 파일시스템 선택 기준을 설명해주세요.

파일시스템의 inode 구조, 디렉토리 인덱싱 방식, 메타데이터 처리 성능을 중심으로 생각해보세요.

A. 모범답안

작은 파일이 많은 환경에서는 메타데이터 성능이 핵심입니다. ext4는 dir_index 옵션으로 HTree 인덱싱을 활성화해 디렉토리 검색 성능을 개선할 수 있지만, 수백만 파일에는 한계가 있습니다. XFS는 B+tree 기반 디렉토리 구조로 대량 파일 처리에 유리하며, inode64 옵션으로 inode 공간을 최적화할 수 있습니다. 파일시스템 마운트 시 noatime이나 relatime 옵션으로 불필요한 메타데이터 업데이트를 줄입니다. 파일 배치 전략으로 해시 기반 디렉토리 샤딩을 적용해 단일 디렉토리에 파일이 집중되지 않도록 하고, SSD를 사용한다면 파일시스템의 TRIM 지원을 활성화합니다. 근본적으로는 오브젝트 스토리지나 key-value 스토어로의 전환을 검토하는 것도 방법입니다.

핵심 포인트
  • • XFS의 B+tree 구조가 대량 파일 처리에 유리
  • • noatime 등 마운트 옵션으로 메타데이터 업데이트 최소화
  • • 디렉토리 샤딩으로 파일 분산 배치
  • • 용도에 따라 오브젝트 스토리지 전환 고려
답변에 넣으면 좋은 키워드
XFS ext4 dir_index noatime inode 메타데이터 디렉토리 샤딩
실무에서는

CDN 캐시 서버나 로그 스토리지처럼 소형 파일을 대량으로 다루는 시스템에서 파일시스템 선택과 튜닝은 성능을 좌우합니다.

Follow-up 질문

메타데이터 저널링이 성능에 미치는 영향과 저널 모드 선택 기준은 무엇입니까?

5 대규모 부하 대응 및 시스템 확장성
Hard

Q. 트래픽이 급증하는 이벤트를 앞두고 있습니다. 현재 시스템은 평상시 초당 1만 요청을 처리하지만, 이벤트 시에는 10만 요청이 예상됩니다. 수평 확장과 수직 확장을 모두 고려해 시스템 용량을 늘리고, 병목 지점을 사전에 파악하는 부하 테스트 전략과 모니터링 체계를 설명해주세요.

부하 테스트 도구 선택, 단계별 부하 증가 시나리오, 그리고 실시간 병목 감지 방법을 포함해 설명하세요.

A. 모범답안

먼저 wrk, ab, JMeter 등으로 현재 시스템의 한계점을 파악하는 기준선 테스트를 수행합니다. 부하를 단계적으로 증가시키며 CPU, 메모리, 디스크 I/O, 네트워크 대역폭, 파일 디스크립터 등 각 리소스의 포화 지점을 찾습니다. sar, perf, ebpf 기반 도구로 실시간 시스템 메트릭을 수집하고, 응답 시간 백분위수(p95, p99)를 추적합니다. 병목이 CPU라면 수평 확장으로 서버를 추가하고 로드밸런서를 구성하며, 메모리나 I/O라면 캐싱 레이어(Redis, Memcached) 추가를 고려합니다. 커널 파라미터(net.core.somaxconn, fs.file-max, net.ipv4.ip_local_port_range)를 대용량 트래픽에 맞게 튜닝하고, ulimit 설정을 조정합니다. 프로덕션 환경과 동일한 구성의 스테이징에서 실제 트래픽 패턴을 재현하는 카오스 엔지니어링을 수행해 예상치 못한 장애 지점을 발견합니다. 이벤트 당일에는 Grafana와 Prometheus로 실시간 대시보드를 구성하고, 임계치 기반 알람을 설정합니다.

핵심 포인트
  • • 단계적 부하 테스트로 각 리소스의 포화 지점 파악
  • • 응답 시간 백분위수와 시스템 메트릭 동시 모니터링
  • • 병목에 따른 수평/수직 확장 및 캐싱 레이어 추가
  • • 커널 파라미터 튜닝과 카오스 엔지니어링으로 사전 검증
답변에 넣으면 좋은 키워드
wrk perf ebpf somaxconn ulimit 백분위수 카오스 엔지니어링 Prometheus
실무에서는

이커머스 플래시 세일이나 티켓팅 시스템처럼 예측 가능한 트래픽 급증 상황에서 사전 부하 테스트와 용량 계획은 필수입니다.

Follow-up 질문

오토스케일링을 구현할 때 스케일 아웃/인 시점을 결정하는 메트릭은 어떻게 선정하시겠습니까?

댓글 0

로그인 후 댓글을 작성할 수 있습니다.

아직 댓글이 없습니다. 첫 번째 댓글을 남겨보세요!