자체 관리 배포서버를 위한 프로덕션 노트

wiredTiger

WiredTiger 스토리지 엔진은 멀티스레드로, 추가 CPU 코어를 활용할 수 있습니다. 특히 활성 스레드의 총 개수(예 동시 작업)는 사용 가능한 CPU 수와 관련이 있으며 성능에 영향을 줄 수 있습니다.

• 동시 활성 작업 수가 CPU 수만큼 증가하면 처리량이 증가합니다.

• 동시 활성 작업 수가 CPU 수를 일부 임계값만큼 초과하면 처리량이 감소합니다.

임계값은 애플리케이션에 따라 다릅니다. 처리량을 실험하고 측정하여 애플리케이션에 가장 적합한 동시 활성 작업 수를 결정할 수 있습니다. mongostat의 출력은 (ar|aw) 열의 활성 읽기/쓰기 수에 대한 통계를 제공합니다.

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 필드를 참조하세요.

압축 및 암호화

암호화를 사용할 때 AES-NI 지침 세트 확장이 장착된 CPU는 상당한 성능 이점을 보여줍니다. 암호화된 스토리지 엔진과 함께 MongoDB Enterprise를 사용하는 경우, 더 나은 성능을 위해 AES-NI를 지원하는 CPU를 선택하세요.

Windows에서 NUMA 구성

Windows에서는 컴퓨터의 BIOS를 통해 메모리 인터리빙을 활성화해야 합니다. 자세한 내용은 시스템 설명서를 참조하세요.

Linux에서 NUMA 구성

Linux에서는 구역 회수 기능을 비활성화하고 mongod 및 mongos 인스턴스가 일반적으로 플랫폼의 init 시스템을 통해 구성되는 numactl에 의해 시작되도록 해야 합니다. 이 두 가지 작업을 모두 수행해야 MongoDB와 함께 사용할 수 있도록 NUMA를 올바르게 비활성화할 수 있습니다.

1. 다음 명령 중 하나를 사용하여 구역 회수 기능을 비활성화합니다:

   echo 0 | sudo tee /proc/sys/vm/zone_reclaim_mode

   sudo sysctl -w vm.zone_reclaim_mode=0

2. mongod 및 mongos가 numactl로 시작되는지 확인합니다. 이는 일반적으로 플랫폼의 init 시스템을 통해 구성됩니다. 다음 명령을 실행하여 플랫폼에서 사용 중인 init 시스템을 확인합니다:

   ps --no-headers -o comm 1

   • "systemd"인 경우 플랫폼에서 systemd 초기화 시스템을 사용하며, 아래 systemd 탭의 단계에 따라 MongoDB 서비스 파일을 편집해야 합니다.

   • "init"인 경우 플랫폼에서 SysV 초기화 시스템을 사용하므로 이 단계를 수행할 필요가 없습니다. SysV 초기화를 위한 기본 MongoDB init 스크립트에는 기본적으로 numactl을 통해 MongoDB 인스턴스를 시작하는 데 필요한 단계가 포함되어 있습니다.

   • init 스크립트를 직접 관리하는 경우(예: 이러한 init 시스템 중 하나를 사용하고 있지 않은 경우), 아래의 init 스크립트 사용자 지정 탭에 있는 단계를 반드시 준수하여 사용자 정의 init 스크립트를 편집해야 합니다.

     
     
   systemd

   사용자 지정 init 스크립트

   모든 config 서버, mongos 인스턴스 및 클라이언트를 포함하여 각 mongod인스턴스를 시작하려면 numactl을 사용해야 합니다. 다음과 같이 각각에 대한 기본 systemd 서비스 파일을 편집합니다.

   1. 기본 MongoDB 서비스 파일을 복사합니다.

      sudo cp /lib/systemd/system/mongod.service /etc/systemd/system/

   2. /etc/systemd/system/mongod.service 파일을 편집하고 ExecStart 문을 업데이트하여 다음으로 시작합니다.

      /usr/bin/numactl --interleave=all

      예시

      기존 ExecStart 문이 다음과 같은 경우.

      ExecStart=/usr/bin/mongod --config /etc/mongod.conf

      해당 문을 업데이트하여 다음을 읽도록 합니다.

      ExecStart=/usr/bin/numactl --interleave=all /usr/bin/mongod --config /etc/mongod.conf

   3. systemd 에 변경 사항을 적용합니다.

      sudo systemctl daemon-reload

   4. 실행 중인 mongod 인스턴스를 다시 시작합니다.

      sudo systemctl stop mongod
      sudo systemctl start mongod

   5. 해당하는 경우 모든 mongos 인스턴스에 대해 이 단계를 반복합니다.

   모든 config 서버, mongos 인스턴스 및 클라이언트를 포함하여 각 mongod인스턴스를 시작하려면 numactl을 사용해야 합니다.

   1. 아직 설치되지 않은 경우 플랫폼에 맞게 numactl을(를) 설치합니다. numactl 패키지 설치에 대한 자세한 내용은 운영 체제 설명서를 참조하세요.

   2. 각 사용자 정의 초기화 스크립트가 numactl를 통해 각 MongoDB 인스턴스를 시작하도록 구성합니다.

      numactl --interleave=all <path> <options>

      여기서 <path>은(는) 시작하는 프로그램의 경로이고 <options>은(는) 해당 프로그램에 전달할 선택적 인수입니다.

      예시

      numactl --interleave=all /usr/local/bin/mongod -f /etc/mongod.conf

자세한 내용은 /proc/sys/vm/* 문서를 참조하세요.

Swap

스왑에서 데이터를 검색하는 것은 항상 RAM의 데이터에 액세스하는 것보다 느리기 때문에 스왑을 피하거나 최소한으로 유지할 수 있는 경우 MongoDB의 성능이 가장 우수합니다. 그러나 MongoDB를 호스팅하는 시스템의 RAM이 부족한 경우 스왑을 수행하면 Linux OOM 킬러가 mongod 프로세스를 종료하지 못할 수 있습니다.

일반적으로 다음 스왑 전략 중 하나를 선택해야 합니다:

1. 시스템에 스왑 공간을 할당하고 메모리 부하가 높은 경우에만 스와핑을 허용하도록 커널을 구성합니다.

2. 시스템에 스왑 공간을 할당하지 말고 스왑을 완전히 비활성화하도록 커널을 구성하세요.

이 가이드라인에 따라 Linux 시스템에서 스왑을 구성하는 방법과 관련한 정보를 알아보려면 vm.swappiness 설정을 참조하세요.

RAID

스토리지 계층의 성능을 최적화하려면 RAID-10으로 지원되는 디스크를 사용하세요. RAID-5 및 RAID-6은 일반적으로 MongoDB deployment를 지원하기에 충분한 성능을 제공하지 않습니다.

원격 파일 시스템(NFS)

원격 파일 시스템이 ISO/IEC 9945-1:1996(POSIX.1)을 준수하는 경우, WiredTiger 스토리지 엔진을 통해 WiredTiger 객체를 원격 파일 시스템에 저장할 수 있습니다. 원격 파일 시스템은 로컬 파일 시스템보다 속도가 느린 경우가 많으므로, 원격 파일 시스템을 스토리지로 사용하면 성능이 저하될 수 있습니다.

NFS를 사용하기로 결정한 경우 /etc/fstab 파일에 다음 NFS 옵션을 추가합니다.

• bg

• hard

• nolock

• noatime

• nointr

커널 버전에 따라 이러한 값 중 일부가 이미 기본값으로 설정되었을 수 있습니다. 자세한 내용은 해당 플랫폼의 설명서를 참조하세요.

구성 요소를 다른 저장 장치에 분리

성능을 향상시키려면 애플리케이션의 액세스 및 쓰기 패턴에 따라 데이터베이스의 데이터, 저널 및 로그를 서로 다른 저장 장치에 분리하는 것이 좋습니다. 컴포넌트를 별도의 파일 시스템으로 마운트하고 심볼릭 링크를 사용하여 각 컴포넌트를 저장된 장치에 매핑합니다.

WiredTiger 스토리지 엔진의 경우 인덱스를 다른 스토리지 장치에 저장할 수도 있습니다. storage.wiredTiger.engineConfig.directoryForIndexes를 참조하세요.

일정 예약

커널 및 파일 시스템

Linux 프로덕션 환경에서 MongoDB를 실행하는 경우, Linux 커널 버전 2.6.36 이상을 사용해야 하며, 파일시스템은 XFS 또는 EXT4여야 합니다. 가능하면 일반적으로 MongoDB에서 더 나은 성능을 발휘하는XFS를 사용하세요.

WiredTiger 스토리지 엔진과 함께 EXT4를 사용할 때 발생할 수 있는 성능 문제를 방지하려면 데이터 보유 노드에 XFS를 사용할 것을 적극 권장합니다.

• 일반적으로 XFS 파일 시스템을 사용하는 경우 Linux 커널 버전 2.6.25 이상을 사용해야 합니다.

• EXT4 파일 시스템을 사용하는 경우 Linux 커널 버전 2.6.28 이상을 사용해야 합니다.

• Red Hat Enterprise Linux 및 CentOS에서는 Linux 커널의 2.6.18-194 버전 이상을 사용하세요.

시스템 C 라이브러리

MongoDB는 Linux에서 GNU C 라이브러리(glibc)를 사용합니다. 일반적으로 각 Linux 배포판은 이 라이브러리의 자체 검증 버전을 제공합니다. 최상의 결과를 얻으려면 이 시스템 제공 버전에서 사용할 수 있는 최신 업데이트를 사용하세요. 시스템의 패키지 관리자를 사용하여 최신 버전이 설치되어 있는지 확인할 수 있습니다. 예시:

• RHEL/CentOS에서 다음 명령은 시스템에서 제공하는 GNU C 라이브러리를 업데이트합니다:

  sudo yum update glibc

• Ubuntu/Debian에서 다음 명령은 시스템에서 제공하는 GNU C 라이브러리를 업데이트합니다.

  sudo apt-get install libc6

fsync() 디렉토리에서

vm.swappiness를 1 또는 0으로 설정

'Swappiness'는 가상 메모리 관리자의 동작에 영향을 미치는 Linux 커널 설정입니다. vm.swappiness 설정 범위는 0에서 100까지입니다. 값이 클수록 RAM에서 페이지를 삭하는 것보다 메모리 페이지를 디스크로 스왑하는 것을 더 선호하게 됩니다.

• 0으로 설정하면 스와핑이 완전히 비활성화됩니다 [8 ].

• 1 설정은 메모리 부족 문제를 방지하기 위한 목적으로만 커널 교체를 허용합니다.

• 60 설정은 커널이 디스크로 자주 교체하도록 지시하며, 이는 많은 Linux 배포판의 기본값입니다.

• 100으로 설정하면 커널이 디스크에 적극적으로 스왑하도록 지시합니다.

MongoDB는 스와핑을 피하거나 최소한으로 유지할 수 있는 경우 가장 우수한 성능을 발휘합니다. 따라서 애플리케이션 요구 사항 및 클러스터 구성에 따라 vm.swappiness를 1 또는 0으로 설정해야 합니다.

• 시스템의 현재 swappiness 설정을 확인하려면 다음을 실행하세요.

  cat /proc/sys/vm/swappiness

• 시스템에서 스왑을 변경하려면 다음을 수행합니다.

  1. /etc/sysctl.conf 파일을 편집하고 다음 줄을 추가합니다:

     vm.swappiness = 1

  2. 다음 명령을 실행하여 설정을 적용합니다.

     sudo sysctl -p

권장 구성

모든 MongoDB deployments의 경우:

• 네트워크 시간 프로토콜(NTP)을 사용하여 호스트 간에 시간을 동기화할 수 있습니다. 이는 샤딩된 클러스터에서 특히 중요합니다.

WiredTiger 스토리지 엔진의 경우 다음 권장 사항을 고려하세요.

• 데이터베이스 파일이 들어 있는 스토리지 볼륨의 atime를 끕니다.

• ulimit 참고의 권장 사항에 따라 플랫폼의 ulimit 설정을 조정합니다. ulimit 값이 낮으면 사용량이 많을 때 MongoDB에 부정적인 영향을 미치고 MongoDB 프로세스에 대한 연결 실패 및 서비스 손실로 이어질 수 있습니다.

  참고

  열려 있는 파일 수의 ulimit 값이 64000 미만인 경우 MongoDB가 시작 경고를 생성합니다.

• MongoDB 8.0 실행 중이라면 Transparent Hugepages를 활성화하세요.

  • MongoDB 7.0 또는 이전 버전을 실행 중이라면 Transparent Hugepages를 비활성화하세요. 이전 버전에서 MongoDB는 일반(4096 바이트) 가상 메모리 페이지에서 더 나은 성능을 발휘했습니다.

• BIOS에서 NUMA를 비활성화합니다. 불가능한 경우 NUMA 하드웨어의 MongoDB를 참조하세요.

• 기본 MongoDB 디렉토리 경로 또는 포트 사용하지 않는 경우 MongoDB용 SELinux를 구성합니다.

  참고

  SELinux를 사용하는 경우 서버 측 JavaScript를 필요로 하는 모든 MongoDB 작업은 세그폴트 오류를 발생시킵니다. JavaScript의 서버 측 실행 비활성화에서는 서버 측 JavaScript의 실행을 비활성화하는 방법을 설명합니다.

WiredTiger 스토리지 엔진의 경우:

• 저장 미디어의 종류(스피닝 디스크, SSD 등)에 관계없이 8에서 32 사이의 readahead를 설정합니다.

  일반적으로 읽기 헤드가 높을 수록 순차적 I/O 작업에 유리합니다. MongoDB 디스크 액세스 패턴은 일반적으로 무작위이기 때문에 더 높은 읽기 헤드 설정을 사용하면 이점이 제한적이거나 성능이 저하될 수 있습니다. 따라서 테스트 결과 더 높은 읽기 헤드 값에서 측정 가능하고 반복 가능하며 신뢰할 수 있는 이점을 얻을 수 있는 경우가 아니라면, 최적의 MongoDB 성능을 위해 읽기 헤드를 8~32 사이로 설정하세요. MongoDB 상업 부문 지원팀이 대체 읽기 헤드 구성에 대한 조언과 지침을 제공해 드릴 수 있습니다.

MongoDB 및 TLS/SSL 라이브러리

Linux 플랫폼에서는 MongoDB 로그에서 다음 명령문 중 하나를 볼 수 있습니다.

<path to TLS/SSL libs>/libssl.so.<version>: no version information available (required by /usr/bin/mongod)
<path to TLS/SSL libs>/libcrypto.so.<version>: no version information available (required by /usr/bin/mongod)

이러한 경고는 시스템의 TLS/SSL 라이브러리가 mongod가 컴파일된 TLS/SSL 라이브러리와 다르다는 것을 나타냅니다. 일반적으로 이러한 메시지에는 개입이 필요하지 않지만 다음 작업을 사용하여 mongod가 예상하는 기호 버전을 확인할 수 있습니다:

objdump -T <path to mongod>/mongod | grep " SSL_"
objdump -T <path to mongod>/mongod | grep " CRYPTO_"

이러한 작업은 다음 줄 중 하나와 유사한 출력을 반환합니다.

0000000000000000      DF *UND*       0000000000000000  libssl.so.10 SSL_write
0000000000000000      DF *UND*       0000000000000000  OPENSSL_1.0.0 SSL_write

이 출력의 마지막 두 문자열은 기호 버전과 기호 이름입니다. 이 값을 다음 작업에서 반환된 값과 비교하여 기호 버전 불일치를 검색합니다.

objdump -T <path to TLS/SSL libs>/libssl.so.1*
objdump -T <path to TLS/SSL libs>/libcrypto.so.1*

이 절차는 정확하지도 완전하지도 않습니다. libcrypto 라이브러리에서 mongod가 사용하는 기호 중 상당수는 CRYPTO_로 시작하지 않습니다.

AWS EC2

고려해야 할 두 가지 성능 구성이 있습니다.

• 성능 테스트 또는 벤치마킹을 위한 재현 가능한 성능, 그리고

• 원시 최대 성능

두 구성 모두에 대해 EC2에서 성능을 조정하려면 다음과 같이 해야 합니다:

• 인스턴스에 대해 AWS 향상된 네트워킹을 활성화합니다. 모든 인스턴스 유형이 향상된 네트워킹을 지원하는 것은 아닙니다.

  향상된 네트워킹에 대해 자세히 알아보려면 AWS 설명서를 참조하세요.

• tcp_keepalive_time를 120으로 설정합니다.

EC2에서 재현 가능한 성능에 더 관심이 있는 경우라면 이 또한 고려해야 합니다:

• 저널과 데이터를 위한 별도의 장치로 스토리지에 프로비저닝된 IOPS를 사용하세요. 대부분의 인스턴스 유형에서 사용할 수 있는 임시(SSD) 스토리지는 성능이 시시각각 변하므로 사용하지 마십시오. (i 시리즈는 주목할 만한 예외이지만 매우 비쌉니다.)

• DVFS 및 CPU 절전 모드를 비활성화합니다.

  팁

  다음도 참조하세요.

  프로세서 상태 제어에 대한 Amazon 문서

• 하이퍼스레딩을 비활성화합니다.

  팁

  다음도 참조하세요.

  하이퍼스레딩 비활성화에 관한 Amazon 블로그 게시물.

• 메모리 지역성을 단일 소켓에 바인딩하려면 numactl를 사용합니다.

Azure

프리미엄 스토리지를 사용합니다. Microsoft Azure는 표준 스토리지와 프리미엄 스토리지라는 두 가지 일반적인 유형의 스토리지를 제공합니다. Azure의 MongoDB는 표준 스토리지보다 프리미엄 스토리지를 사용할 때 더 나은 성능을 제공합니다.

Azure 로드 밸런서의 TCP 유휴 시간 제한은 기본적으로 240초입니다. 이로 인해 Azure 시스템의 TCP 연결 유지가 이 값보다 큰 경우 자동으로 연결이 제거될 수 있습니다. 이 문제를 개선하려면 tcp_keepalive_time을 120으로 설정해야 합니다.

• Linux에서 킵얼라이브 설정을 확인하려면 다음 명령 중 하나를 사용합니다:

  sysctl net.ipv4.tcp_keepalive_time

  또는:

  cat /proc/sys/net/ipv4/tcp_keepalive_time

  값은 초 단위로 측정됩니다.

  참고

  설정 이름에 ipv4가 포함되어 있지만, tcp_keepalive_time 값은 IPv4와 IPv6 모두에 적용됩니다.

• tcp_keepalive_time 값을 변경하려면 다음 명령 중 하나를 사용하여 <value>를 초 단위로 입력하면 됩니다

  sudo sysctl -w net.ipv4.tcp_keepalive_time=<value>

  또는:

  echo <value> | sudo tee /proc/sys/net/ipv4/tcp_keepalive_time

  이러한 연산은 시스템 재부팅 시 지속되지 않습니다. 설정을 유지하려면 다음 줄을 /etc/sysctl.conf에 추가하고 <value>를 초 단위로 입력한 후 머신을 재부팅하세요.

  net.ipv4.tcp_keepalive_time = <value>

  300초(5분)보다 큰 킵얼라이브 값은 mongod 및 mongos 소켓에서 재정의되고 300초로 설정됩니다.

• Windows에서 킵얼라이브 설정을 확인하려면 다음 명령을 실행합니다:

  reg query HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters /v KeepAliveTime

  레지스트리 값은 기본적으로 존재하지 않습니다. 값이 없는 경우 사용되는 시스템 기본값은 7200000 밀리초 또는 16진수로 0x6ddd00입니다.

  
  

• KeepAliveTime 값을 변경하려면 관리자 Command Prompt에서 다음 명령을 사용합니다. 여기서 <value>는 16진수로 표시됩니다 (예: 120000는 0x1d4c0입니다):

  reg add HKLM\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\ /t REG_DWORD /v KeepAliveTime /d <value>

  Windows 사용자가 Windows 시스템에서 MongoDB 배포를 위한 킵얼라이브 설정에 대한 자세한 알아보려면 KeepAliveTime에 대한 Windows Server 테크넷 문서를 참조하세요. 600000 밀리초(10 분)보다 크거나 같은 킵얼라이브 값은 mongod 및mongos에서 무시됩니다.

VMware

MongoDB는 VMware와 호환됩니다.

VMware는 물리적 머신의 사용 가능한 메모리보다 더 많은 메모리를 가상 머신에 할당할 수 있는 메모리 오버커밋을 지원합니다. 메모리가 오버커밋되면 하이퍼바이저는 가상 머신 간에 메모리를 재할당합니다. VMware의 벌룬 드라이버(vmmemctl)가 가장 가치가 낮은 것으로 간주되는 페이지를 회수합니다.

벌룬 드라이버는 게스트 운영 체제 내에 상주합니다. 특정 구성에서 벌룬 드라이버가 확장되면 MongoDB의 메모리 관리를 방해하고 MongoDB의 성능에 영향을 미칠 수 있습니다.

벌룬 드라이버 및 메모리 오버 커밋 기능으로 인해 성능이 저하되는 것을 방지하려면 MongoDB를 실행하는 가상 머신에 전체 메모리 양을 비축해 두세요. 가상 머신에 적절한 양의 메모리를 비축해 두면 하이퍼바이저의 메모리가 부족할 때 로컬 운영 체제에서 벌룬이 팽창하는 것을 방지할 수 있습니다.

벌룬 드라이버 및 메모리 오버커밋 기능은 특정 구성에서 MongoDB 성능에 부정적인 영향을 미칠 수 있지만 이러한 기능을 비활성화하도록 설정하지 않습니다. 이러한 기능을 비활성화하면 하이퍼바이저가 메모리 요청을 처리하기 위해 스왑 공간을 사용할 수 있으므로 성능에 부정적인 영향을 미칩니다.

VMware의 선호도 규칙을 설정하여 가상 머신이 특정 ESX/ESXi 호스트에 유지되는지 확인합니다. 가상 머신을 다른 호스트로 수동으로 마이그레이션해야 하고 가상 머신의 mongod 인스턴스가 프라이머리인 경우, 먼저 프라이머리를 step down 하고, shut down the instance해야 합니다.

vMotion 및 VMKernel에 대한 네트워킹 권장사항을 따릅니다. 권장사항을 따르지 않으면 성능 문제가 발생하고 복제본 세트 및 샤딩된 클러스터 고가용성 메커니즘에 영향을 미칠 수 있습니다.

MongoDB를 실행하는 가상 머신을 복제할 수 있습니다. 이 함수를 사용하여 새 가상 호스트를 배포하여 복제본 세트의 노드로 추가할 수 있습니다.

KVM

MongoDB는 KVM과 호환됩니다.

KVM은 메모리 오버커밋을 지원하여 가상 머신에 물리적 머신이 사용할 수 있는 메모리보다 더 많은 메모리를 할당할 수 있습니다. 메모리가 오버커밋되면 하이퍼바이저는 가상 머신 간에 메모리를 재할당합니다. KVM의 벌룬 드라이버는 가장 가치가 낮은 것으로 간주되는 페이지를 회수합니다.

벌룬 드라이버는 게스트 운영 체제 내에 상주합니다. 특정 구성에서 벌룬 드라이버가 확장되면 MongoDB의 메모리 관리를 방해하고 MongoDB의 성능에 영향을 미칠 수 있습니다.

벌룬 드라이버 및 메모리 오버 커밋 기능으로 인해 성능이 저하되는 것을 방지하려면 MongoDB를 실행하는 가상 머신에 전체 메모리 양을 비축해 두세요. 가상 머신에 적절한 양의 메모리를 비축해 두면 하이퍼바이저의 메모리가 부족할 때 로컬 운영 체제에서 벌룬이 팽창하는 것을 방지할 수 있습니다.

벌룬 드라이버 및 메모리 오버커밋 기능은 특정 구성에서 MongoDB 성능에 부정적인 영향을 미칠 수 있지만 이러한 기능을 비활성화하도록 설정하지 않습니다. 이러한 기능을 비활성화하면 하이퍼바이저가 메모리 요청을 처리하기 위해 스왑 공간을 사용할 수 있으므로 성능에 부정적인 영향을 미칩니다.