문서 메뉴

문서 홈애플리케이션 개발MongoDB 매뉴얼

데이터베이스 프로파일러

이 페이지의 내용

  • 프로파일링 수준
  • 데이터베이스 프로파일링 활성화 및 구성
  • 프로파일러 데이터 보기
  • 프로파일러 오버헤드

데이터베이스 프로파일러는 실행 중인 mongod 인스턴스에 실행된 데이터베이스 명령어에 대한 자세한 정보를 수집합니다. 여기에는 CRUD 작업은 물론 구성 및 관리 명령도 포함됩니다.

프로파일러는 수집한 모든 데이터를 프로파일링된 각 데이터베이스의 고정 사이즈 컬렉션system.profile 컬렉션에 작성합니다. 프로파일러가 생성한 system.profile 문서에 대한 개요는 데이터베이스 프로파일러 출력을 참조하세요.

프로파일러는 기본적으로 off 입니다. 여러 프로파일링 수준 중 하나에서 데이터베이스별 또는 인스턴스별로 프로파일러를 활성화할 수 있습니다.

프로파일링을 활성화하면 데이터베이스 성능과 디스크 사용에 영향을 미칩니다. 자세한 내용은 데이터베이스 프로파일러 오버헤드 를 참조하세요.

이 페이지에는 데이터베이스 프로파일러의 중요한 관리 옵션이 나와 있습니다. 자세한 내용은 다음을 참조하세요.

경고

system.profile이라는 이름의 time series 컬렉션 또는 뷰를 만들려고 시도하지 마세요. MongoDB 6.3 이상 버전에서 이를 시도하는 경우 IllegalOperation 오류가 반환됩니다. 이전 MongoDB 버전은 충돌합니다.

사용할 수 있는 프로파일링 수준은 다음과 같습니다.

수준
설명
0
프로파일러가 꺼져 있고 데이터를 수집하지 않습니다. 이것이 기본 설정된 프로파일러 수준입니다.
1

프로파일러는 slowms 값보다 오래 걸리거나 필터와 일치하는 작업에 대한 데이터를 수집합니다.

필터가 설정된 경우:

  • slowms, sampleRate 옵션은 프로파일링에 사용되지 않습니다.

  • 프로파일러는 필터일치하는 작업만 캡처합니다.

2
프로파일러가 모든 작업의 데이터를 수집합니다.

mongod 인스턴스에 대해 데이터베이스 프로파일링을 활성화할 수 있습니다.

이 섹션에서는 mongosh 헬퍼 메서드 db.setProfilingLevel() 를 사용하여 프로파일링을 활성화하는 방법을 보여 줍니다. 대신 드라이버 메서드를 사용하려면 드라이버 설명서를 참조하세요.

mongod 인스턴스에 대해 프로파일링을 활성화하려면 프로파일링 수준0 보다 큰 값으로 설정합니다. 프로파일러는 system.profile 컬렉션에 데이터를 기록합니다. 해당 데이터베이스에 대해 프로파일링을 활성화하면 MongoDB가 데이터베이스에 system.profile 컬렉션을 생성합니다.

프로파일링을 활성화하고 프로파일링 수준을 설정하려면 db.setProfilingLevel() 헬퍼에게 프로파일링 수준을 전달합니다. 예를 들어, 현재 연결된 데이터베이스의 모든 데이터베이스 작업에 프로파일링을 사용하려면 mongosh 에서 이 작업을 실행합니다.

db.setProfilingLevel(2)

셸은 was 필드에서 이전 프로파일링 수준을 반환하고 새 수준을 설정합니다. 다음 출력에서 "ok" : 1 키-값 쌍은 작업이 성공했음을 나타냅니다.

{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }

새 설정을 확인하려면 프로파일링 수준 확인 섹션을 참조하세요.

MongoDB 5 부터 시작.0 profile 명령이나 db.setProfilingLevel() 래퍼 메서드를 사용하여 데이터베이스 프로파일러 level, slowms, sampleRate 또는 filter 에 대한 변경 사항은 log file 에 기록됩니다.

slowmssampleRate 프로파일링 설정은 글로벌 설정입니다. 이러한 설정은 프로세스의 모든 데이터베이스에 영향을 줍니다.

profile 명령 또는 db.setProfilingLevel() 셸 도우미 메서드를 통해 설정하면 프로파일링 수준필터 설정이 데이터베이스 수준에서 설정됩니다. 명령줄 또는 구성 파일 옵션으로 설정하면 프로파일링 수준 및 filter 설정이 전체 프로세스에 영향을 줍니다.

기본적으로 느린 작업의 임계값은 100밀리초입니다. 느린 작업 임계값을 변경하려면 다음 방법 중 하나로 필요한 임계값을 지정합니다.

다음 예에서는 현재 연결된 데이터베이스의 프로파일링 수준을 1로 설정하고 mongod 인스턴스의 느린 작업 임계값을 20 밀리초로 설정합니다.

db.setProfilingLevel( 1, { slowms: 20 } )

프로파일링 수준이 1이면 프로파일러가 slowms 임계값보다 느린 작업을 기록합니다.

중요

느린 작업 임계값은 mongod 인스턴스 의 모든 데이터베이스에 적용됩니다. 데이터베이스 프로파일러와 진단 로그 모두에서 사용되며 성능 저하를 방지하려면 이용 가능한 가장 높은 값으로 설정해야 합니다.

db.setProfilingLevel()을 사용하여 slowmssampleRatemongos에 구성할 수 있습니다. mongos의 경우, slowmssampleRate 구성 설정은 프로파일링이 mongos에서 사용할 수 없기 때문에 프로파일러가 아닌 진단 로그에만 영향을 미칩니다. [1]

다음 예시에서는 느린 작업을 기록하기 위해 mongos 인스턴스의 느린 작업 임계값을 20으로 설정합니다.

db.setProfilingLevel( 0, { slowms: 20 } )

MongoDB 4.2부터 읽기/쓰기 작업에 대한 프로파일러 항목진단 로그 메시지(예: mongod/mongos 로그 메시지)에 다음이 포함됩니다.

  • queryHash 동일한 쿼리 형태를 가진 느린 쿼리를 식별할 수 있습니다.

  • planCacheKey 느린 쿼리에 대한 쿼리 계획 캐시에 관해 더 많은 인사이트를 제공합니다.

버전 4.2부터 이제 복제본 세트의 보조 멤버가 느린 연산 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.

  • diagnostic log에 세컨더리 멤버에 대해 기록합니다.

  • applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.

  • 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.

  • 프로파일링 수준에 의존하지 않습니다.

  • slowOpSampleRate 의 영향을 받습니다.

프로파일러는 느린 oplog 항목을 캡처하지 않습니다.

모든 느린 연산 중 무작위로 샘플링된 하위 집합만 프로파일링하려면 다음 중 한 가지 방법으로 원하는 샘플 속도를 지정하세요. [2]

기본적으로 sampleRate1.0로 설정되며, 느린 작업이 모두 프로파일링된다는 의미입니다. sampleRate0에서 1 사이로 설정하면 프로파일링 수준이 1인 데이터베이스는 sampleRate에 따라 느린 작업의 무작위로 샘플링된 비율만 프로파일링합니다.

다음 예에서는 현재 연결된 데이터베이스의 프로파일링 수준을 1로 설정하고, 모든 느린 작업의 42%를 샘플링하도록 프로파일러를 설정합니다.

db.setProfilingLevel( 1, { sampleRate: 0.42 } )

수정된 샘플링 속도 값은 시스템 로그에도 적용됩니다.

db.setProfilingLevel()을 사용하여 mongosslowmssampleRate를 구성할 수 있습니다. mongos의 경우 slowmssampleRate 설정은 mongos에서 프로파일링을 사용할 수 없으므로 진단 로그에만 영향을 미치고 프로파일러에는 영향을 미치지 않습니다. [1]

예를 들어 다음은 느린 작업 기록을 위한 mongos 인스턴스의 샘플링 속도를 설정합니다.

db.setProfilingLevel( 0, { sampleRate: 0.42 } )

중요

logLevel0으로 설정하면, MongoDB는 slowOpSampleRate 의해 결정되는 속도로 느린 작업을 진단 로그에 기록합니다.

logLevel 설정이 높으면 지연 시간에 관계없이 모든 작업이 진단 로그에 표시되지만, 세컨더리에 의한 느린 oplog 항목 메시지 로깅은 예외입니다. 세컨더리는 느린 oplog 항목만 기록합니다. logLevel 를 늘려도 모든 oplog 항목이 기록되지는 않습니다.

[1](1, 2) 데이터베이스 프로파일링 및 샤딩을 참조하세요.

필터를 설정하여 프로파일링 및 기록된 작업을 관리할 수 있습니다. 다음 중 한 가지 방법으로 프로파일링 필터를 설정할 수 있습니다.

mongod 인스턴스의 경우 filter 는 진단 로그 및 활성화된 경우 프로파일러에 모두 영향을 줍니다.

mongos 인스턴스의 경우 mongos에서 프로파일링을 사용할 수 없으므로 filter는 프로진단파일러가 아닌 로그에만 영향을 미칩니다.

참고

프로파일링 filter가 설정되었다면, slowmssampleRate 옵션이 진단 로그나 프로파일러에 영향을 미치지 않습니다.

다음 db.setProfilingLevel() 예시에서는 현재 연결된 데이터베이스에 대한 프로필 수준을 설정합니다.

  • 프로파일링 수준2로 설정합니다.

  • 프로파일러가 소요 시간이 2초를 초과하는 query 작업만 기록하도록 하는 { op: "query", millis: { $gt: 2000 } } 필터

db.setProfilingLevel( 2, { filter: { op: "query", millis: { $gt: 2000 } } } )

프로파일링 수준 을 보려면 mongosh에서 다음 예제를 실행합니다.

db.getProfilingStatus()

셸은 다음과 유사한 문서를 반환합니다.

{ "was" : 0, "slowms" : 100, "sampleRate" : 1.0, "ok" : 1 }

was 필드는 현재 프로파일링 수준을 나타냅니다.

slowms 필드는 작업 시간 임계값(밀리초)을 나타내며, 이를 초과하면 느린 작업으로 간주됩니다.

sampleRate 필드는 프로파일링이 필요한 느린 작업의 비율을 나타냅니다.

프로파일링을 비활성화하려면 mongosh에서 다음 예시를 실행합니다.

db.setProfilingLevel(0)

참고

프로파일링을 비활성화하면 데이터베이스 성능이 향상되고 디스크 사용량이 줄어들 수 있습니다. 자세한 내용은 데이터베이스 프로파일러 오버헤드 를 참조하세요.

개발 및 테스트 환경의 경우, 전체 mongod 인스턴스에 대해 데이터베이스 프로파일링을 활성화할 수 있습니다. 프로파일링 수준은 mongod 인스턴스에서 제공하는 모든 데이터베이스에 적용됩니다.

mongod 인스턴스에 대한 프로파일링을 활성화하려면 시작 시 다음 옵션을 mongod로 전달합니다.

mongod --profile 1 --slowms 15 --slowOpSampleRate 0.5

또는 구성 파일에서 operationProfiling을 지정할 수 있습니다.

이를 통해 프로파일링 수준을 1으로 설정하고, 15밀리초보다 오래 지속되는 작업을 느린 작업으로 정의하며, 느린 작업의 50%만 프로파일링하도록 지정합니다. [2]

logLevel0로 설정된 경우 slowmsslowOpSampleRate는 진단 로그에 기록되는 작업에도 영향을 줍니다. slowmsslowOpSampleRatemongos의 진단 로그 구성에도 사용할 수 있습니다. [2]

다음도 참조하세요.

mongos 인스턴스에서는 프로파일링을 활성화할 수 없습니다 . 샤드 클러스터에서 프로파일링을 활성화하려면 클러스터의 각 mongod 인스턴스에 프로파일링을 활성화해야 합니다.

그러나 MongoDB 4.0부터는 mongos에서 --slowmsslowOpSampleRate를 설정하여 느린 작업에 대한 진단 로그를 구성할 수 있습니다.

데이터베이스 프로파일러는 system.profile 컬렉션의 데이터베이스 작업에 대한 정보를 기록합니다.

프로파일링 정보를 보려면 system.profile 컬렉션을 쿼리합니다. 예제 쿼리를 보려면 프로파일러 데이터 쿼리 예제 를 참조하세요. 출력 데이터에 대한 설명은 데이터베이스 프로파일러 출력을 참조하세요.

더 이상 트랜잭션 내에서 collection system.profile에 대해 읽기를 포함한 어떤 작업도 수행할 수 없습니다.

$comment를 사용하여 쿼리 조건자에 데이터를 추가하면 프로파일러에서 데이터를 더욱 쉽게 분석할 수 있습니다.

이 섹션에서는 system.profile 컬렉션에 대한 쿼리 예시를 보여 줍니다. 쿼리 출력 세부 정보는 데이터베이스 프로파일러 출력을 참조하세요.

system.profile 컬렉션에서 가장 최근 로그 항목 10개를 반환하려면 아래와 유사한 쿼리를 실행합니다:

db.system.profile.find().limit(10).sort( { ts : -1 } ).pretty()

명령 작업($cmd)을 제외한 모든 작업을 반환하려면 아래와 유사한 쿼리를 실행합니다.

db.system.profile.find( { op: { $ne : 'command' } } ).pretty()

특정 컬렉션에 대한 작업을 반환하려면 아래와 유사한 쿼리를 실행합니다. 이 예시에서는 mydb 데이터베이스의 test 컬렉션에 있는 작업을 반환합니다.

db.system.profile.find( { ns : 'mydb.test' } ).pretty()

완료하는 데 5밀리초 이상 걸리는 작업을 반환하려면 다음을 실행하세요.

db.system.profile.find( { millis : { $gt : 5 } } ).pretty()

특정 시간 범위에 대한 작업을 반환하려면 다음을 실행하세요.

db.system.profile.find( {
ts : {
$gt: new ISODate("2012-12-09T03:00:00Z"),
$lt: new ISODate("2012-12-09T03:40:00Z")
}
} ).pretty()

다음 예시는 시간 범위를 살펴보고, 읽기 쉽도록 출력에서 user 필드를 제거하며, 각 연산을 실행하는 데 걸린 시간을 기준으로 결과를 정렬합니다.

db.system.profile.find( {
ts : {
$gt: new ISODate("2011-07-12T03:00:00Z"),
$lt: new ISODate("2011-07-12T03:40:00Z")
}
}, { user: 0 } ).sort( { millis: -1 } )

프로파일링이 활성화된 데이터베이스에서 mongoshshow profile 헬퍼는 실행하는 데 1 밀리초 이상 소요된 가장 최근 작업 5 를 표시합니다. mongosh }에서 show profile 를 실행합니다.

show profile

프로파일링을 활성화하면 특히 프로파일링 수준 이 2 으로 구성되거나 프로파일링 수준이 1 인 낮은 임계 값을 사용하는 경우 데이터베이스 성능에 영향을 미칩니다.

프로파일링은 system.profile 컬렉션과 MongoDB logfile에 로그를 쓰기 때문에 프로파일링은 디스크 공간도 사용합니다.

경고

프로덕션 배포에서 프로파일러를 활성화하기 전에 성능과 저장소에 미치는 영향을 고려하세요.

system.profile 컬렉션은 기본 크기가 1메가바이트인 고정 사이즈 컬렉션입니다. 이 정도 크기의 컬렉션에는 일반적으로 수천 개의 프로파일 문서를 저장할 수 있지만, 일부 애플리케이션은 작업당 프로파일링 데이터를 더 많이 사용하거나 더 적게 사용할 수 있습니다. 아래 단계에 따라 system.profile 컬렉션의 크기를 변경할 수 있습니다.

프라이머리에서 system.profile 컬렉션 크기를 변경하려면 다음을 실행합니다.

  1. 프로파일링을 비활성화합니다.

  2. system.profile 컬렉션을 삭제합니다.

  3. system.profile 컬렉션을 만듭니다.

  4. 프로파일링을 다시 활성화합니다.

예를 들어 4000000 바이트(4 MB)인 새 system.profile 컬렉션을 만들려면 mongosh에서 다음 작업 시퀀스를 사용합니다.

db.setProfilingLevel(0)
db.system.profile.drop()
db.createCollection( "system.profile", { capped: true, size:4000000 } )
db.setProfilingLevel(1)

세컨더리에서 system.profile 컬렉션의 크기를 변경하려면 세컨더리를 중지하고 독립형으로 실행한 다음 위의 단계를 수행합니다. 완료되면 복제본 세트의 멤버로 독립형을 다시 시작합니다. 자세한 내용은 복제본 세트 멤버의 유지 관리 수행에서 확인 가능합니다.

[2](1, 2, 3) 버전 4.2부터 복제본 세트의 세컨더리 멤버는 느린 작업 임계값보다 오래 걸리는 oplog 항목을 기록합니다. 이러한 느린 oplog 메시지의 특성은 다음과 같습니다.
  • diagnostic log에 세컨더리 멤버에 대해 기록합니다.
  • applied op: <oplog entry> took <num>ms 텍스트와 함께 REPL 구성 요소 아래에 기록됩니다.
  • 로그 수준(시스템 또는 구성 요소 수준)에 의존하지 않습니다.
  • 프로파일링 수준에 의존하지 않습니다.
  • slowOpSampleRate 의 영향을 받습니다.
프로파일러는 느린 oplog 항목을 캡처하지 않습니다.
← Explain Plan 결과 해석