MongoDB Performance Counters

MongoDB is a distributed database, meaning that data is stored across multiple machines in a cluster. This provides many benefits, such as increased scalability and performance. It also makes it easy to replicate data across multiple servers, ensuring that data is always available and backed up. MongoDB also provides a high level of flexibility, allowing developers to store data in a variety of formats and structures.

MongoDB also provides powerful indexing capabilities. Indexes allow developers to quickly query data and find the information they need. This makes MongoDB a great choice for applications that need to quickly query large amounts of data. MongoDB also provides a variety of tools to help developers manage and monitor their data, such as the MongoDB Management Service.

MongoDB is an open-source, NoSQL database. It is a document-oriented, distributed, and non-relational database that stores data in the form of key-value pairs. MongoDB is a document-oriented database, which allows users to store their data in the form of documents. This makes MongoDB more flexible than traditional relational databases, where data is stored in tables and rows.

MongoDB is also chosen over other databases because of its built-in features, such as replication, sharding, and indexing. Replication ensures that data is always available even if a node fails. Sharding allows data to be distributed across multiple nodes, which improves performance and scalability. Indexing allows for faster searches, as the data can be indexed and retrieved quickly.

MongoDB also provides built-in security features, such as authentication and authorization. Authentication ensures that only authorized users can access the database, while authorization provides access control to individual records and documents. This ensures data security and privacy.

Overall, MongoDB is an excellent choice for developers and businesses that need a flexible, scalable, and powerful database system. It is a great choice for applications that need to store and query large amounts of data quickly and efficiently. MongoDB provides a great set of features and tools to help developers manage their data and optimize their applications.

Key Features of MongoDB

1. Flexible Data Modeling: MongoDB allows developers to store data in a variety of different formats, including JSON, BSON, and even plain text.
2. High Performance: MongoDB is known for its extremely fast read and write speeds.
3. Easy Scalability: MongoDB allows for easy scalability, meaning that it can be used to handle small or large amounts of data.
4. High Availability: MongoDB offers high availability through its replication and sharding capabilities.
5. Security: MongoDB provides several security features such as authentication, role-based access control, and encryption.

NoSQL DB

NoSQL (Not only SQL) is a type of database that is not structured in the same way as a traditional relational database. NoSQL databases are often used for storing and retrieving large sets of distributed data and are especially useful for applications that require quick access to large amounts of data. Unlike traditional relational databases, NoSQL databases do not use fixed table schemas, and instead store data in flexible documents, graphs, key-value pairs, and columns. NoSQL databases are often used for distributed systems that require quick, real-time access to large amounts of data. They are also useful for applications that require scalability and high availability, such as web applications.

Performance Counters of MongoDB

Database

1. Memory
   • disk-space: “Disk space” is the total size of the files that hold the database (is equal to the data files + namespace files for the database).
   • index-size: “Index size” is the total size of all indexes created on this database.
   • data-size: “Data size” is the total size of the data held in this database including the padding factor.
   • storage-size: “Storage size” is the total amount of space allocated to collections in this database for document storage.
2. Locks
   • write: The “Write lock %” reports the percentage of time that the database has held the database write lock (only for 2.x MongoDB versions).
   • read: The “Read lock %” reports the percentage of time that the database has held the database read lock (only for 2.x MongoDB versions).
3. Page-Fault
   • not-in-memory: The “Accesses not in memory” is the number of times per second an access to a memory page was not resident in memory for the database (only for 2.x MongoDB versions).
   • exceptions: The “Page fault exceptions thrown” is the number of page fault exceptions thrown per second (when accessing data for the database) (only for 2.x MongoDB versions).
4. Slow-Operation: “Slow operations” is a list of the slowest operations which occurred during the test (this list is populated at the end of the test). These slowest operations are per database. The MongoDB server profiling configuration defines what a slow operation is:
   • date: The date of the slow operation.
   • operation: The type of operation. The possible values are: “insert”, “query”, “update”, “remove”, “getmore” and “command”.
   • collection: The collection the operation targets (can be empty in case of a “command” operation).
   • query: The query document used (only specified in case of a “query” operation).
   • command: The command operation (only specified in case of a “command” operation).
   • update-object: The update document passed in during an “update” operation.
   • duration: The time in milliseconds for the server to perform the operation. This time does not include network time or time to acquire the lock.

Operations

1. data.total: The total number of data operations per second. This total is the addition of “insert”, “query”, “update”, “delete”, and “get more” operations.
2. total: Total operations. This total operations per seconds is the addition of the number of data operations per second and the number of command operations per second.
3. insert: “Insert operations” provides a counter of the total number of “insert” operations per second.
4. query: “Query operations” provides a counter of the total number of queries per second.
5. update: “Update operations” provides a counter of the total number of “update” operations per second.
6. delete: “Delete operations” provides a counter of the total number of “delete” operations per second.
7. get-more: “GetMore operations” provides a counter of the total number of “getmore” operations per second.
8. command: “Command operations” provides a counter of the total number of “command” operations per second.

Errors

1. total: “Total errors” is the total of errors (assertions) raised per second ( “regular” + “warning” + “message” + “user” + “rollover”).
2. regular: “Regular error” tracks the number of regular errors (assertions) per second.
3. warning: “Warning errors” tracks the number of warnings per second.
4. message: “Message errors” tracks the number of message errors (assertions) per second.
5. user: “User errors” tracks the number of user errors (assertions) per second.
6. rollover: “Rollover errors” displays the number of times per second that the rollover counters have rolled over.

Memory

1. resident: The value of “Resident” is roughly equivalent to the amount of RAM, in megabytes, currently used by the database process. In normal use this value tends to grow. In dedicated database servers this number tends to approach the total amount of system memory.
2. virtual: “Virtual” displays the quantity, in megabytes, of virtual memory used. With journaling enabled, the value of virtual is at least twice the value of mapped.
3. mapped: The value of “Mapped” provides the amount of mapped memory, in megabytes, by the database. Because MongoDB uses memory-mapped files, this value is likely to be to be roughly equivalent to the total size of your database or databases.
4. mapped-with-journal: “Mapped with journal” provides the amount of mapped memory, in megabytes, including the memory used for journaling. This value will always be twice the value of mapped. This field is only included if journaling is enabled.
5. non-mapped: “Non mapped” provides the amount of non-mapped memory, in megabytes, by the database. “Non mapped” is the difference between virtual and mapped memory (or mapped with journal memory in case journaling is enabled).
6. disk-space: “Disk space” is the total size of the files that hold the databases (is equal to the data files + namespace files for all the databases).
7. index-size: “Index size” is the total size of all indexes created on all databases.
8. data-size: “Data size” is the total size of the data held in all databases including the padding factor.
9. storage-size: “Storage size” is the total amount of space allocated to collections in all databases for document storage.

Locks

1. write: The “Write lock %” reports the percentage of time that all databases have held the global write lock (only for 2.x MongoDB versions).
2. read: The “Read lock %” reports the percentage of time that all databases have held the global read lock (only for 2.x MongoDB versions).

Index

1. accesses: “Accesses” reports the number of times per second that operations have accessed indexes. This value is the combination of the hits and misses. Higher values indicate that your database has indexes and that queries are taking advantage of these indexes. If this number does not grow over time, this might indicate that your indexes do not effectively support your use.
2. hits: The “Hits” value reflects the number of times per second that an index has been accessed and returned from memory.
3. misses: The “Misses” value represents the number of times per second that an operation attempted to access an index that was not in memory. These misses do not indicate a failed query or operation, but rather an inefficient use of the index. Lower values in this field indicate better index use and likely overall performance as well.
4. miss-ratio: The “MissRatio” value is the percentage ratio of “hits” to “misses” misses.

Queue

1. percentage: “Queue %” is the percentage of the percentage ratio of “operations queued” to “total data operations”.
2. total: The value of “Queue” provides the combined total of current operations queued waiting for the lock.
3. writers: The value of “Writers queue” is the number of operations that are currently queued and waiting for the write-lock. A consistently small write-queue, particularly of shorter operations is no cause for concern.
4. readers: The value of “Readers queue” is the number of operations that are currently queued and waiting for the read-lock. A consistently small read-queue, particularly of shorter operations should cause no concern.

flushing. (only for MMAPv1 Storage Engine)

1. average-duration: The “Flushing average duration” value describes the relationship between the number of flushes and the total amount of time that the database has spent writing data to disk. The larger flushes is, the more likely this value is likely to represent a “normal” time; however, abnormal data can skew this value. Use the “Last duration” to ensure that a high average is not skewed by transient historical issue or a random write distribution.
2. last-duration: The value of the “Flushing last duration” field is the amount of time, in milliseconds, that the last flush operation took to complete.

Connections

1. total: The value of “Total active connections” is the total number of active client connections to the database. This combines clients that are performing read operations (e.g. “Readers”) and clients that are performing write operations (e.g. “Writers”).
2. readers: The value of “Reader connections” contains a count of the active client connections performing read operations.
3. writers: The value of “Writer connections” contains a count of active client connections performing write operations.

Cursors

1. opened: “Total opened” provides the number of cursors that MongoDB is maintaining for clients. Because MongoDB exhausts unused cursors, typically this value small or zero. However, if there is a queue, stale tailable cursors, or a large number of operations this value may rise.
2. timed-out: “Timed out cursors” provides a counter of the total number of cursors that have timed out per second. If this number is large or growing at a regular rate, this may indicate an application error.

Network

1. bytes-in: The value of the “KBytes in” field reflects the amount of network traffic, in kbytes per second, received by this database.
2. bytes-out: The value of the “KBytes out” field reflects the amount of network traffic, in kbytes per second, sent from this database.
3. requests: The “Number of network requests” field is a counter of the total number of distinct requests that the server has received.

Page-Faults

1. system-number: The “System page faults” field reports the total number of page faults that require disk operations. System page faults refer to operations that require the database server to access data which is not available in active memory. The “System page faults” counter may increase dramatically during moments of poor performance and may correlate with limited memory environments and larger data sets. Limited and sporadic page faults do not necessarily indicate an issue.
2. accesses-not-in-memory: “Accesses not in memory” reflects the number of times per second a memory page was not resident in memory for all databases (only for 2.x MongoDB versions).
3. accesses-not-in-memory-ratio: The “Accesses not in memory %” value is the percentage ratio of “Accesses not in memory” to “Total data operations” (only for 2.x MongoDB versions).
4. exception: “Page fault exceptions thrown” reflects the number of page fault exceptions thrown per second when accessing data for all databases (only for 2.x MongoDB versions).

Journaling

1. write-lock-commits: “Commits in write lock” provides a count per second of the commits that occurred while a write lock was held. Commits in a write lock indicate a MongoDB server under a heavy write load and call for further diagnosis.
2. journaled-size: “Journaled size” provides the amount of data in megabytes written to journal during the last journal group commit interval.
3. write-to-data-files: “Written to data files size” provides the amount of data in megabytes written from journal to the data files during the last journal group commit interval.

Replications

1. lag: “Replication lag” is the delay in milliseconds between the time an operation occurs on the primary and the time that same operation gets applied on the secondary.
2. max-lag: “Max Replication lag” is the worst delay in milliseconds between the time an operation occurs on the primary and the time that same operation gets applied on one of the secondaries.
3. oplog-length: The oplog (operations log) is a special capped collection that keeps a rolling record of all operations that modify the data stored in your databases. MongoDB applies database operations on the primary and then records the operations on the primary oplog. Finally “Oplog length” corresponds to the difference between the first and the last timestamp operation in the “oplog”: this duration is in hours.
4. maximum-oplog-size: “Maximum oplog size” is the maximum size in megabytes of the oplog defined by the MongoDB server.
5. used-oplog-size: “Used oplog size” is the used oplog size in megabytes.
6. free-oplog-size: Free oplog size is equals to “Maximum oplog size” – “Used oplog size” (in megabytes).

---

---

You may be interested:

• Oracle DB Performance Counters
• DB2 Performance Counters