MongoDB Performance Counters

An open-source, document-oriented NoSQL database system is called MongoDB. Instead of using a conventional relational database, this sort of database stores data in a group of documents. MongoDB is made to be quick, scalable, and high availability. Additionally, it offers a robust query language that enables developers to quickly and effectively query their data.

Mongo DB is a distributed database system that employs a cluster of computers to store information. This distributed architecture brings several benefits, including improved performance and scalability. By distributing data across multiple servers, MongoDB can handle large datasets and achieve horizontal scaling, enhancing its ability to handle increased workloads and maintain optimal performance.

Additionally, MongoDB’s replication feature simplifies data redundancy and availability. Through data replication across multiple servers, MongoDB ensures that data remains accessible and backed up even in the event of server failures. This replication mechanism contributes to high availability and fault tolerance, ensuring that data remains consistently available to users.

An open-source NoSQL database is MongoDB. It is a distributed, non-relational document-oriented database that stores data as key-value pairs. The document-oriented database MongoDB enables users to store their data as documents. Because of this, MongoDB is more adaptable than conventional relational databases, which store data in tables and rows.

Replication, sharding, and indexing are just a few of the built-in capabilities that make MongoDB superior to competing databases. Even if a node fails, replication makes sure that data is always accessible. Sharding enhances performance and scalability by distributing data over numerous nodes. Faster searches are made possible by indexing since it makes it easier to store and retrieve data.

Additional built-in security measures offered by MongoDB include authentication and authorization. While permission grants access control to specific records and documents, authentication ensures that only authorized users can access the database. This ensures the privacy and security of data.

Overall, MongoDB is a great option for programmers and companies who require a versatile, scalable, and powerful database system. It is a wonderful option for applications that need to quickly and effectively store and query massive amounts of data. To manage their data and enhance their apps, developers can take advantage of a great variety of capabilities and tools offered by MongoDB.

Key Features of MongoDB

  1. Flexible Data Modeling: MongoDB’s flexible data modeling feature enables programmers to store data in a wide range of formats, including JSON, BSON, and even plain text.
  2. High Performance: The read and write speeds of MongoDB are renowned for being incredibly fast.
  3. Simple Scalability: MongoDB is easily scaleable, making it possible to use it to manage both modest and big volumes of data.
  4. High Availability: MongoDB’s replication and sharding features provide high availability.
  5. Security: Security features offered by MongoDB include encryption, role-based access control, and authentication.

NoSQL database
A form of database known as NoSQL (Not Only SQL) is not structured in the same manner as a conventional relational database. NoSQL databases are frequently used for storing and retrieving big collections of distributed data, and they are particularly helpful for applications that need quick access to sizable data sets. Instead of using rigid table schemas like traditional relational databases do, NoSQL databases store data in flexible documents, graphs, key-value pairs, and columns. For distributed systems that need speedy, real-time access to massive amounts of data, NoSQL databases are frequently used. They are also helpful for applications like web applications that need high availability and scalability.

MongoDB performance counters

Database
  1. Memory
    • Disk-space: “Disc space” refers to the combined size of the database’s files, which includes both the database’s data files and namespace files.
    • Index -size: “Index size” refers to the overall size of all indexes built for this database.
    • data-size: “Data size” refers to the entire amount of data stored in this database, including the padding factor.
    • storage-size: “Storage size” refers to the overall volume of space allotted to collections in this database for the purpose of storing documents.
  2. Locks
    • Write: Only for MongoDB 2. x versions, the “Write lock%” field displays the percentage of time the database has held the write lock.
    • Read: For versions of MongoDB 2. x only, the “Read lock%” field displays the percentage of time the database has held the read lock.
  3. Page-Fault
    • not-in-memory: The “Accesses not in memory” statistic represents the number of times per second that a memory page for the database was not kept in memory (only for MongoDB 2. x versions).
    • Exceptions: For versions of MongoDB 2. x, “Page fault exceptions thrown” refers to the volume of page fault exceptions that are thrown each second when accessing database data.
  4. Slow operations
    The list of “slow operations” is created at the conclusion of the test and contains the slowest operations that took place. These database-specific operations are the slowest. What is considered a slow operation according to the MongoDB server profiling configuration?
    • Date: The day that the procedure was slow.
    • Action: The kind of action. “Insert,” “query,” “update,” “remove,” “get more,” and “command” are among the available values.
    • Collection: The collection that the operation is intended to affect (it could be empty for “command” operations).
    • Query: The query document that was used (only specified in a “query” operation).
    • Command: The command action (only mentioned when a “command” action is taken).
    • Update-object: The updated document that was provided during an “update” procedure is the update-object.
    • Duration: The amount of time, in milliseconds, that the server needs to complete the task. Network wait times and lock acquisition times are not included in this time.

Operations

  1. Total data: operations per second, or data. total. The “insert,” “query,” “update,” “delete,” and “get more” actions are added to produce this sum.
  2. Overall: Overall activities. The sum of the number of data operations per second and the number of command operations per second is the total number of operations per second.
  3. Insert: “Insert operations” gives you a counter for how many “insert” operations there are overall every second.
  4. The tally for total queries per second is provided by “Query operations”.
  5. Update: “Update operations” gives the total number of “update” operations that are performed each second.
  6. Delete The phrase “Delete operations” gives the total number of “delete” operations per second as a counter.
  7. get-more: “GetMore operations” gives a count of all “get more” operations that are performed each second.
  8. Command: “Command operations” gives you a tally of how many “command” operations there are overall every second.

Errors

  1. Total: “Total errors” is the sum of all assertions that were raised in that second (including “regular” plus “warning” plus “message” plus “user” plus “rollover”).
  2. Regular: “Regular error” counts the regular assertions (errors) made each second.
  3. Warning: “Warning errors” keeps track of how many warnings are issued each second.
  4. Message: “Message errors” keeps track of the number of assertions and message errors made per second.
  5. User: “User errors” keeps track of how many user assertions (mistakes) happen each second.
  6. Rollover: “Rollover errors” shows how often the rollover counts are rolling over each second.

Memory

  1. Resident: The value of “Resident” roughly corresponds to how many megabytes of RAM are currently being used by the database process. This value tends to increase during normal use. This figure frequently approaches the complete amount of system RAM in dedicated database servers.
  2. Virtual: “Virtual” shows the amount of virtual memory used, in megabytes. The value of virtual is at least twice as high as the value of mapped when journaling is enabled.
  3. Mapped: The value of “Mapped” gives the database’s total amount of mapped memory, expressed in megabytes. This value is probably to be about similar to the overall size of your database or databases because MongoDB employs memory-mapped files.
  4. Mapped-with-journal: “Mapped with the journal” gives the total amount of mapped memory, measured in megabytes, which includes journaling memory. This value will always be double what it was when it was mapped. Only when journaling is enabled is this field included?
  5. non-mapped: “Non-mapped” gives the database’s non-mapped memory size, in MB. The distinction between virtual and mapped memory (or mapped memory with journal memory if journaling is enabled) is “non-mapped”.
  6. Disk space: The overall size of the files used to store databases is referred to as “disc space” and is comprised of both the data files and namespace files for all databases.
  7. Index size: “Index size” refers to the combined size of all indexes established across all databases.
  8. data-size: “Data size” refers to the overall amount of data stored across all databases, including the padding factor.
  9. Storage size: The entire amount of space allotted to collections across all databases for document storage is referred to as “storage size”.

Locks

  1. Write: For 2. x MongoDB versions only, the “Write lock%” column displays the percentage of time that all databases have had the global write lock.
  2. Read: For 2. x MongoDB versions only, the “Read lock%” column displays the percentage of time that each database has had the global read lock.

Index

  1. Accesses: “Accesses” shows how frequently operations access indexes each second. The sum of the hits and misses makes up this value. Higher numbers imply the presence of indexes in your database and the use of these indexes by queries. If this figure doesn’t increase over time, it’s possible that your indexes aren’t properly supporting your use.
  2. Hits: The “Hits” value displays how frequently an index is accessed and returned from memory each second.
  3. Misses: The “Misses” value indicates the frequency with which an operation attempted to access an index that was not in memory. These misses represent an ineffective usage of the index rather than a failed operation or query. Higher index use and perhaps higher overall performance are indicated by lower values in this category.
  4. miss-ratio: The percentage ratio of “hits” to “misses” misses is represented by the “MissRatio” number.

Queue

  1. Percentage: In terms of a percentage, “Queue%” represents the proportion of “operations queued” to “total data operations”.
  2. Total: The total number of current operations that are queued up and waiting for the lock is provided by the value of “Queue”.
  3. Writers: The number of operations that are now in the “Writers queue” and awaiting the write-lock is the value of this field. A continuously small write queue is not a cause for concern, especially for shorter operations.
  4. Readers: The number of operations in the “Readers queue” value queued up and awaiting the read-lock. A constantly small read queue shouldn’t raise any issues, especially for shorter operations.

Flushing. (only for MMAPv1 Storage Engine)

  1. average-duration: The value for “Flushing average duration” explains how the number of flushes and the overall length of time the database has spent writing data to disc relate to one another. The likelihood that this result represents a “normal” duration increases with the size of the stream; nonetheless, anomalous data can skew this value. To make sure that a high average is not distorted by a temporary historical issue or a random write distribution, use the “Last duration” field.
  2. last-duration: The value of the “Flushing last duration” column represents the time, in milliseconds, required to perform the most recent flush operation.

Connections

The total number of active client connections to the database is represented by the value of “Total active connections”. This mixes clients that are engaged in reading activities (for example, “Readers”) with clients that are engaged in writing operations (for example, “Writers”).

  1. Readers: A count of the active client connections carrying out read operations is contained in the value of “Reader connections”.
  2. Writers: The number of active client connections executing write operations is contained in the value of “Writer connections”.

Cursors

  1. Opened: “Total opened” shows how many MongoDB cursors are kept open for users. Due to MongoDB’s exhaustion of unused cursors, this number is often minimal or nil. However, this value may increase if there is a queue, stale available cursors, or a high volume of operations.
  2. timed-out: “Timed out cursors” displays a counter of how many cursors time out overall every second. This number may point to an application fault if it is high or growing steadily.

Networks

  1. bytes-in: The value of the “KBytes in” field represents the volume of network traffic that this database has received, expressed in kilobytes per second.
  2. bytes-out: The value of the “KBytes out” field represents the volume of network traffic that this database sends out, in kbytes per second.
  3. Requests: The “Number of Network Requests” feature keeps track of all the different requests that the server has got.

Page Faults

  1. System number: The total number of page faults that demand disc operations is shown in the “System page faults” box. Operations that call for the database server to access data that is not present in active memory are referred to as system page faults. When performance suffers, the “System page faults” counter may spike substantially, and it may also be related to memory constraints and larger data sets. Limited and irregular page defects may not always signify a problem.
  2. Accesses-not-in-memory: “Accesses not in memory” measures the number of times per second for all databases (but just for 2. x MongoDB versions) that a memory page was not kept in memory.
  3. Accesses-not-in-memory-ratio: The “Not In Memory Accesses %” metric (for MongoDB 2. x versions only) represents the ratio of “Not In Memory Accesses” to “Total Data Operations”.
  4. Exception: when accessing data from all databases, the number of page fault exceptions thrown every second is indicated by the “Page Fault Exceptions Thrown” exception (for MongoDB 2. x versions only).

Journaling

  1. Write Lock Acks: “Write Lock Acks” lists the acknowledgments that occurred per second that a write lock was held. Captures a write hang point on a MongoDB server that is experiencing a high write load and requires further investigation.
  2. Logged Size: “Logged Size” indicates how many megabytes of data were logged during the most recent log group commit period.
  3. Data File Writes: “Data File Write Size” shows how much information was transferred from the journal to the data files during the most recent journal group commit interval in megabytes.

Replications

  1. lag: “Replication Lag” is the amount of time, measured in milliseconds, between when an action occurs on the primary and when it is applied to the secondary.
  2. Max-lag: “Maximum Replication Lag” is the maximum amount of time, in milliseconds, that can elapse between when an action occurs on the primary server and when it is applied on one of the secondary servers.
  3. Oplog Length: The oplog (operation log) is a unique and limited collection that keeps a running log of all operations that change the data stored in your databases. After performing database operations on the main, MongoDB logs them to the main operations log. last but not least, the “oplog length” refers to the amount of time that separates the first and last timestamp operation on the “oplog”; this period is measured in hours.
  4. Maximum Operation Log Size: “Maximum Operation Log Size” refers to the maximum operation log size specified by the MongoDB server in megabytes.
  5. Used-oplog-size: The term “Used Oplog Size” refers to the size of the used Oplog in megabytes.
  6. Free Login Size: In megabytes, the Free Login Size is equal to “Maximum Login Size” minus “Used Login Size”.
Scroll to Top