문서 홈 → 애플리케이션 개발 → MongoDB 매뉴얼
FAQ: MongoDB 진단
이 페이지의 내용
이 문서에서는 일반적인 진단 질문과 문제에 대한 답변을 제공합니다.
원하는 답변을 찾지 못한 경우 FAQ의 전체 목록을 확인하거나 MongoDB Community에 질문을 게시하세요.
예기치 않게 실행이 중지된 mongod 프로세스에 대한 정보는 어디에서 찾을 수 있나요?
mongod가 UNIX 또는 UNIX 기반 플랫폼에서 예기치 않게 종료되고 mongod가 종료 또는 오류 메시지를 기록하지 못하는 경우 시스템 로그에서 MongoDB와 관련된 메시지를 확인합니다. 예를 들어, /var/log/messages에 있는 로그의 경우 다음 명령을 사용합니다.
sudo grep mongod /var/log/messages sudo grep score /var/log/messages
TCP keepalive 시간이 MongoDB deployment에 영향을 주나요?
클라이언트와 서버 간 또는 샤드 클러스터 또는 복제본 세트의 멤버 간 통신에서 네트워크 시간 초과 또는 소켓 오류가 발생하는 경우, 영향을 받는 시스템의 TCP 킵얼라이브 값을 확인합니다.
대부분의 운영 체제에서는 이 값을 기본적으로 7200초(2시간)로 설정합니다. MongoDB의 경우 일반적으로 킵얼라이브 값이 120초 (2분) 정도로 짧을수록 더 나은 결과를 경험할 수 있습니다.
MongoDB deployment에서 킵얼라이브 관련 문제가 발생하는 경우, 영향을 받는 모든 시스템에서 킵얼라이브 값을 변경해야 합니다. 여기에는 mongod 또는 mongos 프로세스를 실행하는 모든 머신과 MongoDB에 연결하는 클라이언트 프로세스를 호스팅하는 모든 머신이 포함됩니다.
TCP 킵얼라이브 값 조정:
시스템 전체에 새 킵얼라이브 설정을 적용하려면 mongod 및 mongos 프로세스를 다시 시작해야 합니다.
TCP 재전송 시간 초과가 MongoDB deployment에 영향을 미치나요?
클라이언트와 서버 간 또는 샤드 클러스터 또는 복제본 세트의 멤버 간에 네트워크 시간 초과 또는 소켓 오류와 함께 긴 중단(2분 이상 중단)이 발생하는 경우 영향을 받는 시스템에 대해 tcp_retries2 값을 확인합니다.
대부분의 Linux 운영 체제는 기본적으로 이 값을 15로, Windows는 5로 설정합니다. MongoDB의 경우 5(12초) 이하 정도의 낮은 tcp_retries2 값을 사용하면 더 나은 결과를 얻을 수 있습니다.
MongoDB deployment에서 TCP 재전송 시간 초과 관련 문제가 발생하는 경우 영향을 받는 모든 시스템에 대해 tcp_retries2 값(Windows의 경우 TcpMaxDataRetransmission)을 변경합니다. 여기에는 mongod 또는 mongos 프로세스를 실행하는 모든 머신과 MongoDB에 연결하는 클라이언트 프로세스를 호스팅하는 모든 머신이 포함됩니다.
TCP 재전송 시간 초과 조정
MongoDB가 " 연결 허용 " 이벤트를 그렇게 많이 기록하는 이유는 무엇인가요?
MongoDB 로그에 매우 많은 수의 연결 및 재연결 메시지가 표시되면 클라이언트가 MongoDB server에 자주 연결하고 연결을 끊는 것입니다. 이는 CGI와 같이 요청 풀링을 사용하지 않는 애플리케이션의 정상적인 동작입니다. FastCGI, Apache 모듈 또는 다른 종류의 영구 애플리케이션 서버를 사용하여 연결 오버헤드를 줄이는 것이 좋습니다.
이러한 연결이 성능에 영향을 주지 않는다면 런타임 quiet 옵션 또는 명령줄 옵션 --quiet을(를) 사용하여 로그에서 이러한 메시지를 표시하지 않게 할 수 있습니다.
MongoDB를 모니터링하는 데 사용할 수 있는 도구는 무엇입니까?
MongoDB Cloud Manager 와 MongoDB Enterprise Advanced에서 사용할 수 있는 온프레미스 솔루션인 Ops Manager 에는 실행 중인 MongoDB 배포에서 데이터를 수집하고 해당 데이터를 기반으로 시각화 및 경고를 제공하는 모니터링 기능이 포함되어 있습니다.
자세한 내용은 MongoDB Cloud Manager 설명서 및 Ops Manager 설명서를 참조하세요.
타사 도구의 전체 목록은 MongoDB 모니터링 설명서의 일부로 제공됩니다.
WiredTiger 스토리지 엔진의 메모리 진단
작업 세트 크기가 RAM에 꼭 맞아야 하나요?
아니요.
캐시에 추가 데이터를 로드할 공간이 충분하지 않은 경우 WiredTiger는 캐시에서 페이지를 제거하여 공간을 확보합니다.
참고
storage.wiredTiger.engineConfig.cacheSizeGB 는 WiredTiger 내부 캐시의 크기를 제한합니다. 운영 체제는 사용 가능한 여유 메모리를 파일 시스템 캐시에 사용하므로 압축된 MongoDB 데이터 파일을 메모리에 유지할 수 있습니다. 또한 운영 체제는 여유 RAM을 사용하여 파일 시스템 차단과 파일 시스템 캐시를 버퍼링합니다.
추가적인 RAM 소비를 수용하려면 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를 통해 내부 캐시와 파일 시스템 캐시 모두를 활용합니다.
MongoDB 3.4부터는 기본 WiredTiger 내부 캐시 크기가 다음 중 큰 값으로 설정됩니다.
(RAM - 1GB)의 50%
256MB
예를 들어 총 RAM이 4GB인 시스템에서 WiredTiger 캐시는 1 사용합니다.5GB RAM(0.5 * (4 GB - 1 GB) =
1.5 GB). 반대로 총 1 인 시스템에서는 25 GB RAM WiredTiger는 WiredTiger 캐시에 256 MB를 할당하는데, 이는 전체 RAM에서 1기가바이트를 뺀 값의 절반 이상이기 때문입니다(0.5 * (1.25 GB - 1 GB) = 128 MB < 256 MB).
참고
컨테이너에서 실행할 때 등의 일부 인스턴스에서는 데이터베이스 메모리 제한이 총 시스템 메모리보다 낮을 수 있습니다. 이러한 인스턴스에서는 총 시스템 메모리가 아니라 이 메모리 제한이 사용 가능한 최대 RAM으로 사용됩니다.
메모리 제한을 보려면 hostInfo.system.memLimitMB 참조하세요.
기본적으로 WiredTiger는 모든 컬렉션에 Snappy 차단 압축을 사용하고 모든 인덱스에 접두사 압축을 사용합니다. 압축 기본값은 전역 수준에서 구성할 수 있으며 컬렉션 및 인덱스 생성 중에 컬렉션 및 인덱스별로 설정할 수도 있습니다.
WiredTiger 내부 캐시와 온디스크 형식의 데이터에는 서로 다른 표현이 사용됩니다.
파일 시스템 캐시의 데이터는 온디스크 형식과 동일하며, 데이터 파일에 대한 모든 압축의 이점을 누릴 수 있습니다. 파일시스템 캐시는 운영 체제에서 디스크 I/O를 줄이기 위해 사용됩니다.
WiredTiger 내부 캐시에 로드된 인덱스는 온디스크 형식과는 다른 데이터 표현을 갖지만, 인덱스 접두사 압축을 활용하여 RAM 사용량을 줄일 수 있습니다. 인덱스 접두사 압축은 인덱싱된 필드에서 공통 접두사를 중복 제거합니다.
WiredTiger 내부 캐시의 컬렉션 데이터는 압축되지 않으며 온디스크 형식과 다른 표현을 사용합니다. 차단 압축은 상당한 온디스크 스토리지 절감을 제공할 수 있지만 서버에서 데이터를 조작하려면 압축을 풀어야 합니다.
파일 시스템 캐시를 사용하면 MongoDB는 WiredTiger 캐시나 다른 프로세스에서 사용하지 않는 모든 여유 메모리를 자동으로 사용합니다.
와이어드타이거 내부 캐시 크기를 조정하려면 storage.wiredTiger.engineConfig.cacheSizeGB 및 --wiredTigerCacheSizeGB를 참조하세요. WiredTiger 내부 캐시 크기를 기본값 이상으로 늘리지 마세요.
참고
storage.wiredTiger.engineConfig.cacheSizeGB 는 WiredTiger 내부 캐시의 크기를 제한합니다. 운영 체제는 사용 가능한 여유 메모리를 파일 시스템 캐시에 사용하므로 압축된 MongoDB 데이터 파일을 메모리에 유지할 수 있습니다. 또한 운영 체제는 여유 RAM을 사용하여 파일 시스템 차단과 파일 시스템 캐시를 버퍼링합니다.
추가적인 RAM 소비를 수용하려면 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가 처음에는 균형을 이루었지만, 나중에 데이터 분포가 고르지 않다면 다음과 같은 원인을 고려하세요.
클러스터에서 상당한 양의 데이터를 삭제하거나 제거했습니다. 추가 데이터를 추가한 경우 샤드 키 분산이 다를 수 있습니다.
밸런서가 클러스터 전체에 데이터를 분산할 수 있는 속도보다 빠르게 데이터 세트가 증가하고 있습니다. 이는 드문 경우이며 일반적으로 다음과 같은 이유로 발생합니다.
청크 마이그레이션이 샤드 클러스터 성능에 영향을 미치는 이유는 무엇인가요?
마이그레이션이 클러스터 또는 애플리케이션의 성능에 영향을 주는 경우 영향의 특성에 따라 다음 옵션을 고려합니다.
마이그레이션으로 인해 클러스터가 간헐적으로 중단되는 경우에는 밸런싱 시간을 제한하여 피크 시간대에 밸런싱 활동이 발생하지 않도록 할 수 있습니다. 데이터의 밸런스가 다시 깨지지 않도록 충분한 시간이 남아 있는지 확인합니다.
밸런서가 항상 전체 클러스터 성능이 저하될 때까지 청크를 마이그레이션하는 경우:
청크 크기를 줄여 마이그레이션 크기를 제한할 수도 있습니다.
클러스터의 용량이 초과되었을 수 있으며, 부하를 분산하기 위해 클러스터에 샤드 한두 개를 추가하려고 시도할 수 있습니다.
샤드 키로 인해 애플리케이션이 모든 쓰기를 단일 샤드로 보낼 수도 있습니다. 이러한 활동 패턴의 경우 밸런서가 데이터를 작성한 후 바로 대부분의 데이터를 마이그레이션해야 할 수 있습니다. 더 나은 쓰기 확장을 제공하는 다른 샤드 키로 컬렉션을 재샤딩하는 것을 고려해야 할 수도 있습니다.