DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브 DevOps 도구 및 베스트 프랙티스 마스터 - DevOps 지식 허브

Linux 리소스 고갈 문제 해결: CPU, 메모리 및 디스크 공간

실용적인 명령어, 안전한 정리 단계 및 근본 원인 확인을 통해 Linux CPU, 메모리 및 디스크 고갈 문제를 해결합니다.

Linux 리소스 고갈 문제 해결: CPU, 메모리 및 디스크 공간

Linux 서버의 CPU, 메모리 또는 디스크 공간이 부족해지면 첫 번째 증상은 일반적으로 모호합니다. 사이트가 느려지고, SSH 로그인이 멈추고, 배포가 실패하거나, 서비스가 계속 다시 시작됩니다. 인시던트를 가장 빠르게 해결하는 방법은 어떤 리소스가 고갈되었는지 식별한 다음 그 뒤에 있는 프로세스나 파일 시스템을 찾는 것입니다.

가장 위험이 적은 확인부터 먼저 수행하세요. top, free, df, du, vmstat, journalctl과 같은 읽기 전용 명령어는 시스템을 변경하지 않고 상황을 파악할 수 있게 해줍니다. 프로세스 종료 및 파일 삭제가 필요할 수 있지만, 이는 진단이 아닙니다.

원인 식별: 시스템 리소스 모니터링

리소스 고갈 문제를 해결하기 전에 어떤 리소스가 과도하게 사용되고 있으며 어떤 프로세스가 원인인지 정확히 파악해야 합니다. Linux는 이를 위한 풍부한 명령줄 도구 세트를 제공합니다.

CPU 사용량 모니터링

높은 CPU 사용량은 시스템을 느리고 응답하지 않게 만들 수 있습니다. 종종 실행 오류가 있는 프로세스, 요구 사항이 많은 애플리케이션 또는 비효율적인 스크립트로 인해 발생합니다.

  • top: 이는 필수적인 실시간 시스템 모니터입니다. 기본적으로 CPU 사용량별로 정렬된 동적 프로세스 목록을 표시합니다. 전체 CPU 사용률, 메모리 사용량 및 개별 프로세스 세부 정보를 볼 수 있습니다.

    top

    top 내에서 1을 누르면 개별 CPU 코어 사용량을 볼 수 있습니다. P를 누르면 CPU 사용량별로 정렬됩니다. 지속적으로 높은 CPU 비율을 소비하는 프로세스를 찾으십시오.

  • htop: top의 향상된 대화형 버전입니다. 사용자 친화성, 색상화된 출력 및 더 쉬운 탐색으로 인해 종종 선호됩니다.

    htop

    top과 유사하게 htop은 CPU 사용량별 정렬을 허용하고 자세한 프로세스 정보를 제공합니다.

  • mpstat: sysstat 패키지의 일부로, mpstat은 프로세서별 사용량, 인터럽트 수 및 컨텍스트 스위치를 포함한 자세한 CPU 통계를 제공합니다.

    mpstat -P ALL 1

    이 명령은 매초 모든 코어의 CPU 통계를 표시합니다.

또한 CPU 코어 수에 대한 로드 평균을 확인하십시오:

uptime
nproc

로드 평균 8은 2코어 VM과 32코어 호스트에서 매우 다른 의미를 갖습니다. 로드에는 무중단 I/O를 기다리는 작업도 포함되므로, CPU 사용량이 낮은 높은 로드 평균은 실제로 디스크나 네트워크 스토리지를 가리킬 수 있습니다.

메모리 사용량 모니터링

시스템에서 사용 가능한 RAM과 스왑 공간이 부족해지면 디스크 공간을 가상 메모리로 사용하기 시작하는데, 이는 현저히 느리며 심각한 성능 저하로 이어집니다.

  • free -h: 시스템의 사용 가능한 물리적 메모리와 스왑 메모리의 총량, 사용량, 그리고 커널이 사용하는 버퍼와 캐시를 표시합니다. -h 플래그는 출력을 사람이 읽기 쉬운 형식(예: MB, GB)으로 만듭니다.

    free -h

    available 메모리와 used 스왑 공간에 주목하십시오. 높은 스왑 사용량은 RAM이 충분하지 않음을 나타냅니다.

  • top / htop: top과 htop 모두 프로세스별 메모리 사용량을 보여줍니다. %MEM 값이 높은 프로세스를 찾으십시오.

  • vmstat: 가상 메모리 통계를 보고합니다. 프로세스, 메모리, 페이징, 블록 IO, 트랩 및 CPU 활동에 대한 정보를 표시할 수 있습니다.

    vmstat 5

    이 명령은 5초마다 통계를 보고합니다. si(스왑인) 및 so(스왑아웃) 열을 확인하십시오. 높은 값은 상당한 메모리 스와핑이 발생하고 있음을 나타냅니다.

가능한 OOM 종료의 경우 커널 로그를 확인하십시오:

dmesg -T | grep -i 'killed process'
journalctl -k --since "1 hour ago" | grep -i oom

OOM 종료는 인시던트를 변경합니다. 즉각적인 질문은 어떤 프로세스가 종료되었는지, 왜 사용 가능한 메모리를 초과했는지, systemd 또는 오케스트레이터가 이를 다시 시작했는지입니다.

디스크 공간 모니터링

가득 찬 디스크 파티션은 애플리케이션이 데이터를 쓰지 못하게 하고, 오류를 발생시키며, 시스템 부팅을 방해할 수도 있습니다.

  • df -h: 파일 시스템 디스크 공간 사용량을 보고합니다. -h 플래그는 출력을 사람이 읽기 쉽게 만듭니다.

    df -h

    이 명령은 마운트된 모든 파일 시스템을 나열하고 총 크기, 사용 공간, 사용 가능한 공간 및 마운트 지점을 표시합니다. 사용량이 100%에 가깝거나 도달한 파티션을 찾으십시오.

  • du -sh <directory>: 주어진 디렉토리의 파일 공간 사용량을 추정합니다. -s 플래그는 요약하고, -h는 사람이 읽기 쉽게 만듭니다.

    du -sh /var/log/*

    이를 사용하여 가장 많은 디스크 공간을 소비하는 하위 디렉토리를 찾으십시오.

inode 사용량도 확인하십시오:

df -ih

파일 시스템에 여유 기가바이트가 있어도 inode가 부족하면 파일을 생성할 수 없습니다. 이는 수백만 개의 작은 파일(캐시 항목, 메일 큐, 세션 파일, 빌드 아티팩트 또는 제대로 회전되지 않은 로그)에서 발생합니다.

리소스 고갈 문제 해결

문제가 되는 리소스와 문제를 일으키는 프로세스를 식별한 후에는 문제를 해결하기 위한 조치를 취할 수 있습니다.

높은 CPU 사용량 처리

  1. 프로세스 식별: top 또는 htop을 사용하여 높은 CPU를 소비하는 프로세스 ID(PID)를 찾습니다.
  2. 프로세스 조사: 프로세스가 무엇인지 확인합니다. 사용자 애플리케이션, 시스템 서비스 또는 예상치 못한 것입니까?
    • 정당한 높은 사용량: 합법적인 애플리케이션이 많은 CPU를 사용하는 경우(예: 소프트웨어 컴파일, 비디오 인코딩), 완료될 때까지 기다리거나, 비수기 시간으로 예약하거나, 하드웨어를 업그레이드해야 할 수 있습니다.
    • 실행 오류 프로세스: 프로세스가 루프에 갇히거나 의도치 않게 과도한 CPU를 소비하는 경우, 다시 시작해 볼 수 있습니다. 그래도 작동하지 않으면 종료해야 할 수 있습니다.
  3. 프로세스 종료 (주의해서 사용!): kill 명령을 사용하여 프로세스에 신호를 보낼 수 있습니다. 가장 일반적인 신호는 다음과 같습니다:
    • SIGTERM (15): 프로세스에 정상 종료를 요청합니다.
    • SIGKILL (9): 프로세스를 즉시 강제로 종료합니다. 프로세스가 정리 작업을 수행할 수 없으므로 최후의 수단으로 사용해야 합니다.
    # PID 1234 프로세스를 정상 종료
kill 1234

# PID 1234 프로세스를 강제 종료
kill -9 1234
  4. 로그 확인: 문제가 있는 프로세스와 관련된 오류에 대해 시스템 로그(예: /var/log/syslog, /var/log/messages, 애플리케이션별 로그)를 검사합니다.
  5. 애플리케이션/스크립트 최적화: 높은 CPU 사용량이 비효율적인 애플리케이션이나 스크립트로 인한 경우 코드나 구성을 최적화하는 것을 고려하십시오.

높은 CPU가 항상 나쁜 것은 아닙니다. 짧은 시간 동안 모든 코어를 사용하는 배치 작업은 괜찮을 수 있습니다. 요청이 뒤에서 대기하는 동안 단일 스레드 프로세스가 한 코어의 100%에 고정되어 있는 것은 다릅니다. 지속 시간, 사용자 영향 및 프로세스가 바쁠 것으로 예상되는지 여부를 확인하십시오.

서비스를 다시 시작하기 전에 더 많은 컨텍스트가 필요한 경우 스냅샷을 캡처하십시오:

ps -fp <pid>
sudo lsof -p <pid> | head
sudo strace -p <pid> -tt -T -f

프로덕션 시스템에서 strace를 주의해서 사용하십시오. 오버헤드를 추가할 수 있지만, 짧은 샘플은 프로세스가 루핑 중인지, 파일을 기다리는 중인지, 네트워크 호출에 실패하는지, 또는 동일한 리소스를 반복적으로 여는지 여부를 알려줍니다.

메모리 누수 및 고갈 해결

메모리 누수는 프로그램이 더 이상 필요하지 않은 메모리를 해제하지 못해 점차 모든 사용 가능한 RAM을 소비할 때 발생합니다. 이는 과도한 스와핑과 시스템 응답 불능으로 이어질 수 있습니다.

  1. 프로세스 식별: top 또는 htop을 사용하여 시간이 지남에 따라 꾸준히 증가하는 높은 메모리(%MEM) 또는 상주 세트 크기(RSS) 값을 가진 프로세스를 찾습니다.
  2. 프로세스 조사: 애플리케이션의 특성을 확인합니다. 잠재적인 메모리 문제가 있는 알려진 애플리케이션입니까, 아니면 사용자 정의 애플리케이션입니까?
  3. 애플리케이션/서비스 다시 시작: 종종 애플리케이션이나 서비스를 다시 시작하면 누적된 메모리를 해제하여 메모리 누수를 일시적으로 해결할 수 있습니다.
    # 예: Apache 웹 서버 다시 시작
sudo systemctl restart apache2
  4. 애플리케이션별 모니터링 확인: 많은 애플리케이션(예: 웹 서버, 데이터베이스)에는 메모리 문제를 진단하는 데 도움이 되는 자체 모니터링 도구나 로그가 있습니다.
  5. 코어 덤프 분석: 중요한 애플리케이션의 경우 코어 덤프를 활성화하고 디버깅 도구(예: gdb)를 사용하여 누수가 발생할 때 메모리 상태를 분석해야 할 수 있습니다. 이는 고급 문제 해결 단계입니다.
  6. 스왑 공간 늘리기 (임시 조치): 누수를 즉시 해결할 수 없는 경우 스왑 공간을 늘려 더 많은 가상 메모리를 제공할 수 있습니다. 그러나 이는 해결책이 아닌 임시 방편입니다.
  7. 하드웨어 업그레이드: 시스템이 워크로드에 대해 지속적으로 메모리가 부족한 경우 실제 RAM을 추가해야 할 수 있습니다.

더 나은 메모리 조사는 시간에 따른 변화를 관찰합니다. 하나의 top 스크린샷은 현재 누가 큰지만 알려줍니다. 누수는 추세입니다.

while true; do
  date
  ps -eo pid,comm,rss,%mem --sort=-rss | head -15
  sleep 60
done

트래픽이 감소한 후에도 동일한 프로세스가 샘플 간에 꾸준히 증가하면 누수 신호가 더 강력합니다. 피크 트래픽 중에 여러 프로세스가 함께 증가하면 워크로드가 단순히 용량이나 동시성 제한을 초과할 수 있습니다.

systemd 서비스의 경우 메모리 제한이 이미 있는지 확인하십시오:

systemctl show <service> -p MemoryCurrent -p MemoryMax

컨테이너의 경우 호스트 수준의 free -h는 정상으로 보일 수 있지만 컨테이너가 자체 제한에 도달할 수 있습니다. docker stats, kubectl top pod 또는 OOM 종료에 대한 오케스트레이터 이벤트를 확인하십시오.

가득 찬 디스크 파티션 관리

디스크 파티션이 가득 차면 다양한 시스템 오류가 발생할 수 있습니다. 일반적으로 즉각적인 조치가 필요합니다.

  1. 가득 찬 파티션 식별: df -h를 사용하여 용량이 100%인 파티션을 찾습니다.
  2. 큰 파일/디렉토리 찾기: du -sh 또는 du -h --max-depth=1 <directory>를 사용하여 디렉토리 트리를 탐색하고 공간을 소비하는 항목을 찾습니다.
    # 루트 파티션에서 가장 큰 디렉토리 찾기
sudo du -h --max-depth=1 / | sort -rh
    일반적인 원인으로는 로그 파일(/var/log), 임시 파일(/tmp), 패키지 캐시 및 사용자 데이터가 있습니다.
  3. 로그 파일 정리: 로그 파일은 매우 커질 수 있습니다. 오래된 로그를 안전하게 삭제하거나 로그 순환(logrotate)을 구성하여 크기를 자동으로 관리할 수 있습니다.
    • 오래된 로그 삭제: 주의하고 현재 활성 로그를 삭제하지 않는지 확인하십시오. find를 사용하여 특정 일 수보다 오래된 파일을 삭제할 수 있습니다.
      # /var/log/myapp에서 30일보다 오래된 .log 파일 삭제
sudo find /var/log/myapp -name "*.log" -type f -mtime +30 -delete
    • 로그 순환: 서비스에 대해 logrotate가 올바르게 구성되었는지 확인하십시오. 일반적으로 매일 실행되며 오래된 로그를 보관하고 삭제합니다.
  4. 패키지 관리자 캐시 지우기: 패키지 관리자는 종종 다운로드한 패키지 파일을 보관합니다. 이를 지우면 상당한 공간을 확보할 수 있습니다.
    • Debian/Ubuntu (apt):
      sudo apt autoremove
sudo apt clean
    • CentOS/RHEL/Fedora (yum/dnf):
      sudo yum autoremove  # 또는 dnf autoremove
sudo yum clean all   # 또는 dnf clean all
  5. 사용하지 않는 패키지 제거: 더 이상 필요하지 않은 소프트웨어를 제거하십시오.
    • Debian/Ubuntu: sudo apt remove <package_name>
    • CentOS/RHEL/Fedora: sudo yum remove <package_name> 또는 sudo dnf remove <package_name>
  6. 임시 디렉토리 확인: /tmp의 파일은 특히 재부팅 후에 안전하게 삭제할 수 있는 경우가 많지만, 애플리케이션이 적극적으로 사용 중인 경우 주의하십시오.
  7. 휴지통 비우기: 데스크탑 환경을 사용하는 경우 사용자 휴지통을 확인하십시오.
  8. 파티션 크기 조정 고려: 공간이 지속적으로 문제이고 정리만으로 충분하지 않은 경우 파티션 크기를 조정하거나 스토리지를 추가해야 할 수 있습니다. 이는 파티션을 마운트 해제하거나 라이브 환경에서 부팅해야 할 수 있는 고급 작업입니다.

여전히 열려 있는 삭제된 파일에 주의하십시오. 실행 중인 프로세스가 여전히 파일 핸들을 보유하고 있기 때문에 큰 로그 파일을 제거한 후에도 df는 파일 시스템이 가득 찬 것으로 표시할 수 있습니다.

sudo lsof +L1

삭제된 파일이 여전히 열려 있는 경우, 소유 서비스를 다시 시작하거나 리로드하면 공간이 해제됩니다. 영향을 이해하지 않고 인시던트 중간에 데이터베이스나 중요한 서비스를 다시 시작하지 마십시오.

저널 로그의 경우 파일을 수동으로 삭제하는 것보다 journalctl 정리를 선호하십시오:

journalctl --disk-usage
sudo journalctl --vacuum-time=14d

Docker 호스트의 경우 컨테이너 로그와 사용하지 않는 이미지를 확인하십시오:

docker system df
docker ps --size

프로덕션 호스트에서 광범위한 prune 명령을 맹목적으로 실행하지 마십시오. 이미지, 빌드 캐시, 중지된 컨테이너 및 누군가 유지하기를 기대했던 네트워크를 제거할 수 있습니다.

압박 속에서 작동하는 분류 순서

모든 것이 느릴 때는 고정된 순서를 사용하여 이론 사이를 오가지 않도록 하십시오.

  1. 호스트에 연결할 수 있고 읽기 전용이 아닌지 확인:

    uptime
date
mount | grep ' ro,'

  2. CPU 및 로드 확인:

    top
uptime

  3. 메모리 및 스왑 확인:

    free -h
vmstat 1 5

  4. 디스크 공간 및 inode 확인:

    df -h
df -ih

  5. 최근 커널 및 서비스 오류 확인:

    journalctl -p warning..alert --since "30 minutes ago"
journalctl -k --since "30 minutes ago"

이 순서는 CPU 포화, 스왑 폭풍, 가득 찬 파일 시스템, inode 고갈, OOM 종료 및 스토리지 오류와 같은 일반적인 실패를 빠르게 포착합니다.

최악이 아닌 즉각적인 수정 선택

중단 중에는 영구적인 수정이 준비되기 전에 단기적인 수정이 필요할 수 있습니다.

CPU 고갈의 경우, 특히 상태를 쓰는 소프트웨어의 경우 kill -9보다 정상적인 서비스 재시작이 더 안전할 수 있습니다. 하나의 백그라운드 작업이 사용자 트래픽을 굶주리게 하는 경우 우선 순위를 낮추십시오:

sudo renice +10 -p <pid>
sudo ionice -c2 -n7 -p <pid>

메모리 고갈의 경우, 스왑을 추가하고 기대하는 것보다 동시성을 줄이는 것이 종종 더 안전합니다. 웹 작업자 수를 낮추고, 배치 작업을 일시 중지하거나, 비용이 많이 드는 기능을 일시적으로 비활성화하십시오. 스왑은 시간을 벌 수 있지만, 과도한 스왑은 일반적으로 명확한 실패를 느린 실패로 바꿉니다.

디스크 고갈의 경우, 이해하는 파일을 삭제하거나 순환시키십시오. 좋은 후보는 오래된 압축 로그, 패키지 캐시, 쓸모없는 빌드 아티팩트 및 중지된 작업의 임시 파일입니다. 나쁜 후보는 데이터베이스 파일, 활성 로그, 애플리케이션 데이터 디렉토리 아래의 알 수 없는 파일 및 설명할 수 없는 모든 것입니다.

캡처할 근본 원인 노트

시스템이 안정화된 후에는 무엇이 변경되었는지 기록하십시오. 유용한 노트는 구체적입니다:

  • 고갈된 정확한 파일 시스템 또는 리소스.
  • 관련된 프로세스, 사용자, 서비스, 컨테이너 또는 cron 작업.
  • 이를 증명한 명령 출력.
  • 취해진 즉각적인 조치.
  • 필요한 영구적인 수정.

이는 그 자체를 위한 서류 작업이 아닙니다. 배포 후 디버그 로그가 증가하여 /var가 가득 찼거나, 작업자 수가 두 배로 증가했을 때 메모리 압력이 시작되었음을 알면 다음 인시던트가 훨씬 쉬워집니다.

예방을 위한 모범 사례

  • 정기적인 모니터링: top, htop, free, df 및 전용 모니터링 솔루션(예: Nagios, Zabbix, Prometheus)과 같은 도구를 사용하여 CPU, 메모리 및 디스크 공간을 정기적으로 모니터링합니다.
  • 로그 순환 자동화: 로그를 생성하는 모든 서비스에 대해 logrotate가 올바르게 구성되었는지 확인합니다.
  • 애플리케이션 구성 조정: 리소스 효율성을 높이기 위해 애플리케이션 설정을 최적화합니다. 예를 들어, 웹 서버 작업자 프로세스, 데이터베이스 연결 풀 등을 조정합니다.
  • 알림 설정: 지속적인 높은 사용량, 빠른 성장, OOM 종료, 파일 시스템 포화, inode 고갈 및 서비스 재시작에 대한 알림을 구성합니다. 하드 제한뿐만 아니라 추세에 대해서도 알림을 설정합니다.
  • 시스템 업데이트: 성능 개선 및 버그 수정이 새 버전에 포함되는 경우가 많으므로 시스템과 애플리케이션을 최신 상태로 유지합니다.
  • 리소스 제한: 다중 사용자 시스템 또는 컨테이너화된 환경의 경우, 단일 프로세스가 다른 프로세스를 굶주리지 않도록 리소스 제한(예: ulimit 또는 cgroups 사용)을 설정하는 것을 고려합니다.

리소스 고갈 문제 해결은 대부분 규율 있는 범위 축소입니다. 제한된 리소스를 찾고, 소유자를 식별하고, 가장 작은 안정화 변경을 수행한 다음, 발생한 이유를 수정하십시오. 기본 도구는 대부분의 인시던트에 충분합니다. 해당 순서로 사용하고 만지는 것을 이해하기 전에 삭제하거나 종료하려는 충동을 억제한다면 말입니다.