FAQ: 자체 관리형 MongoDB 진단

TCP 킵얼라이브 값 조정:

시스템 전체에 새 킵얼라이브 설정을 적용하려면 mongod 및 mongos 프로세스를 다시 시작해야 합니다.

TCP 재전송 시간 초과 조정

작업 세트 크기가 RAM에 꼭 맞아야 하나요?

No.

캐시에 추가 데이터를 로드할 공간이 충분하지 않은 경우 WiredTiger는 캐시에서 페이지를 제거하여 공간을 확보합니다.

기본 WiredTiger 내부 캐시 크기 값은 머신당 단일 mongod 인스턴스가 있다고 가정합니다. 단일 머신에 여러 MongoDB 인스턴스가 포함된 경우 다른 mongod 인스턴스를 수용할 수 있도록 설정을 줄여야 합니다.

시스템에서 사용 가능한 모든 RAM에 액세스할 수 없는 컨테이너에서 mongod를 실행하는 경우(예를 들어, lxc, cgroups, Docker 등) storage.wiredTiger.engineConfig.cacheSizeGB를 반드시 컨테이너에서 사용 가능한 RAM의 양보다 적은 값으로 설정해야 합니다. 정확한 양은 컨테이너에서 실행 중인 다른 프로세스에 따라 달라집니다. memLimitMB를 참조하세요.

캐시 및 제거에 대한 통계를 보려면 serverStatus 명령을 사용합니다. wiredTiger.cache 필드에는 캐시 및 제거에 대한 정보가 들어 있습니다.

...
"wiredTiger" : {
   ...
   "cache" : {
      "tracked dirty bytes in the cache" : <num>,
      "bytes currently in the cache" : <num>,
      "maximum bytes configured" : <num>,
      "bytes read into cache" :<num>,
      "bytes written from cache" : <num>,
      "pages evicted by application threads" : <num>,
      "checkpoint blocked page eviction" : <num>,
      "unmodified pages evicted" : <num>,
      "page split during eviction deepened the tree" : <num>,
      "modified pages evicted" : <num>,
      "pages selected for eviction unable to be evicted" : <num>,
      "pages evicted because they exceeded the in-memory maximum" : <num>,,
      "pages evicted because they had chains of deleted items" : <num>,
      "failed eviction of pages that exceeded the in-memory maximum" : <num>,
      "hazard pointer blocked page eviction" : <num>,
      "internal pages evicted" : <num>,
      "maximum page size at eviction" : <num>,
      "eviction server candidate queue empty when topping up" : <num>,
      "eviction server candidate queue not empty when topping up" : <num>,
      "eviction server evicting pages" : <num>,
      "eviction server populating queue, but not evicting pages" : <num>,
      "eviction server unable to reach eviction goal" : <num>,
      "pages split during eviction" : <num>,
      "pages walked for eviction" : <num>,
      "eviction worker thread evicting pages" : <num>,
      "in-memory page splits" : <num>,
      "percentage overhead" : <num>,
      "tracked dirty pages in the cache" : <num>,
      "pages currently held in the cache" : <num>,
      "pages read into cache" : <num>,
      "pages written from cache" : <num>,
   },
   ...

wiredTiger.cache.bytes currently in the cache 및 wiredTiger.cache.tracked dirty bytes in the cache 등의 일부 키 캐시 및 제거 통계에 대한 설명은 wiredTiger.cache를 참조하세요.

와이어드타이거 내부 캐시 크기를 조정하려면 storage.wiredTiger.engineConfig.cacheSizeGB 및 --wiredTigerCacheSizeGB를 참조하세요. WiredTiger 내부 캐시 크기를 기본값 이상으로 늘리지 마세요.

애플리케이션에 필요한 RAM 용량은 어떻게 계산하나요?

MongoDB는 WiredTiger를 통해 내부 캐시와 파일 시스템 캐시 모두를 활용합니다.

기본 WiredTiger 내부 캐시 크기는 다음 중 더 큰 값입니다.

• (RAM - 1GB)의 50%

• 256 MB.

예를 들어 총 4 GB RAM이 있는 시스템에서 WiredTiger 캐시는 1.5 GB RAM(0.5 * (4 GB - 1 GB) = 1.5 GB)을 사용합니다. 반대로, 총 RAM이 1.25 GB인 시스템에서는 WiredTiger는 WiredTiger 캐시에 256 MB를 할당하는데, 이는 전체 RAM에서 1 GB(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB)를 뺀 값의 절반 이상이기 때문입니다.

기본적으로 WiredTiger는 모든 컬렉션에 Snappy 블록 압축을 사용하고 모든 인덱스에 접두사 압축을 사용합니다. 압축 기본값은 전역 수준에서 구성할 수 있으며 컬렉션 및 인덱스 생성 중에 컬렉션 및 인덱스별로 설정할 수도 있습니다.

WiredTiger 내부 캐시와 온디스크 형식의 데이터에는 서로 다른 표현이 사용됩니다.

• 파일 시스템 캐시의 데이터는 온디스크 형식과 동일하며, 데이터 파일에 대한 모든 압축의 이점을 누릴 수 있습니다. 파일시스템 캐시는 운영 체제에서 디스크 I/O를 줄이기 위해 사용됩니다.

• WiredTiger 내부 캐시에 로드된 인덱스는 온디스크 형식과는 다른 데이터 표현을 갖지만, 인덱스 접두사 압축을 활용하여 RAM 사용량을 줄일 수 있습니다. 인덱스 접두사 압축은 인덱싱된 필드에서 공통 접두사를 중복 제거합니다.

• WiredTiger 내부 캐시의 컬렉션 데이터는 압축되지 않으며 온디스크 형식과 다른 표현을 사용합니다. 차단 압축은 상당한 온디스크 스토리지 절감을 제공할 수 있지만 서버에서 데이터를 조작하려면 압축을 풀어야 합니다.

MongoDB는 파일 시스템 캐시를 통해 자동으로 WiredTiger 캐시나 다른 프로세스에서 사용되지 않는 모든 여유 메모리를 사용합니다.

와이어드타이거 내부 캐시 크기를 조정하려면 storage.wiredTiger.engineConfig.cacheSizeGB 및 --wiredTigerCacheSizeGB를 참조하세요. WiredTiger 내부 캐시 크기를 기본값 이상으로 늘리지 마세요.

기본 WiredTiger 내부 캐시 크기 값은 머신당 단일 mongod 인스턴스가 있다고 가정합니다. 단일 머신에 여러 MongoDB 인스턴스가 포함된 경우 다른 mongod 인스턴스를 수용할 수 있도록 설정을 줄여야 합니다.

시스템에서 사용 가능한 모든 RAM에 액세스할 수 없는 컨테이너에서 mongod를 실행하는 경우(예를 들어, lxc, cgroups, Docker 등) storage.wiredTiger.engineConfig.cacheSizeGB를 반드시 컨테이너에서 사용 가능한 RAM의 양보다 적은 값으로 설정해야 합니다. 정확한 양은 컨테이너에서 실행 중인 다른 프로세스에 따라 달라집니다. memLimitMB를 참조하세요.

캐시 및 퇴거율에 대한 통계를 보려면 serverStatus명령에서 반환된 wiredTiger.cache 필드를 참조하세요.

새로운 샤딩된 클러스터에서 모든 데이터가 하나의 샤드에 남는 이유는 무엇인가요?

샤딩이 가능하려면 클러스터에 충분한 데이터가 있어야 합니다. 샤딩은 각 샤드의 청크 수가 거의 같을 때까지 샤드 간에 청크를 마이그레이션하는 방식으로 작동합니다.

기본 청크 크기는 128MB입니다. 클러스터의 청크 불균형이 마이그레이션 임계값을 초과할 때까지 MongoDB는 마이그레이션을 시작하지 않습니다. 이 동작은 클러스터 전체의 성능을 저하시킬 수 있는 불필요한 청크 마이그레이션을 방지하는 데 도움이 됩니다.

방금 샤딩된 클러스터를 배포한 경우, 샤딩을 효과적으로 수행할 수 있을 만큼 충분한 데이터가 있는지 확인하세요. 8개보다 많은 128MB 청크를 생성할 만큼 데이터가 충분하지 않은 경우, 모든 데이터는 하나의 샤드에 유지됩니다. 청크 크기 설정을 낮추거나 클러스터에 더 많은 데이터를 추가하세요.

관련 문제로, 시스템은 삽입 또는 업데이트 시에만 청크를 분할하므로 샤딩을 구성하고 삽입 및 업데이트 작업을 계속 실행하지 않으면 데이터베이스에 청크가 생성되지 않습니다. 애플리케이션이 데이터를 삽입할 때까지 기다리거나 또는 청크를 수동으로 분할할 수 있습니다.

마지막으로, 샤드 키의 카디널리티가 낮은 경우, MongoDB가 데이터 간에 충분한 분할을 생성하지 못할 수 있습니다.

하나의 샤드가 샤딩된 클러스터에서 불균형한 양의 트래픽을 수신하는 이유는 무엇인가요?

경우에 따라 단일 샤드 또는 클러스터의 하위 집합이 트래픽 및 워크로드의 불균형한 부분을 받게 됩니다. 거의 대부분의 경우 이는 샤드 키가 쓰기 확장을 효과적으로 허용하지 않는 경우의 결과입니다.

'핫 청크'가 있을 수도 있습니다. 이 경우 해당 청크의 일부를 분할한 후 마이그레이션하여 문제를 해결할 수 있습니다.

이 패턴을 수정하기 위해 다른 샤드 키를 사용하여 컬렉션을 다시 샤딩하는 것을 고려해야 할 수 있습니다.

샤딩된 클러스터의 밸런싱을 방해하는 요소는 무엇인가요?

방금 샤딩된 클러스터를 배포한 경우 데이터가 단일 샤드에 남아 있는 새 클러스터에 대한 문제 해결 제안을 고려할 수 있습니다.

cluster가 처음에는 균형을 이루었지만, 나중에 데이터 분포가 고르지 않다면 다음과 같은 원인을 고려하세요.

• 클러스터에서 상당한 양의 데이터를 삭제하거나 제거했습니다. 추가 데이터를 추가한 경우 샤드 키 분산이 다를 수 있습니다.

• 샤드 키의 카디널리티가 낮아서 MongoDB가 청크를 더 이상 분할할 수 없습니다.

• 밸런서가 클러스터 전체에 데이터를 분산할 수 있는 속도보다 빠르게 데이터 세트가 증가하고 있습니다. 이는 드문 경우이며 일반적으로 다음과 같은 이유로 발생합니다.

  • 데이터 증가 속도를 고려할 때 밸런싱 시간이 너무 짧습니다.

  • 쓰기 작업이 고르게 분산되어 있지 않아 더 많은 데이터 마이그레이션이 필요합니다. 이 문제를 해결하려면 다른 샤드 키를 선택해야 할 수도 있습니다.

  • 샤드 간 네트워크 연결이 좋지 않아 청크 마이그레이션을 완료하는 데 너무 오랜 시간이 걸릴 수 있습니다. 네트워크 구성 및 샤드 간의 상호 연결을 조사합니다.

청크 마이그레이션이 샤딩된 클러스터 성능에 영향을 미치는 이유는 무엇인가요?

마이그레이션이 클러스터 또는 애플리케이션의 성능에 영향을 주는 경우 영향의 특성에 따라 다음 옵션을 고려합니다.

1. 마이그레이션으로 인해 클러스터가 간헐적으로 중단되는 경우에는 밸런싱 시간을 제한하여 피크 시간대에 밸런싱 활동이 발생하지 않도록 할 수 있습니다. 데이터의 밸런스가 다시 깨지지 않도록 충분한 시간이 남아 있는지 확인합니다.

2. 밸런서가 항상 전체 클러스터 성능이 저하될 때까지 청크를 마이그레이션하는 경우:

   • 청크 크기를 줄여 마이그레이션 크기를 제한할 수도 있습니다.

   • 클러스터의 용량이 초과되었을 수 있으며, 부하를 분산하기 위해 클러스터에 샤드 한두 개를 추가하려고 시도할 수 있습니다.

샤드 키로 인해 애플리케이션이 모든 쓰기를 단일 샤드로 보낼 수도 있습니다. 이러한 활동 패턴의 경우 밸런서가 데이터를 작성한 후 바로 대부분의 데이터를 마이그레이션해야 할 수 있습니다. 더 나은 쓰기 확장을 제공하는 다른 샤드 키로 컬렉션을 재샤딩하는 것을 고려해야 할 수도 있습니다.