무료 -h 서버와 열에서 무료 화면에는 거의 0이 표시됩니다. 하지만 애플리케이션은 여전히 정상적으로 작동하고 메모리 오류도 발생하지 않습니다. 이러한 현상은 흔히 볼 수 있습니다. 리눅스는 사용되지 않는 RAM을 캐시로 사용한 다음, 프로세스가 필요로 할 때 일부를 회수합니다.
기기에 실제로 메모리가 부족한지 확인하려면 먼저 다음을 살펴보세요. 사용 가능그런 다음 시간에 따른 스왑 및 메모리 활동을 보여줍니다. 단일 값 사용된 그것만으로는 충분하지 않습니다. 서비스를 중지하거나 RAM을 추가하기 전에 제가 사용하는 방법은 다음과 같습니다.
`free -h` 명령어를 실행하고 `available` 열을 확인하세요.
무료 -h -시간 자동으로 읽기 쉬운 단위(예: MiB 또는 GiB)를 선택합니다. 기억다음 세 열부터 시작하세요.
총커널의 알려진 사용 가능한 메모리;사용 가능: 새 프로세스가 스왑을 발생시키지 않고 확보할 수 있는 메모리 양에 대한 추정치;무료현재 전혀 사용되지 않는 페이지들입니다.
사용 가능 무료커널은 캐시와 복구 가능한 구조의 일부를 해제하는 방법을 알고 있습니다. 300MiB의 캐시를 가진 시스템은 다음과 같습니다. 무료 하지만 4GiB에는 사용 가능 RAM이 부족한 것이 아닙니다.
사용량, 공유량, 버프/캐시 값을 합산하지 않고 읽습니다.
열 무료 이는 서로 연결해야 하는 독립적인 서랍에 해당하지 않습니다. procps-ng의 최신 버전에서는, 에서 계산됩니다 총 그리고 사용 가능따라서 이는 모든 프로세스의 RSS 메모리 합계와 정확히 일치하는 것은 아닙니다.
공유됨tmpfs;코어 버퍼를 포함합니다.숨겨진특히 파일 캐시 및 복구 가능한 구조를 포함합니다.버프/캐시버퍼와 캐시를 표준 디스플레이에 그룹화합니다.
분리하다 버퍼 그리고 숨겨진와이드스크린 디스플레이를 사용하세요:
이러한 관점은 할당 방식을 이해하는 데 도움이 되지만 진단을 바꾸지는 않습니다. 여전히 문제는 스왑 없이 얼마나 많은 메모리를 복구할 수 있는지, 그리고 그 여유분이 영구적으로 감소하는지 여부입니다.
리눅스가 RAM을 캐시로 채우는 이유는 무엇일까요?
RAM에서 파일을 다시 읽는 것이 SSD나 하드 드라이브에서 다시 읽는 것보다 비용이 적게 듭니다. 따라서 Linux는 최근 사용한 데이터를 페이지 캐시에 저장합니다. 어떤 애플리케이션도 이 공간을 요청하지 않는 한, 캐시를 비워두는 것은 아무런 이점이 없습니다.
캐시를 삭제하지 마세요 drop_caches 척추를 인위적으로 높이다 무료유용한 캐시를 삭제하고 시스템이 데이터를 다시 읽도록 강제하고 있습니다. 이 작업은 주로 제어된 테스트에 사용되며, 일상적인 서버 유지 관리에는 적합하지 않습니다.
값의 출처는 다음에서 확인할 수 있습니다. /proc/meminfo :
grep -E '^(MemTotal|MemFree|MemAvailable|Buffers|Cached|SReclaimable|SwapTotal|SwapFree):' /proc/meminfoMemAveable
-중 메비바이트 단위로 표시됩니다. 소수 단위의 경우, 다음을 더하세요. --만약에 :
무료 -m
무료 -h --si또한 단 한 번의 포착만으로 결론을 내리는 것을 피하십시오. 무료 2초마다 측정을 반복하고 5회 측정 후 중지할 수 있습니다.
자유 -h -s 2 -c 5확인해보세요 사용 가능 스왑 작업이 진행된 후 프로세스가 완료되어 상황이 정상으로 돌아오면 지속적인 드롭 현상이 발생합니다. 백업이나 컴파일 중에 발생하는 짧은 드롭 현상은 몇 시간 동안 지속되는 드롭 현상과는 다릅니다.
RAM과 스왑 및 vmstat의 상호 참조
라인 교환 ~의 무료 이는 해당 영역의 점유 상태를 나타낼 뿐, 활동 상태를 나타내는 것은 아닙니다. 수 기가바이트의 장기간 사용된 데이터가 있다고 해서 해당 컴퓨터가 여전히 페이지를 주고받고 있다는 것을 증명하는 것은 아닙니다. 활성 영역 목록을 작성한 다음 관찰하십시오. 만약에 그리고 ~와 함께 vmstat :
스왑온 --쇼
vmstat 1 5~ 안에 vmstat순간 활동을 나타내는 첫 번째 줄은 무시하세요. 이는 시작 시점 이후의 평균값을 나타냅니다. 다음 줄들은 표본 값을 보여줍니다. 반복되는 값은 다음과 같습니다. 만약에 또는 그래서와 연관된 사용 가능 메모리 사용량이 낮거나 속도가 느려지는 것은 실제 메모리 부족 현상을 나타냅니다.
가이드 Linux에서 스왑 이 파일은 언제 정상적으로 사용되는지, 그리고 RAM 없이 이 파일을 삭제하면 왜 컴퓨터가 멈출 수 있는지 설명합니다.
실제로 메모리를 많이 사용하는 프로세스를 찾으세요.
지표들이 긴장 상태를 확인시켜 준다면, 조치를 취하기 전에 관련 과정을 파악하십시오.
ps -eo pid,user,comm,%mem,rss --sort=-rss | 헤드
htopRSS 이 값은 프로세스의 상주 물리적 메모리를 측정하지만, 일부 페이지는 여러 프로세스에서 공유될 수 있습니다. 따라서 모든 RSS 값을 합산하면 실제 사용량을 과대평가할 수 있습니다. 이 목록을 사용하여 문제의 원인을 파악한 다음, 해당 서비스, 구성 및 로그를 확인하십시오.
~ 안에 htop
systemctl status service-concerned --no-pager
Journalctl -u service-concerne -n 100 --no-pagerRAM이 실제로 부족하다고 판단하는 시점은 언제일까요?
사용 가능 매우 낮은 상태로 남아 있으며, vmstat 반복적인 데이터 교환이 발생하고 응답 시간이 저하되며 결국 커널이 OOM 킬러를 호출합니다.
journalctl -k -b | grep -Ei 'out of memory|oom-killer|killed process'
dmesg -T | grep -Ei '메모리 부족|oom-killer|프로세스 종료됨'이 경우, 메모리 제한 설정 오류, 서비스 누수, 과도한 부하 또는 부족한 메모리 크기 등 원인을 수정하십시오. 스왑 공간은 안전망으로만 추가해야 하며, 항상 포화 상태인 RAM을 대체해서는 안 됩니다. 무료 매뉴얼 페이지 해당 문서에는 각 열의 계산 내용이 기록되어 있습니다. proc_meminfo(5) 커널에서 제공하는 카운터에 대해 설명합니다.