On this page本页内容
As you develop and operate applications with MongoDB, you may need to analyze the performance of the application and its database.在使用MongoDB开发和操作应用程序时,可能需要分析应用程序及其数据库的性能。When you encounter degraded performance, it is often a function of database access strategies, hardware availability, and the number of open database connections.当您遇到性能下降时,这通常是数据库访问策略、硬件可用性和打开的数据库连接数的函数。
Some users may experience performance limitations as a result of inadequate or inappropriate indexing strategies, or as a consequence of poor schema design patterns.由于索引策略不充分或不适当,或者由于模式设计模式不佳,一些用户可能会遇到性能限制。Locking Performance discusses how these can impact MongoDB’s internal locking.锁定性能讨论了它们如何影响MongoDB的内部锁定。
Performance issues may indicate that the database is operating at capacity and that it is time to add additional capacity to the database.性能问题可能表明数据库正在满负荷运行,现在是向数据库添加额外容量的时候了。In particular, the application’s working set should fit in the available physical memory.特别是,应用程序的工作集应该适合可用的物理内存。
In some cases performance issues may be temporary and related to abnormal traffic load.在某些情况下,性能问题可能是暂时的,并与异常流量负载有关。As discussed in Number of Connections, scaling can help relax excessive traffic.正如在“连接数”中所讨论的,缩放有助于缓解过多的流量。
Database Profiling can help you to understand what operations are causing degradation.数据库分析可以帮助您了解导致降级的操作。
MongoDB uses a locking system to ensure data set consistency.MongoDB使用锁定系统来确保数据集的一致性。If certain operations are long-running or a queue forms, performance will degrade as requests and operations wait for the lock.如果某些操作是长时间运行的,或者形成了一个队列,那么当请求和操作等待锁定时,性能将下降。
Lock-related slowdowns can be intermittent.与锁相关的减速可能是间歇性的。To see if the lock has been affecting your performance, refer to the locks section and the globalLock section of the 要查看锁是否影响了您的性能,请参阅serverStatus
output.serverStatus
输出的locks部分和globalLock部分。
Dividing 将locks.timeAcquiringMicros
by locks.acquireWaitCount
can give an approximate average wait time for a particular lock mode.locks.timeAcquiringMicros
除以locks.acquireWaitCount
可以得出特定锁定模式的大致平均等待时间。
locks.deadlockCount
provide the number of times the lock acquisitions encountered deadlocks.locks.deadlockCount
提供锁获取遇到死锁的次数。
If 如果globalLock.currentQueue.total
is consistently high, then there is a chance that a large number of requests are waiting for a lock. This indicates a possible concurrency issue that may be affecting performance.globalLock.currentQueue.total
始终较高,则可能有大量请求正在等待锁定。这表明可能存在影响性能的并发问题。
If globalLock.totalTime
is high relative to uptime
, the database has existed in a lock state for a significant amount of time.
Long queries can result from ineffective use of indexes; non-optimal schema design; poor query structure; system architecture issues; or insufficient RAM resulting in disk reads.长查询可能是由于索引的无效使用造成的;非最优方案设计;查询结构差;系统架构问题;或RAM不足,导致磁盘读取。
In some cases, the number of connections between the applications and the database can overwhelm the ability of the server to handle requests. The following fields in the serverStatus
document can provide insight:
connections
is a container for the following two fields:connections.current
the total number of current clients connected to the database instance.connections.available
the total number of unused connections available for new clients.If there are numerous concurrent application requests, the database may have trouble keeping up with demand.如果存在多个并发应用程序请求,则数据库可能无法满足需求。If this is the case, then you will need to increase the capacity of your deployment.如果是这种情况,则需要增加部署的容量。
For read-heavy applications, increase the size of your replica set and distribute read operations to secondary members.
For write-heavy applications, deploy sharding and add one or more shards to a sharded cluster to distribute load among mongod
instances.
Spikes in the number of connections can also be the result of application or driver errors. All of the officially supported MongoDB drivers implement connection pooling, which allows clients to use and reuse connections more efficiently. An extremely high number of connections, particularly without corresponding workload, is often indicative of a driver or other configuration error.
Unless constrained by system-wide limits, the maximum number of incoming connections supported by MongoDB is configured with the maxIncomingConnections
setting. On Unix-based systems, system-wide limits can be modified using the ulimit
command, or by editing your system’s /etc/sysctl
file. See UNIX ulimit Settings for more information.
The Database Profiler collects detailed information about operations run against a mongod instance. The profiler’s output can help to identify inefficient queries and operations.
You can enable and configure profiling for individual databases or for all databases on a mongod
instance. Profiler settings affect only a single mongod
instance and will not propagate across a replica set or sharded cluster.
See Database Profiler for information on enabling and configuring the profiler.
The following profiling levels are available:以下配置级别可用:
Level | |
---|---|
0 |
|
1 |
slowms .slowms 值的操作收集数据。 |
2 |
Important
Profiling can impact performance and shares settings with the system log.分析可能会影响性能并与系统日志共享设置。Carefully consider any performance and security implications before configuring and enabling the profiler on a production deployment.在生产部署中配置和启用剖析器之前,仔细考虑任何性能和安全含义。
See Profiler Overhead for more information on potential performance degradation.有关潜在性能下降的更多信息,请参阅探查器开销。
Note
When logLevel
is set to 0
, MongoDB records slow
operations to the diagnostic log at a rate determined by slowOpSampleRate. Starting in MongoDB 4.2, the secondaries of replica sets log all oplog entry messages that take longer than the slow operation threshold to apply regardless of the sample rate.
At higher logLevel
settings, all operations appear in the diagnostic log regardless of their latency with the following exception: the logging of slow oplog entry messages by the secondaries. The secondaries log only the slow oplog entries; increasing the logLevel
does not log all oplog entries.
Starting in MongoDB 4.2, the profiler entries and the diagnostic log messages (i.e. mongod/mongos log messages) for read/write operations include:
queryHash
to help identify slow queries with the same query shape.queryHash
可以帮助识别具有相同查询形状的慢速查询。planCacheKey
to provide more insight into the query plan cache for slow queries.To facilitate analysis of the MongoDB server behavior by MongoDB Inc. engineers, mongod
and mongos
processes include a Full Time Diagnostic Data Collection (FTDC) mechanism. FTDC data files are compressed, are not human-readable, and inherit the same file access permissions as the MongoDB data files. Only users with access to FTDC data files can transmit the FTDC data. MongoDB Inc. engineers cannot access FTDC data independent of system owners or operators. MongoDB processes run with FTDC on by default. For more information on MongoDB Support options, visit Getting Started With MongoDB Support.
FTDC Privacy
FTDC data files are compressed and not human-readable.FTDC数据文件是压缩的,不可读。MongoDB Inc. engineers cannot access FTDC data without explicit permission and assistance from system owners or operators.没有系统所有者或运营商的明确许可和协助,MongoDB公司的工程师无法访问FTDC数据。
FTDC data never contains any of the following information:FTDC数据从不包含以下任何信息:
FTDC data contains certain host machine information such as hostnames, operating system information, and the options or settings used to start the mongod
or mongos
. This information may be considered protected or confidential by some organizations or regulatory bodies, but is not typically considered to be Personally Identifiable Information (PII). For clusters where these fields were configured with protected, confidential, or PII data, please notify MongoDB Inc. engineers before sending the FTDC data so appropriate measures can be taken.
FTDC periodically collects statistics produced by the following commands:FTDC定期收集由以下命令生成的统计信息:
serverStatus
replSetGetStatus
(mongod
only)collStats
for the local.oplog.rs
collection (mongod
only)connPoolStats
(mongos
only)Depending on the host operating system, the diagnostic data may include one or more of the following utilization statistics:根据主机操作系统的不同,诊断数据可能包括以下一个或多个利用率统计信息:
Note
Starting in MongoDB 4.4, if the mongod
process runs in a container, FTDC will report utilization statistics from the perspective of the container instead of the host operating system. For example, if a the mongod
runs in a container that is configured with RAM restrictions, FTDC will calculate memory utilization against the container’s RAM limit, as opposed to the host operating system’s total available RAM.
FTDC collects statistics produced by the following commands on file rotation or startup:FTDC在文件旋转或启动时收集由以下命令生成的统计信息:
mongod
processes store FTDC data files in a diagnostic.data
directory under the instances storage.dbPath
. All diagnostic data files are stored under this directory. For example, given a dbPath
of /data/db
, the diagnostic data directory would be /data/db/diagnostic.data
.
mongos
processes store FTDC data files in a diagnostic directory relative to the systemLog.path
log path setting. MongoDB truncates the logpath’s file extension and concatenates diagnostic.data
to the remaining name. For example, given a path
setting of /var/log/mongodb/mongos.log
, the diagnostic data directory would be /var/log/mongodb/mongos.diagnostic.data
.
FTDC runs with the following defaults:FTDC以以下默认值运行:
diagnostic.data
folder size.These defaults are designed to provide useful data to MongoDB Inc.这些默认设置旨在为MongoDB Inc.提供有用的数据。engineers with minimal impact on performance or storage size.对性能或存储大小影响最小的工程师。These values only require modifications if requested by MongoDB Inc. engineers for specific diagnostic purposes.仅当MongoDB Inc.工程师出于特定诊断目的提出要求时,才需要修改这些值。
You can view the FTDC source code on the MongoDB Github Repository. The ftdc_system_stats_*.ccp
files specifically define any system-specific diagnostic data captured.ftdc_system_stats_*.ccp
文件专门定义捕获的任何系统特定诊断数据。
To disable FTDC, start up the mongod
or mongos
with the diagnosticDataCollectionEnabled: false
option specified to the setParameter
setting in your configuration file:
Disabling FTDC may increase the time or resources required when analyzing or debugging issues with support from MongoDB Inc. engineers.在MongoDB 公司的工程师的支持下,禁用FTDC可能会增加分析或调试问题所需的时间或资源。