Home Assistant는 읽기와 쓰기 작업에서 왜 서로 다른 부하를 생성하나요?

에바 왕

IceWhale author

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

Why Does Home Assistant Generate Different Loads During Reads and Writes?

Home Assistant는 쿼리가 캐시된 페이지를 재사용하는 반면 상태 지속성은 저널, 인덱스 및 영구 스토리지를 수정하므로 서로 다른 읽기 및 쓰기 부하를 생성합니다.

히스토리 차트를 열면 저장된 여러 행을 변경 없이 스캔할 수 있지만, 노이즈가 많은 센서 하나는 하루 종일 소규모 트랜잭션을 생성할 수 있습니다. 첫 번째 패턴은 순차 읽기, 데이터베이스 캐시 및 쿼리 인덱스의 영향을 크게 받으며, 두 번째 패턴은 동기화, 저널 업데이트, 파일 시스템 메타데이터 및 플래시 쓰기 증폭을 추가합니다. 따라서 두 작업이 동일한 Recorder 데이터베이스를 사용하더라도 그래프는 서로 다르게 나타납니다.

실시간 상태 변경은 여러 쓰기를 생성합니다

Recorder는 선택한 상태 및 이벤트 변경을 데이터베이스 트랜잭션으로 변환합니다. 논리적 행 삽입 하나가 인덱스와 저널 또는 쓰기 선행 로그를 업데이트할 수도 있으며, 그 후 파일 시스템과 장치 캐시가 영구 저장 완료를 확인합니다.

데이터베이스 및 통계 설명 자료는 단기 상태 저장소와 장기 통계를 구분하여, Recorder 데이터 구조가 단순한 추가 전용 파일 하나가 아니라 서로 관련된 여러 구조를 건드릴 수 있는 이유를 설명합니다.

고빈도 엔티티는 여러 소규모 논리적 변경을 생성하며, 이러한 변경은 묶음으로 커밋될 수 있습니다. 이로 인해 주기적인 버스트처럼 보일 수 있으며, 데이터베이스와 스토리지 계층이 일관성을 유지하기 때문에 실제 기록되는 물리적 바이트 수는 페이로드보다 많을 수 있습니다.

히스토리 읽기는 범위, 선택도 및 캐시에 좌우됩니다

현재 상태 조회는 작지만, 여러 엔티티의 히스토리 차트는 넓은 시간 범위를 스캔하고 속성을 디코딩하며 결과를 집계한 뒤 클라이언트로 전송할 수 있습니다. 유용한 인덱스와 예열된 데이터베이스 페이지가 있으면 이러한 작업 대부분이 물리적 스토리지에 접근하지 않고 처리될 수 있습니다.

장기간 진행된 성능 사례에서는 일반적인 실시간 사용에도 불구하고 히스토리 접근이 매우 느렸습니다. 이는 히스토리 쿼리 워크로드가 현재 상태 제어에서는 실행되지 않는 쿼리 경로 문제를 드러낼 수 있음을 보여줍니다.

관련 페이지가 메모리에 남아 있으면 반복 읽기는 더 빨라지는 경우가 많습니다. 하지만 재시작, 메모리 부족 또는 다른 날짜 범위에서는 이러한 이점이 사라지므로, 예열된 쿼리 하나만으로 스토리지 용량을 신뢰성 있게 측정할 수는 없습니다.

로깅 및 주변 서비스가 늘어나면 쓰기 비용도 증가합니다

일반적인 홈 서버에서 유일한 기록 주체는 Home Assistant Core가 아닙니다. 디버그 로그, 애드온 데이터베이스, 백업, 카메라 스냅샷 및 컨테이너 로그가 같은 장치를 공유할 수 있으며, Recorder가 커밋을 시도하는 바로 그때 대기열을 유발할 수 있습니다.

플래시 마모를 줄인 실무자들은 로그와 관련 구성 요소가 쓰기 사이클을 추가한다는 점을 확인했습니다. 따라서 전체 볼륨의 쓰기 활동은 주 데이터베이스 프로세스뿐 아니라 전체 볼륨을 포함해야 합니다.

프로세스 수준의 원인 분석은 애플리케이션 동작과 공유 스토리지 경합을 구분합니다. Recorder가 조용한데 다른 컨테이너가 쓰기를 전담하고 있다면 엔티티 제외 설정을 변경해도 관찰된 부하는 해결되지 않습니다.

-15% OFF

ZimaBoard 2 - 당신의 큰 아이디어를 위한 미니 홈 서버

Single board computer zimaboard2

유지 관리가 일반적인 패턴을 뒤집을 수 있습니다

만료된 행을 삭제하거나 인덱스를 재구축하고, 진공 처리하거나, 다시 패키징하는 작업은 데이터베이스의 큰 부분을 읽고 다시 쓸 수 있습니다. 이 시간 동안 정리라고 설명되는 작업이 일반적인 상태 수집보다 더 많은 읽기와 쓰기를 동시에 발생시킬 수 있습니다.

Recorder 설정 관련 논의에서는 보존 기간 및 삭제 동작을 데이터베이스 유지 관리와 연결합니다. 따라서 보존 및 삭제 동작은 매일 같은 시간에 정기적인 부하 급증이 나타날 때 반드시 확인해야 합니다.

병목이 CPU 측 템플릿 평가, 클라이언트 렌더링 또는 네트워크 전송이라면 읽기와 쓰기의 차이만으로는 설명할 수 없습니다. 증상과 함께 스토리지 카운터도 증가해야 하며, 그렇지 않다면 데이터베이스는 단지 지연 현상 가까이에 있을 뿐입니다.

하나의 읽기 경로와 하나의 쓰기 경로를 비교하세요

고정된 히스토리 쿼리와 안전한 상태 변경 작업을 선택하세요. 각각에 대해 콜드 스타트와 반복된 웜 실행에서 요청 지연 시간, CPU, 데이터베이스 시간, 디스크 처리량, IOPS, 대기열 깊이 및 장치 지연 시간을 기록하세요.

관련 자료인 보존 데이터 증가는 메타데이터와 히스토리 증가가 워크로드를 변경하는 이유를 설명하며, 임의의 벤치마크 트래픽이 아닌 보존 데이터에 기반해 비교할 수 있도록 합니다.

공변성에 따라 한계를 분류하세요. 첫 읽기는 느리지만 반복 읽기는 빠르다면 캐시 지역성을 의미하고, 범위가 넓어질수록 쿼리 시간이 증가한다면 스캔 비용을 의미합니다. 쓰기 지연과 대기열 깊이의 증가는 영구 스토리지 경합을 의미하며, 어느 패턴도 나타나지 않는다면 다른 계층이 원인일 수 있습니다. 사용자에게 보이는 지연을 두 번 재현하는 경로만 최적화하세요.