이 섹션에서는 hardware 구성 요소에 대한 포괄적인 개요와 하드웨어 구성 요소가 mongot 프로세스 에 미치는 영향에 대해 설명합니다. 크기 조정 가이드라인, 필수 모니터링 권장 사항 및 실용적인 확장 조언 제공합니다.
중앙처리장치
영향
CPU 수와 품질을 늘리면 일반적으로 복제 처리량 및 쿼리 처리량 (QPS)에 긍정적인 영향 미칩니다. CPU는 특히 동시 세그먼트 검색 사용하는 쿼리에 활용됩니다.
크기 조정 가이드라인
쿼리 처리량 기반으로 한 유용한 추정치는 CPU 코어당 10 QPS입니다. 실제 QPS는 쿼리 복잡성과 인덱스 매핑의 영향을 받기 때문에 이는 기준입니다.
모니터링
CPU 사용량이 지속적으로 80%를 초과하면 확장하다 (CPU 코어 추가)이 필요하다는 것을 의미하고, 20% 미만으로 지속적으로 낮다면 확장하다 (CPU 코어 감소)이 필요하다는 의미일 수 있습니다.
확장
수평 확장 (더 많은 mongot 노드 추가)은 총 CPU를 늘려 QPS를 높입니다.
참고
수평 확장 각 mongot 가 소스 컬렉션 에서 인덱스 데이터를 복제해야 하므로 복제본 세트 에 추가 로드를 추가합니다. 각 검색 또는 벡터 검색 인덱스 mongot 별로 새로운 변경 스트림 생성하므로 복제본 세트 크기가 추가 복제 로드를 처리하다 할 수 없는 경우 성능이 저하될 수 있습니다.
수직 확장 더 많은 쿼리를 병렬로 제공 하고 쿼리 요청 대기열을 줄임으로써 쿼리 지연 시간 에 주로 영향을 미칩니다.
메모리(RAM)
영향
mongot JVM 힙(루센 관련 데이터 구조 및 캐시용)과 파일 시스템 캐시 (인덱싱된 데이터에 효율적으로 액세스하기 위해)에 시스템 메모리를 사용합니다.
크기 조정 가이드라인
함께 배치된 아키텍처의 경우 기본값 설정이 적절한 균형을 제공합니다. 그러나 전용 인프라의 경우 기본값 JVM 힙 크기를 조정하는 것이 유용할 수 있습니다. 다음 섹션에서는 특정 hardware 및 워크로드 에 맞게 이 설정을 최적화하는 방법에 대한 지침 제공합니다.
JVM 힙 크기 조정
mongot 는 주로 루센 관련 데이터 구조 및 캐시에 JVM 힙을 사용합니다. 일반적으로 mongot 의 힙 사용량은 인덱싱된 필드 수에 따라 대략적으로 조정됩니다. 힙 사용량은 문서 수나 벡터 수에 크게 영향을 받지 않습니다. 전체 텍스트 검색 및 벡터 검색 위한 효과적인 데이터 모델링은 일반적으로 인덱싱된 필드 수를 최소화합니다.
최대 약 30GB 초과하지 않는 범위에서 사용 가능한 총 시스템 메모리의 50%를 추정치로 할당합니다. 이렇게 하면 디스크에서 자주 액세스하는 인덱스 세그먼트를 캐싱하여 Lucene의 성능에 중요한 역할 하는 OS 파일 시스템 캐시 에 충분한 메모리를 사용할 수 있습니다. 기본값 으로 mongot 는 JVM 힙에 사용 가능한 총 시스템 메모리의 최대 25%, 최대 32GB (128GB 의 시스템 메모리 포함)를 할당합니다. 이 크기 조정 가이드라인은 이 기본값 에서 상향된 것입니다.
또한 힙 크기를 약 30GB 미만으로 유지하면 JVM 압축된 객체 포인터를 사용하여 메모리를 절약할 수 있습니다. 힙 크기를 이 30GB 제한 이상으로 늘리는 경우 힙 크기를 직접 48GB 이상으로 늘리는 것이 좋습니다.
기본값 힙 크기 설정을 재정의하려면 mongot 시작 스크립트 에 필요한 크기를 인수로 지정합니다. 최소 힙 크기(Xms)와 최대 힙 크기(Xmx)를 동일한 값으로 설정하다 것이 좋습니다. 예시 를 들면 다음과 같습니다.
/etc/mongot/mongot --config /etc/mongot/mongot.conf --jvm-flags "-Xms4g -Xmx4g"
파일 시스템 캐시
인덱스 세그먼트는 메모리 매핑된 파일을 통해 액세스되므로 쿼리 지연 시간 과 처리량 OS의 파일 시스템 캐시 에 따라 크게 달라집니다. 파일 시스템 캐시 워크로드 위해 충분한 메모리를 확보해야 합니다. mongot 에 격리된 hardware 사용하면 캐시 경합을 줄일 수 있습니다.
참고
JVM 힙 크기를 사용 가능한 메모리의 50% 이상으로 늘리면 파일 시스템 캐시 사용에 필요한 메모리가 부족할 수 있습니다.
벡터 검색 가이드
벡터 검색 의 경우 '검색 프로세스 메모리'는 HNSW 그래프 와 같은 데이터 구조를 효율적으로 저장 데 사용됩니다. 벡터 인덱스 크기가 3GB 초과하는 경우 벡터 양자화를 사용합니다. 벡터를 양자화할 때 전체 인덱스 가 아닌 인덱스 의 4%만 메모리에 저장하면 됩니다.
메모리 부족 모니터링
검색 페이지 오류 및 디스크 IOPS 가 증가하면 운영 체제가 디스크에서 필요한 페이지를 자주 검색하고 있으며, 이는 메모리가 부족함을 나타냅니다. 1000/s에 걸쳐 페이지 오류가 지속적으로 표시되면 확장 을 고려해야 합니다.
확장
mongot 프로세스 OutOfMemoryError 로 종료되면 JVM 힙이 인덱싱 및 쿼리 워크로드 에 비해 너무 작다는 의미입니다. 이는 소스 필드를 너무 많이 저장하거나 구조화되지 않은 데이터의 동적 매핑으로 인한 '매핑 폭발'로 인해 발생하는 경우가 많습니다. 이 문제를 해결하기 위한 프라이머리 권장 사항은 다음과 같습니다.
Java 힙 크기 늘리기(수직적 확장)
가장 직접적인 해결책은 mongot 프로세스 에 더 많은 RAM 할당하는 것입니다. 호스팅하다 사용 가능한 메모리가 있는 경우 최대 Java 힙 크기를 늘릴 수 있습니다. 이렇게 하면 인덱스 정의를 변경하지 않고도 기존 인덱스 및 쿼리 패턴에 더 많은 여유 공간을 확보할 수 있습니다.
인덱스 메모리 사용량 줄이기
hardware 확장 이 옵션이 아니거나 효율성 위해 최적화하려는 경우 인덱스 에 필요한 메모리 양을 줄일 수 있습니다.
인덱스 정의를 검토하고 storedSource 필드를 줄이고 인덱스 에서 필수가 아닌 모든 필드를 제거 힙 압력을 줄입니다.
정적 매핑을 사용합니다. 동적 매핑은 컬렉션 문서의 모든 고유 필드 에 대한 인덱스 필드 생성합니다. 보다 선택적이고 필수 필드만 인덱싱 하면 힙 소비가 줄어듭니다.
디스크 처리량 및 스토리지
영향
읽기 및 쓰기 (write) IOPS는 모두 mongot 성능에 중요하며 복제, 초기 동기화 및 쿼리 처리량 영향을 미칩니다. 대부분의 사용 사례에서는 범용 SSD를 사용하는 것이 좋습니다.
일반적으로 읽기 및 쓰기 (write) IOPS는 모두 mongot 성능에 중요합니다. 데이터 복제에는 디스크에 쓰기뿐만 아니라 이전 인덱스 세그먼트가 더 큰 세그먼트로 병합되므로 읽기도 포함됩니다. 따라서 디스크 처리량 쿼리 처리량 부터 초기 동기화 인덱싱 처리량 에 이르기까지 mongot 성능의 모든 측면에 다양한 영향을 미칩니다.
크기 조정 가이드라인
디스크 크기 조정 가이드라인을 참조하세요.
인덱스 재구축
Atlas Search 인덱스 만들거나 다시 작성하는 작업은 리소스를 많이 사용하며 클러스터 성능에 영향 수 있습니다. 다운타임 없는 인덱싱 의 경우 이전 인덱스 에서 사용한 디스크 공간의 125%에 해당하는 디스크 여유 공간을 할당합니다. 이 여유 공간은 재구축 중에 이전 인덱스 디스크에 유지되므로 중요합니다. 일반적으로 인덱스 재구축을 수용하려면 mongot 에 대한 디스크 허용량을 두 배로 늘리는 것이 좋습니다.
모니터링
현재 인덱스 소비를 추적 하려면 Search Disk Space Used을 모니터 . 1K를 초과하는 지속적인 IOPS 사용량에 대해서는 조사가 필요합니다.
참고
mongot 호스트의 저장 사용률이 90%에 도달하면 mongot 는 읽기 전용 상태 됩니다. 이 상태 에 있는 동안 mongot 는 현재 상태 의 인덱스를 사용하여 쿼리를 계속 제공 . 완화하지 않고 소스 컬렉션 변경하면 검색 결과가 오래될 수 있습니다.
소스 컬렉션과의 인덱스 동기화를 다시 시작하려면 인덱스 데이터를 삭제하거나 저장 용량 늘려 저장 사용률을 85% 미만으로 줄이세요.
확장
특히 이진 양자화를 사용하여 인덱스 크기를 늘리고 인덱스 데이터의 볼륨이 큰 경우에는 인스턴스에 더 큰 인덱스 데이터 작업 세트를 지원 수 있는 충분한 메모리가 있어야 합니다. 그러나 필요한 정확한 메모리 양은 워크로드 에 따라 다릅니다.
예시 를 들어, 전체가 거의 쿼리되지 않는 대규모 데이터 세트는 전체가 자주 쿼리되는 동일한 크기의 데이터 세트보다 적은 메모리로 짧은 지연 시간 으로 쿼리를 처리할 수 있습니다.
스토리지 대 메모리 비율이 높은 mongot 를 사용하는 경우 메모리 사용량을 주의 깊게 모니터 . 예시 를 들어, 64GB 의 메모리는 6400GB 의 저장 에 충분하지 않을 수 있습니다.