반복 가능한 워크로드에서 Home Assistant의 리소스 여유를 벤치마크하는 방법

에바 왕

IceWhale author

에바 왕 는 기술 작가 그리고 이자 ZimaSpace의 상주 장인입니다. 평생을 기술에 열정을 가진 사람으로서 홈랩과 오픈소스 소프트웨어에 열정을 가지고 있으며,복잡한 기술 개념을 쉽게 이해할 수 있는 실습 가이드로 번역하는 데 전문성을 가지고 있습니다.에바는 셀프 호스팅이 어렵지 않고 재미있어야 한다고 믿습니다. 그녀의 튜토리얼을 통해 커뮤니티가 하드웨어 설정의 신비를 풀도록돕고 있습니다. 첫 NAS 구축부터 Docker 컨테이너 마스터링까지.

How to Benchmark Home Assistant Resource Headroom Under a Repeatable Workload - Zima Store Online

Home Assistant 성능 벤치마크는 동일한 워크로드를 재현하고 리소스 그래프를 보기 전에 ‘충분히 빠른’ 상태의 기준을 정의할 때만 유용합니다. 그렇지 않으면 CPU, 메모리, 스토리지, 네트워크 수치는 용량에 대한 결론이 없는 단순한 관찰에 그칩니다.

이는 느린 설치 하나를 문제 해결하는 것과는 다릅니다. 벤치마크는 반복 가능한 기준선을 의도적으로 만들고, 하나의 워크로드 차원을 증가시키며, 선택한 자동화, 히스토리 쿼리 또는 대시보드 응답이 허용 가능한 지연 시간 범위를 벗어나기 전에 얼마나 많은 리소스 여유가 남아 있는지 파악합니다.

하나의 워크로드와 하나의 허용 기준을 정의하세요

실제 가정의 사용량이 가장 높은 순간을 나타내는 워크로드를 선택하세요. 예를 들어 로컬 모션 자동화, 활성 대시보드 3개, 일반적인 Recorder 쓰기, 백업이 없는 백그라운드 작업 기간 1회, 고정된 통합 세트를 포함할 수 있습니다. Home Assistant 버전, 호스트 하드웨어, 스토리지, 데이터베이스, 클라이언트, 네트워크 경로, 테스트 시간을 기록하세요.

Home Assistant의 시스템 정보 보기에는 설치, 네트워크, 통합, 리소스 관련 정보가 표시되므로 성능 결과와 함께 기록해야 합니다. 환경 세부 정보가 없으면 한 사람의 응답 시간을 다른 시스템과 의미 있게 비교할 수 없습니다.

그런 다음 허용 기준을 정의하세요. 조명 자동화는 물리적 응답 시간이 1초 미만이어야 할 수 있지만, 5년치 히스토리 쿼리는 수 초가 걸려도 허용될 수 있습니다. 이를 하나의 일반적인 ‘Home Assistant 속도’ 점수로 합치지 마세요.

모든 공유 리소스에서 사용률, 포화도, 오류를 확인하세요

평균 사용률만으로 중단 조건을 정하는 것은 적절하지 않습니다. 디스크는 사용량이 높아도 정상일 수 있고, CPU는 평균 사용률이 낮더라도 짧은 급증으로 인해 사용자가 지연으로 체감하는 대기열이 생길 수 있습니다.

USE 방법론은 각 물리적 리소스 또는 제약된 리소스의 사용률, 포화도, 오류를 평가합니다. 가장 높은 사용률 그래프 하나를 고르는 대신 CPU, 메모리 용량, 스토리지 I/O, 네트워크 인터페이스에 이 기준을 적용하세요.

컨테이너화된 Home Assistant에서는 cgroup 제한도 리소스로 포함하세요. 호스트에 CPU 여유가 60% 남아 있어도 컨테이너가 할당된 쿼터에 도달하면 스로틀링될 수 있습니다.

압력 지표는 리소스 부족으로 손실되는 시간을 보여 줍니다

Linux Pressure Stall Information은 지연 시간 중심의 관점을 추가합니다. CPU, 메모리 또는 I/O가 얼마나 사용되는지만 묻는 대신 PSI는 리소스 경쟁으로 인해 작업이 대기하는 시간의 비율을 측정합니다.

Linux 커널 문서에 따르면 CPU, 메모리, I/O 압력은 경쟁으로 인해 실제로 손실된 시간으로 측정할 수 있으며, 평균 사용률이 극단적으로 높아 보이기 전에도 짧은 급증이 지연 시간을 악화시키는 상황을 포함합니다.

따라서 PSI는 공유 홈 서버에서 유용합니다. 다른 컨테이너의 쓰기 급증 중 I/O 압력이 높아질 때 Home Assistant 지연 시간이 악화된다면, ‘SSD 사용률이 70%였다’는 설명보다 공유 스토리지 경쟁에 대한 더 강력한 근거를 얻을 수 있습니다.

Featured

ZimaCube 2 개인용 클라우드 홈 NAS

ZimaCube2

실행마다 하나의 워크로드 차원만 증가시키세요

대시보드 사용자, 자동화 트리거, 카메라 스트림, 보존 기간, 백업 트래픽을 동시에 추가하지 마세요. 다른 모든 조건을 고정한 채 변수 하나만 증가시키세요.

유용한 단계별 테스트로는 분당 자동화 이벤트 수 증가, 동시 대시보드 수 증가, 더 넓은 히스토리 범위, 더 많은 엔티티 업데이트, 또는 정의된 인접 서비스 부하 1개가 있습니다. 각 단계 후에는 충분히 기다려 시스템이 안정적인 동작에 도달하도록 하세요. 캐시가 예열되는 처음 10초나 시작 시 급증하는 구간만 수집해서는 안 됩니다.

ZimaSpace의 공유 스토리지 대기열 경쟁과 테일 지연 시간 분석은 워크로드를 리소스 경로에 매핑해야 하는 이유를 보여 줍니다. 테스트한 작업이 스토리지에 직접 의존하거나 동일한 I/O 대기열을 공유할 때만 스토리지가 중요하기 때문입니다.

하나의 리소스를 변경하고 결과가 달라지는지 확인하세요

제어된 리소스 변경으로 지연 시간 곡선이 이동할 때 벤치마크는 진단 도구가 됩니다. 무거운 인접 작업을 Home Assistant CPU에서 다른 곳으로 고정하거나, 쓰기 작업이 많은 작업을 일시 중지하거나, 테스트 대상 cgroup의 메모리 제한을 높이거나, 직접 LAN 경로를 사용하거나, 앱 데이터를 지연 시간이 더 낮은 스토리지로 옮겨 보세요.

동일한 워크로드 단계에서 원래의 지연 시간 기준이 개선된다면 해당 리소스가 여유 용량을 제한하고 있었을 가능성이 있습니다. 아무것도 달라지지 않는다면 실험을 되돌리고 변경 사항을 영구 설정으로 만들지 말고 다음 후보를 테스트하세요.

결과를 용량 범위로 게시하세요

워크로드 차원	측정 방법	중단 조건
자동화/이벤트 발생률	트리거부터 작업 실행까지의 테일 지연 시간	지연 시간 또는 대기열이 지속적으로 증가함
대시보드 클라이언트	서버 응답 + 클라이언트 렌더링	반복적인 상호작용 지연이 목표를 초과함
Recorder/히스토리 부하	쿼리 지연 시간 + 스토리지 압력	I/O 압력 또는 쿼리 테일 지연 시간이 급격히 증가함
공유 호스트 부하	PSI / cgroup / 사용률	경쟁 상황에 따라 Home Assistant 지연 시간이 변함
네트워크 경로	RTT, 손실률, DNS, 응답 시간	원격 경로가 정의한 목표를 충족하지 못함

최종 결과는 ‘이 하드웨어, 데이터베이스, 클라이언트 구성, 백그라운드 워크로드에서 선택한 제어 경로가 N단계까지 목표 범위 안에 유지된다’와 같이 작성해야 합니다. 이는 재현 가능한 진술입니다. ‘Home Assistant는 CPU를 20%만 사용한다’는 그렇지 않습니다.