Home Assistant에 설정해야 할 메모리 제한은 얼마인가요?

Home Assistant 메모리 제한에 단 하나의 정답은 없습니다. 직접 측정한 최대 사용량을 기준으로 경계를 설정하고, 호스트와 다른 컨테이너가 사용할 수 있는 RAM을 남겨 두며, OOM으로 프로세스가 종료되면 제한 또는 워크로드를 조사해야 한다는 신호로 받아들이세요.

공유 홈 서버에서는 유휴 상태의 측정값만으로는 충분하지 않습니다. Recorder 작업, 백업, 통합 구성 요소 다시 로드, 대시보드, 그리고 홈 전체에서 실행되는 바쁜 자동화 시퀀스는 서로 다른 최대 사용량을 만들 수 있습니다. 안전한 방법은 기준값을 기록하고, 확인된 워크로드 최대 사용량보다 높은 되돌릴 수 있는 제한을 선택한 다음, 호스트에 여유 공간이 남아 있는지 확인하고, 설정을 영구 적용하기 전에 원래의 바쁜 시간대를 다시 테스트하는 것입니다.

일반적인 RAM 수치가 아니라 최대 사용량부터 확인하세요

일반적인 며칠 동안 Home Assistant 컨테이너와 호스트를 동시에 측정하세요. 재시작, 백업, 사용하는 경우 데이터베이스 정리 또는 재패킹, 대시보드 활동, 안전하게 재현할 수 있는 가장 바쁜 자동화 시간을 포함하세요. 컨테이너 최대 사용량, 호스트의 사용 가능한 메모리, 스왑 활동, 응답 시간 변화 여부를 기록하세요.

메모리 제한은 성능 목표가 아니라 cgroup 경계입니다. 컨테이너가 하드 경계를 넘으면 커널이 프로세스를 종료할 수 있습니다. exit code 137과 OOM-killed 상태가 함께 나타나는 것이 유용한 신호입니다. 따라서 평균값이나 그대로 복사한 권장값보다 관찰된 최대 사용량이 더 중요합니다.

작업 중 메모리가 증가한 뒤 안정된다면, 반복 가능한 최대 사용량에 작업 여유 공간을 더해 설정하세요. 워크로드가 끝난 뒤에도 익명 메모리가 몇 시간 동안 계속 증가하고 줄어들지 않는다면, 크기 조정보다 메모리 누수가 있는 통합 구성 요소, 사용자 지정 구성 요소 또는 버전 회귀를 먼저 조사하세요. 상한을 높이면 문제를 해결하지 못한 채 충돌만 늦출 수 있습니다.

호스트와 함께 실행되는 모든 서비스에 메모리를 할당하세요

Home Assistant가 가장 바쁠 때에도 응답성을 유지해야 하는 서비스를 나열하세요. 운영 체제, Docker, 데이터베이스, MQTT, DNS, 대시보드, 미디어 서비스, 백업 작업 등이 여기에 포함됩니다. 제한은 Home Assistant뿐 아니라 이러한 서비스도 보호해야 합니다. 설치된 RAM을 한 컨테이너에 거의 모두 할당하면 장애가 호스트로 옮겨갈 뿐입니다.

같은 시간대의 호스트 사용 가능 메모리와 Home Assistant의 최대 사용량을 비교하세요. 회수 가능한 캐시는 애플리케이션 메모리와 같지 않으며, 스왑 활동은 기기가 제어에 느리게 반응하는 동안에도 시스템이 작동하는 것처럼 보이게 할 수 있습니다. Home Assistant가 최대 사용량에 도달하기 전에 호스트의 여유 공간이 사라진다면, Home Assistant의 상한을 조정하기 전에 겹치는 작업을 줄이거나 서비스를 다른 곳으로 옮기세요.

이는 단순한 Docker 설정이 아니라 용량에 관한 결정입니다. 웜 캐시를 넘어 Home Assistant 측정하기에 관한 관련 ZimaSpace 가이드는 반복 가능한 콜드 및 바쁜 워크로드가 편리한 유휴 상태 스냅샷보다 신뢰할 수 있는 기준값을 제공하는 이유를 설명합니다.

되돌릴 수 있는 제한을 적용하고 실제로 적용되었는지 확인하세요

Compose 파일이나 오케스트레이션 UI처럼 실제로 컨테이너를 다시 생성하는 구성에 메모리 설정을 추가하세요. 다음 배포에서 설정이 사라질 수 있는 일회성 실행 중 업데이트에 의존하지 마세요. 즉시 복원할 수 있도록 이전 구성을 저장하세요.

다시 생성한 후 실행 중인 컨테이너를 검사하고 구성된 제한이 표시되는지 확인하세요. 그런 다음 컨테이너 사용량, 호스트 사용 가능 메모리, 스왑, 재시작 횟수, 지연 시간을 관찰하세요. 호스트 cgroup에 의해 적용되지 않는 표시 설정은 특히 중첩 가상화 환경에서 잘못된 확신을 줍니다.

컨테이너가 재시작되더라도 자동으로 제한을 높이지 마세요. 런타임에서 OOMKilled와 exit 137을 보고하는지 확인하세요. 그렇지 않다면 다른 종료 경로를 조사하세요. 그렇다면 타임스탬프를 워크로드와 비교하세요. 반복적으로 발생하는 짧은 최대 사용량은 작업 여유 공간이 부족하다는 뜻일 수 있고, 꾸준한 증가는 메모리 누수 또는 폭주하는 통합 구성 요소를 의미할 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

$799.00 - $2,499.00

Buy Now

원래의 바쁜 Home Assistant 워크로드에서 다시 테스트하세요

기준값을 측정할 때 사용한 시나리오를 그대로 반복하세요. 동일한 통합 구성 요소를 다시 로드하고, 동일한 대시보드를 열고, 동일한 홈 전체 제어 시퀀스를 실행하며, 동일한 백업 또는 Recorder 활동도 포함하세요. 워크로드를 바꾸면 더 가벼운 시스템에 맞는다는 것만 입증하게 됩니다.

통과한 결과란 컨테이너가 OOM 이벤트 없이 경계 아래에 머물고, 호스트에 사용 가능한 메모리가 남으며, 스왑으로 인해 제어 지연이 발생하지 않고, 자동화가 평소 속도로 완료되는 것을 의미합니다. 두 번 재시작하고 다음 예약 백그라운드 작업 후에도 다시 확인하여 결과가 컨테이너 재생성과 시간 기반 작업을 견디는지 확인하세요.

기기 제어가 불안정해지거나, 컨테이너가 재시작 루프에 빠지거나, 호스트 메모리 압박이 계속 심하다면 새 제한을 롤백하세요. 트리거가 된 워크로드가 끝난 뒤에도 메모리가 계속 증가한다면 통합 구성 요소를 분리하거나 버전을 비교하는 단계로 넘어가세요. 이 시점에서는 제한 조정이 더 이상 주요 해결책이 아닙니다.

자주 묻는 질문

Home Assistant에는 항상 하드 메모리 제한이 있어야 하나요? 공유 Docker 호스트에서는 테스트된 경계가 다른 서비스를 보호할 수 있습니다. 전용 HAOS 시스템이나 VM은 용량을 다르게 설정하므로, 전체 게스트를 측정하지 않고 컨테이너 제한을 VM 할당량에 그대로 적용하지 마세요.

사용 중인 메모리가 높으면 자동으로 메모리 누수인가요? 아닙니다. 캐시와 짧은 워크로드 최대 사용량은 정상일 수 있습니다. 익명 메모리가 계속 증가하는지, OOM 이벤트나 재시작 루프가 발생하는지, 워크로드가 끝난 뒤 지연 시간이 악화되는지를 확인하세요.

스왑을 비활성화해야 하나요? 첫 단계로는 권장하지 않습니다. 먼저 스왑이 호스트 메모리 압박을 숨기고 있는지 또는 갑작스러운 장애를 방지하고 있는지 파악한 다음, 테스트된 롤백 경로와 전체 워크로드를 감당할 충분한 물리 RAM이 있을 때만 변경하세요.