문서 홈 → 애플리케이션 개발 → MongoDB 매뉴얼
MongoDB 성능
이 페이지의 내용
MongoDB로 애플리케이션을 개발하고 운영할 때 애플리케이션 및 해당 데이터베이스의 성능 분석이 필요할 수 있습니다. 성능 저하가 발생하는 경우 데이터베이스 액세스 전략, 하드웨어 가용성, 열린 데이터베이스 연결 수 등이 원인인 경우가 많습니다.
일부 사용자는 불충분하거나 부적절한 인덱싱 전략 또는 잘못된 스키마 설계 패턴으로 인해 성능 제한을 경험할 수 있습니다. 잠금 성능 에서는 이러한 요소가 MongoDB의 내부 잠금에 어떤 영향을 미치는지 설명합니다.
성능 문제는 데이터베이스가 용량으로 작동 중이고 데이터베이스에 추가 용량을 추가해야 할 때임을 나타낼 수 있습니다. 특히 애플리케이션의 작업 세트는 사용 가능한 실제 메모리에 적합해야 합니다.
경우에 따라 성능 문제는 일시적이며 비정상적인 트래픽 부하와 관련이 있을 수 있습니다. 연결 수 에서 설명한 대로 확장은 과도한 트래픽을 완화하는 데 도움이 될 수 있습니다.
데이터베이스 프로파일링 은 어떤 작업이 성능 저하를 일으키는지 이해하는 데 도움이 될 수 있습니다.
잠금 성능
MongoDB는 데이터 세트 일관성을 보장하기 위해 잠금 시스템을 사용합니다. 특정 작업이 오래 실행되거나 대기열이 형성되면 요청 및 작업이 잠금을 대기함에 따라 성능이 저하됩니다.
잠금 관련 속도 저하가 간헐적으로 발생할 수 있습니다. 잠금이 성능에 영향을 미치는지 확인하려면 serverStatus 출력의 잠금 섹션과 globalLock 섹션을 참조하세요.
locks.<type>.timeAcquiringMicros를 locks.<type>.acquireWaitCount로 나누면 특정 잠금 모드의 대략적인 평균 대기 시간을 구할 수 있습니다.
locks.<type>.deadlockCount 잠금 획득 시 교착 상태가 발생한 횟수를 제공합니다.
globalLock.currentQueue.total가 지속적으로 높으면 많은 수의 요청이 잠금을 기다리는 중일 가능성이 있습니다. 이는 성능에 영향을 미치는 동시성 문제가 있을 수 있음을 나타냅니다.
만약 globalLock.totalTime이 uptime에 비해 높으면 데이터베이스가 상당한 시간 동안 잠금 상태로 존재한 것입니다.
긴 쿼리는 인덱스의 비효율적인 사용, 최적이 아닌 스키마 설계, 잘못된 쿼리 구조, 시스템 아키텍처 문제, 또는 부족한 RAM으로 인해 디스크 읽기가 발생할 수 있습니다.
연결 횟수
어떤 경우에는 애플리케이션과 데이터베이스 간의 연결 수가 요청을 처리하는 서버의 능력을 압도할 수 있습니다. serverStatus 문서의 다음 필드에서 인사이트를 얻을 수 있습니다:
connections다음 두 필드를 위한 컨테이너입니다.connections.current데이터베이스 인스턴스에 연결된 현재 클라이언트의 총 수입니다.connections.available새 클라이언트가 사용할 수 있는 미사용 연결의 총 개수입니다.
동시 애플리케이션 요청이 많은 경우 데이터베이스가 수요를 따라잡는 데 문제가 있을 수 있습니다. 이 경우 배포서버의 용량을 늘려야 합니다.
쓰기 작업이 많은 애플리케이션의 경우 샤딩을 배포하고 샤드 클러스터에 하나 이상의 샤드를 추가하여 mongod 인스턴스 간에 로드를 분산합니다.
연결 수의 급증은 애플리케이션 또는 드라이버 오류의 결과일 수도 있습니다.공식적으로 지원되는 모든 MongoDB 드라이버는 연결 풀링을 구현하여 클라이언트가 연결을 보다 효율적으로 사용하고 재사용할 수 있습니다. 특히 해당 워크로드가 없는 매우 높은 연결 수는 드라이버 또는 기타 구성 오류를 나타내는 경우가 많습니다.
시스템 전체 제한으로 제한되지 않는 한 MongoDB에서 지원하는 최대 수신 연결 수는 maxIncomingConnections 설정으로 구성됩니다. 유닉스 기반 시스템에서는 ulimit 명령을 사용하거나 시스템의 /etc/sysctl 파일을 편집하여 시스템 전체 제한을 수정할 수 있습니다. 자세한 내용은 UNIX ulimit 설정을 참조하세요.
데이터베이스 프로파일링
데이터베이스 프로파일러는 mongod 인스턴스에 대해 실행되는 작업에 대한 자세한 정보를 수집합니다. 프로파일러의 출력은 비효율적인 쿼리와 작업을 식별하는 데 도움이 될 수 있습니다.
개별 데이터베이스 또는 mongod 인스턴스의 모든 데이터베이스에 대해 프로파일링을 활성화하고 구성할 수 있습니다. 프로파일러 설정은 단일 mongod 인스턴스에만 영향을 미치며 복제본 세트 또는 샤드 cluster 전체에 전파되지 않습니다.
프로파일러 활성화 및 구성에 대한 자세한 내용은 데이터베이스 프로파일러를 참조하세요.
사용할 수 있는 프로파일링 수준은 다음과 같습니다.
경고
프로파일링은 성능을 저하시키고 시스템 로그에서 암호화되지 않은 쿼리 데이터를 노출시킬 수 있습니다. 프로덕션 배포서버에서 프로파일러를 구성하고 활성화하기 전에 이것이 성능과 보안에 미치는 영향을 신중하게 고려하세요.
잠재적인 성능 저하에 대한 자세한 내용은 프로파일러 오버헤드를 참조하십시오.
참고
logLevel을 0으로 설정하면, MongoDB는 slowOpSampleRate 에 의해 결정되는 속도로 느린 작업을 진단 로그에 기록합니다.
logLevel 설정이 높으면 지연 시간에 관계없이 모든 작업이 진단 로그에 표시되지만, 세컨더리에 의한 느린 oplog 항목 메시지 로깅은 예외입니다. 세컨더리는 느린 oplog 항목만 기록합니다. logLevel 를 늘려도 모든 oplog 항목이 기록되지는 않습니다.
MongoDB 4.2부터는 읽기/쓰기 작업에 대한 프로파일러 항목과 진단 로그 메시지 (즉, mongod/mongos 로그 메시지)는 다음을 포함합니다.
풀타임 진단 데이터 캡처
MongoDB 엔지니어가 서버 동작을 분석할 있도록 mongod 및 mongos 프로세스에는 FTDC(Full Time Diagnostic Data Capture) 메커니즘이 포함되어 있습니다. FTDC는 기본적으로 활성화되어 있습니다. 배포 디버깅에서 중요한 역할을 하기 때문에 FTDC 스레드 실패는 치명적이며 상위 mongod 또는 mongos 프로세스를 중지시킵니다.
중요
FTDC 개인정보 보호
FTDC 데이터 파일은 압축되어 있어 사람이 읽을 수 없습니다. MongoDB Inc. 엔지니어는 시스템 소유자나 연산자의 명시적인 허가와 지원 없이는 FTDC 데이터에 액세스할 수 없습니다.
다음 정보는 FTDC 데이터에 절대 포함되지 않습니다.
쿼리, 쿼리 조건자 또는 쿼리 결과의 샘플
최종 사용자 컬렉션 또는 인덱스에서 샘플로 가져온 데이터
시스템 또는 MongoDB 사용자 자격증명 또는 보안 인증서
FTDC 데이터에는 호스트 이름, 운영 체제 정보, mongod 또는 mongos 시작하는 데 사용된 옵션 또는 설정과 같은 특정 호스트 머신 정보가 포함되어 있습니다. 이 정보는 일부 조직 또는 규제 기관에서 보호되거나 기밀로 간주될 수 있지만 일반적으로 개인 식별 정보(PII)로 간주되지 않습니다. 이러한 필드가 보호, 기밀 또는 PII 데이터로 구성된 cluster의 경우 FTDC 데이터를 전송하기 전에 MongoDB Inc. 엔지니어에게 알려 적절한 조치를 취할 수 있도록 하세요.
FTDC는 다음 명령으로 생성된 통계를 주기적으로 수집합니다.
local.oplog.rscollection에 대한collStats(mongod만 해당)connPoolStats(mongos만 해당)
호스트 운영 체제에 따라 진단 데이터에는 다음 사용률 통계 중 하나 이상이 포함될 수 있습니다.
CPU 사용률
메모리 효율성
성능과 관련된 디스크 사용률입니다. FTDC에는 저장 용량과 관련된 데이터가 포함되지 않습니다.
네트워크 성능 통계 FTDC는 메타데이터만 캡처하며 네트워크 패킷을 캡처하거나 검사하지 않습니다.
참고
FTDC는 파일 회전 또는 시작 시 다음 명령으로 생성된 통계를 수집합니다.
mongod 프로세스는 storage.dbPath 인스턴스 아래의 diagnostic.data 디렉토리에 FTDC 데이터 파일을 저장합니다. 모든 진단 데이터 파일은 이 디렉터리에 저장됩니다. 예를 들어 /data/db의 dbPath 경우, 진단 데이터 디렉토리는 /data/db/diagnostic.data가 됩니다.
mongos프로세스는 systemLog.path 로그 경로 설정을 기준으로 진단 디렉토리에 FTDC 데이터 파일을 저장합니다. MongoDB는 로그 경로의 파일 확장자를 자르고 diagnostic.data를 나머지 이름에 연결합니다. 예를 들어 path 설정이 /var/log/mongodb/mongos.log인 경우 진단 데이터 디렉토리는 /var/log/mongodb/mongos.diagnostic.data가 됩니다.
FTDC는 다음과 같은 기본값으로 실행됩니다.
1초마다 데이터 캡처
최대 200MB
diagnostic.data폴더 크기
이러한 기본값은 성능이나 스토리지 크기에 미치는 영향을 최소화하면서 MongoDB Inc. 엔지니어에게 유용한 데이터를 제공하기 위해 설계되었습니다. 이 값은 MongoDB Inc. 엔지니어가 특정 진단 목적으로 요청한 경우에만 수정이 필요합니다.
FTDC 소스 코드는 MongoDB Github 리포지토리 에서 확인할 수 있습니다. . 파일은 ftdc_system_stats_*.ccp 캡처한 모든 시스템별 진단 데이터를 구체적으로 정의합니다.
FTDC를 비활성화하려면 mongod mongos diagnosticDataCollectionEnabled: false 구성 setParameter 파일의 설정에 옵션을 지정하여 또는 를 시작합니다.
setParameter: diagnosticDataCollectionEnabled: false
FTDC를 비활성화하면 MongoDB Inc. 엔지니어의 지원을 받아 문제를 분석하거나 디버깅할 때 필요한 시간이나 리소스가 증가할 수 있습니다.