对于已启用备份的所有项目，此页面提供基于每个作业的密钥大小和吞吐量统计信息。
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.