업그레이드 전에 메모리 및 디스크 경고를 읽으세요.

맥락과 함께 작은 기준선 캡처하기

운영하는 애플리케이션을 점검할 수 있는 권한이 있는 Linux 계정을 사용하십시오. 여기의 명령은 상태를 점검하며 파일을 제거하거나 저장소 크기를 조정하지 않습니다. 일부 디렉터리와 저널에는 상승된 권한이 필요합니다. 다음을 실제 /var/lib/field-api, /opt/field-api 및 /opt/first-api 애플리케이션 경로로 바꾸고, 결과를 해석하기 전에 해당 경로가 존재하는지 확인하십시오.

시간, 현재 릴리스 및 활동을 기록하십시오: 일반 트래픽, 업로드, 보고서 작업 또는 배포 빌드. 비슷한 활동 중에 다시 측정하십시오. 서로 관련 없는 두 스크린샷은 정상 기계를 일관성 없어 보이게 할 수 있습니다. 사용자가 이미 영향을 받고 있다면, 여러 변경을 한꺼번에 하기 전에 애플리케이션 장애 가이드 에서 첫 번째 유용한 단서를 확보하십시오.

사용 가능한 메모리를 읽은 다음 워크로드 점검하기

free -h
ps -eo pid,comm,rss --sort=-rss | head -n 12

에서 free, 사용 가능한 메모리는 스와핑 없이 새 애플리케이션에 사용할 수 있는 양을 추정합니다. 회수 가능한 캐시를 고려하므로 완전히 사용되지 않은 '여유' 메모리와는 다른 질문에 답합니다. 다음을 참조하십시오: upstream free 매뉴얼. Linux은 파일 캐싱에 메모리를 사용하므로 캐시가 큰 것만으로는 누수 증거가 되지 않습니다. 커널 메모리 개요 에서는 캐시와 애플리케이션 메모리가 공존하는 이유를 설명합니다.

예시 판독값이며 서버 측정값이 아닙니다: 작은 호스트에 약 1.9 GiB의 사용 가능한 메모리, 80 MiB 여유, 850 MiB 사용 가능이 있습니다. 낮은 여유 수치만으로 업그레이드가 정당화되지는 않습니다. 보고서 중 사용 가능한 메모리가 반복적으로 0에 가까워지고, 요청이 느려지며, 관련 할당 또는 메모리 부족 메시지가 나타난다면 그 결합된 증거는 조사할 가치가 있습니다.

The ps 명령은 프로세스 RSS를 KiB 단위로, 가장 큰 것부터 나열합니다. RSS는 상주 메모리를 설명하며 배타적 소유권의 완전한 회계가 아닙니다. 공유 페이지는 여러 프로세스에 나타날 수 있습니다. 모든 RSS 수치를 더해 그 결과를 정확한 호스트 사용량으로 취급하지 마십시오. upstream ps 참조 에서는 RSS와 정렬을 정의합니다. 프로세스 이름과 워크로드 종료 후 해당 풋프린트가 이전 수준으로 돌아가는지 기록하십시오.

사용 중인 스왑은 이전 활동을 반영할 수 있으며, 그 자체로 현재 압력을 증명하지는 않습니다. 또한 호스트 용량과 서비스 또는 컨테이너 제한을 구분하십시오. 제한된 프로세스는 호스트에 아직 사용 가능한 메모리가 있어도 실패할 수 있습니다. VPS 크기를 늘리기 전에 구성된 제한과 실패 시각을 점검하십시오. 커널의 proc 파일 시스템 참조 에서는 이러한 관찰 뒤에 있는 메모리 필드를 문서화합니다.

실제로 채워지고 있는 파일 시스템 찾기

df -h / /opt/first-api
df -i / /opt/first-api

첫 번째 명령은 해당 경로가 포함된 파일 시스템의 공간을 보고합니다. 두 번째 명령은 파일과 디렉터리에 필요한 파일 시스템 레코드인 inode를 보고합니다. 작은 파일이 많은 워크로드는 바이트 용량이 남아 있어도 inode를 고갈시킬 수 있습니다. 전체 VPS 크기를 유일한 숫자로 사용하지 말고 마운트와 두 용량 종류를 모두 확인하십시오. 다음을 참조하십시오: GNU df 매뉴얼.

별도로 마운트된 볼륨의 경로는 루트 파일 시스템과 독립적으로 채워질 수 있습니다. 반대로 나열된 두 경로가 같은 파일 시스템에 속할 수 있으므로 사용 가능한 공간은 합산되지 않습니다. 파일 시스템 예약, 할당량 및 스토리지 계층도 앱이 쓸 수 있는 양에 영향을 줄 수 있습니다. 표시된 단일 백분율은 증가의 주인을 식별하지 않습니다.

증가 원인을 로그, 업로드 또는 아티팩트에 귀속시키기

sudo du -xhd1 /var/lib/field-api
sudo du -xhd1 /var/log
sudo du -xhd1 /opt/field-api
sudo journalctl --disk-usage

GNU du 에서는 각 디렉터리 아래 할당된 공간을 추정합니다. 여기서 -x 은 다른 파일 시스템으로 넘어가는 것을 피하고, -h 은 읽기 쉬운 단위를 사용하며, -d1 은 표시 깊이를 제한합니다. 큰 트리는 스캔에 시간과 디스크 활동이 여전히 걸릴 수 있습니다. 권한 오류는 보기가 불완전함을 의미합니다. 다음을 참조하십시오: GNU du 매뉴얼. journal 명령은 journalctl.

에서 문서화한 대로 활성 및 보관 파일을 포함한 저널 저장소를 보고합니다. 가장 큰 디렉터리를 해당 목적과 비교하십시오:

• 로그: 반복된 오류로 볼륨이 증가했으며, 로테이션이 구성되어 있습니까?
• 업로드: 보존된 사용자 파일이 예상대로 증가하고 있으며, 중단된 부분 업로드가 고려되고 있습니까?
• 릴리스 아티팩트: 롤백 정책을 넘어 오래된 빌드가 누적되고 있습니까?
• 데이터베이스 파일: 데이터베이스 자체 도구가 증가와 유지 관리 필요성을 설명합니까?

조사 단계로 익숙하지 않은 데이터베이스 디렉터리를 삭제하거나 광범위한 컨테이너 볼륨 정리를 하지 마십시오. 먼저 소유권, 보존 요구 사항 및 복구 가능한 사본을 확인하십시오. 만약 df 과 디렉터리 합계가 크게 불일치하면 숙련된 운영자와 함께 마운트 경계, 접근 오류 및 삭제 후에도 열려 있는 파일을 점검하십시오. 보이는 파일을 반복적으로 삭제하면 점유된 공간을 놓칠 수 있습니다.

측정값을 구체적인 다음 행동으로 전환하기

예시 사례: 사용 가능한 메모리는 여유가 있지만, 관찰된 이틀 각각에 업로드 디렉터리가 약 400 MiB씩 증가했습니다. 파일 시스템에는 약 2 GiB가 사용 가능합니다. 남은 공간을 이 단기 증가량으로 나누면 운영 여유를 두기 전에 같은 속도로 약 5일 정도만 가능함을 시사합니다. 이는 계획 추정치이며 예측이나 기다려야 할 안전한 기한이 아닙니다. 업로드와 임시 작업은 고르지 않게 도착할 수 있습니다.

다음 행동은 업로드 보존과 예상 수요를 확인하고, 정당화되면 추가 스토리지를 계획하며, 행동할 수 있을 만큼 일찍 알림을 설정하는 것입니다. RAM을 더 늘리는 것은 이 발견을 해결하지 못합니다. 다른 사례에서는 배포 빌드가 잠깐의 메모리 피크를 만들 수 있지만 서비스는 작게 유지될 수 있습니다. 빌드를 VPS 밖으로 옮기는 것이 런타임을 영구적으로 키우는 것보다 더 유용할 수 있습니다.

정당화된 변경 후에는 동일한 측정값과 하나의 애플리케이션 동작을 반복하십시오. 공간이 실제로 사용 가능하고 의도한 데이터가 여전히 작동하는지 확인하십시오. 삭제와 크기 조정은 빨간 숫자에 대한 자동 대응이 아니라 복구 단계가 있는 계획된 작업으로 유지하십시오. 다음을 사용하십시오: 리소스 예산 가이드 는 입증된 필요를 구성 선택으로 전환하고, 정리나 마이그레이션에 의존하기 전에 복원 을 연습하십시오.