이 페이지에서는 백업을 활성화한 모든 프로젝트에 대해 작업별 키 크기 및 처리량 통계를 제공합니다.
Ops Manager는 두 테이블 Per Job 및 Per Project 에 다음 정보 목록을 표시합니다.
열 제목 | 콘텐츠 |
|---|---|
Oplog 수신(지난 24시간) | 지난 24시간 동안의 oplog 처리량에 대한 통계를 표시합니다. |
Oplog 애플리케이션(지난 24시간) | 지난 24시간 동안의 oplog 처리에 대한 통계를 표시합니다. |
SnapshotStore 사용량 | 다음 정보를 표시합니다.
리소스 추적 작업 은 이러한 통계를 수집합니다. |
참고
여러 백업 작업에서 동일한 스냅샷 저장소를 사용합니다.
이 정보를 내보내려면 Export as CSV 을 클릭합니다.
View Job Resource Usage Details
Click the job name in the Job column of the Per Job table to view time-series resource usage graphs for that job. Ops Manager displays the following graphs:
Network Usage
Data Blocks Throughput (WTC)
Data Blocks Request Latency (WTC)
Writing Blocks Latency Details (WTC)
CPU 사용량
Disk (HEAD) Usage
SnapshotStore Usage
The (WTC) graphs apply to WiredTiger checkpoint-based backups.
참고
Most graphs on this page require you to enable Resource Usage on the Backup Daemon. The Data Blocks Throughput, Data Blocks Request Latency, and Writing Blocks Latency Details graphs are an exception. Ops Manager collects this data automatically for jobs that use backup cursors.
Network Usage
This graph shows the throughput of oplog data that Ops Manager receives from the MongoDB Agent for this backup job, measured in bits per second. It plots two series:
Oplog data received during ongoing replication
Data received during the initial sync of the backup job, if an initial sync is in progress
Use this graph to identify network throughput bottlenecks. If the throughput drops, the MongoDB Agent might be struggling to send oplog data to Ops Manager.
Data Blocks Throughput (WTC)
This graph applies to backup jobs that use backup cursors to create snapshots. It shows the throughput, in bytes per second, of data blocks at three stages of processing:
계열 | 설명 |
|---|---|
Network Throughput | The rate at which Ops Manager receives data blocks over the network from the MongoDB Agent. |
Snapshot Storage Throughput | The rate at which Ops Manager writes data blocks to the snapshot store. |
Snapshot Throughput | The overall throughput of the snapshot, including any idle time between requests. This value is typically lower than the other two series. |
Compare the three series to identify where a slowdown originates. If Network Throughput is low, the connection between the MongoDB Agent and Ops Manager might be the bottleneck. If Snapshot Storage Throughput is low, the snapshot store might be slow to write data.
Data Blocks Request Latency (WTC)
This graph applies to backup jobs that use backup cursors to create snapshots. It shows the average time (in milliseconds) that each request to upload a data block spends in the following phases:
Reading incoming data from the network
Awaiting the completion of block writes to the snapshot store
Updating block metadata
Use this graph to isolate which phase of the upload request is slow. Consistently high values in one phase point to the specific component that is limiting backup throughput, such as the network or the snapshot store.
Writing Blocks Latency Details (WTC)
This graph applies to backup jobs that use backup cursors to create snapshots. It provides a more granular, per-block breakdown of the storage phase than the Data Blocks Request Latency (WTC) graph. It shows the average time spent on each of the following operations:
Checking whether a block already exists in the snapshot store
Compressing a block
Writing a block to the snapshot store
Writing block metadata
Use this graph to pinpoint whether compression, snapshot store writes, or metadata updates are the source of slow backups.
CPU 사용량
참고
Despite its name, this graph does not measure CPU usage. It measures the throughput of the Backup Daemon's oplog application process and related page faults.
This graph shows two series. The first is the rate, in KB per second, at which the Backup Daemon applies oplog entries to keep the backup current. The second is the rate of page faults per second during that process.
Use this graph to evaluate whether the daemon is keeping pace with incoming oplog data. If applied throughput drops while the Network Usage graph shows steady incoming data, the daemon might be falling behind. A high page fault rate can indicate that the backed-up data does not fit in available memory, causing disk I/O.
참고
For backup jobs that use backup cursors, this graph might be absent or show no data.
Disk (HEAD) Usage
참고
The label on this graph is legacy terminology. For backup jobs that use backup cursors, Ops Manager has no local head database. The graph instead reflects size statistics for the source database that you are backing up.
This graph shows the data size, storage size, and file size of the database being backed up. Ops Manager adds one data point each time a snapshot completes.
Use this graph to track database growth over time and to plan backup storage capacity.
SnapshotStore Usage
This graph shows the storage that snapshots for this backup job consume in the snapshot store over time, split into the following series:
Live bytes, which are referenced by currently active snapshots
Dead bytes, which belong to deleted snapshots that a groom job has not yet removed
Total bytes, which is the sum of the live and dead series
Use this graph to track storage growth. It also helps you identify when dead bytes accumulate faster than the Resource Tracking job reclaims them. Ops Manager updates this graph periodically rather than continuously, so recent changes might not appear immediately.