diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/_index.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/_index.md index 5bacfc1f0b..de5c91fb33 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/_index.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/_index.md @@ -7,19 +7,18 @@ cascade: minutes_to_complete: 30 -who_is_this_for: This Learning Path is designed for software developers looking to migrate their MongoDB workloads from x86_64 to Arm-based platforms, specifically on the Microsoft Azure Cobalt 100 processors. +who_is_this_for: This Learning Path is designed for software developers looking to migrate their MongoDB workloads to Arm-based platforms, specifically on the Microsoft Azure Cobalt 100 processors. learning_objectives: - - Provision an Azure Arm64 virtual machine using Azure console, with Ubuntu Pro 24.04 LTS as the base image. - - Deploy the MongoDB on an Azure ubuntu virtual machine. - - Perform MongoDB baseline testing and benchmarking on both x86_64 and Arm64 virtual machine. + - Provision an Azure Arm64 Cobalt 100 based virtual machine using Azure console, with Ubuntu Pro 24.04 LTS as the base image. + - Deploy MongoDB on an Azure Cobalt 100 based virtual machine. + - Perform MongoDB baseline testing and benchmarking on the Arm64 virtual machine. prerequisites: - A [Microsoft Azure](https://azure.microsoft.com/) account with access to Cobalt 100 based instances (Dpsv6). - - Basic understanding of Linux command line. - Familiarity with the [MongoDB architecture](https://www.mongodb.com/) and deployment practices on Arm64 platforms. -author: Jason Andrews +author: Pareena Verma ### Tags skilllevels: Introductory diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/baseline-testing.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/baseline-testing.md index 2a74624104..4b981f3286 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/baseline-testing.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/baseline-testing.md @@ -8,7 +8,7 @@ layout: learningpathall ### Baseline testing of MongoDB -Perform baseline testing by verifying MongoDB is running, logging into the shell, executing a few test queries, and monitoring live performance. This ensures the database is functioning correctly before starting any benchmarks. +In this section you will perform baseline testing by verifying MongoDB is running, logging into the shell, executing a few test queries, and monitoring live performance. This ensures the database is functioning correctly before starting any benchmarks. 1. Verify Installation & Service Health @@ -17,11 +17,12 @@ ps -ef | grep mongod mongod --version netstat -tulnp | grep 27017 ``` +An explanation of what each command is doing: - **ps -ef | grep mongod** – Checks if the MongoDB server process is running. - **mongod --version** – Shows the version of MongoDB installed. - **netstat -tulnp | grep 27017** – Checks if MongoDB is listening for connections on its default port 27017. -You should see an output similar to: +You should see output similar to: ```output mongod --version @@ -48,12 +49,12 @@ tcp 0 0 127.0.0.1:27017 0.0.0.0:* LISTEN 2. Storage and Health Check -Run the command below to check how fast your storage can **randomly read small 4KB chunks** from a 100 MB file for 30 seconds, using one job, and then show a summary report: +To perform a storage and health check, run the command below. This command checks how fast your storage can randomly read small 4KB chunks from a 100 MB file for 30 seconds, using one job, followed by a summary report: ```console fio --name=baseline --rw=randread --bs=4k --size=100M --numjobs=1 --time_based --runtime=30 --group_reporting ``` -You should see an output similar to: +You should see output similar to: ```output baseline: (g=0): rw=randread, bs=(R) 4096B-4096B, (W) 4096B-4096B, (T) 4096B-4096B, ioengine=psync, iodepth=1 @@ -91,6 +92,13 @@ The output shows how fast it read data (**16.6 MB/s**) and how many reads it did 3. Connectivity and CRUD Sanity Check +To verify that the MongoDB server is reachable you will perform a connectivity check. You will run a sanity test of core database functionality and permissions, refered to as CRUD: + +C - Create: Insert a new record/document into the database. +R - Read: Query the database to retrieve data. +U - Update: Modify an existing record. +D - Delete: Remove a record. + ```console mongosh --host localhost --port 27017 ``` @@ -107,7 +115,7 @@ exit ``` These commands create a test record, read it, update its value, and then delete it a simple way to check if MongoDB’s basic **add, read, update, and delete** operations are working. -You should see an output similar to: +You should see output similar to: ```output test> use baselineDB @@ -141,6 +149,8 @@ baselineDB> db.testCollection.deleteOne({ name: "baseline-check" }) 4. Basic Query Performance Test +You will now perform a lightweight query performance check: + ```console mongosh --eval ' db = db.getSiblingDB("baselineDB"); @@ -150,9 +160,9 @@ db.perf.find({ value: { $gt: 0.5 } }).count(); print("Query Time (ms):", new Date() - start); ' ``` -The command connected to MongoDB, switched to the **baselineDB** database, inserted **1,000 documents** into the perf collection, and then measured the execution time for counting documents where **value > 0.5**. The final output displayed the **query execution time** in milliseconds. +The command connected to MongoDB, switched to the `baselineDB` database, inserted 1,000 documents into the perf collection, and then measured the execution time for counting documents where value > 0.5. The final output displayed the query execution time in milliseconds. -You should see an output similar to: +You should see the Query Time output similar to: ```output Query Time (ms): 2 @@ -160,6 +170,7 @@ Query Time (ms): 2 5. Index Creation Speed Test +You will now run a performance sanity check that measures how long MongoDB takes to create an index on a given collection: ```console mongosh --eval ' db = db.getSiblingDB("baselineDB"); @@ -168,9 +179,9 @@ db.perf.createIndex({ value: 1 }); print("Index Creation Time (ms):", new Date() - start); ' ``` -The test connected to MongoDB, switched to the **baselineDB** database, and created an index on the **value** field in the **perf** collection. The index creation process completed in **22 milliseconds**, indicating relatively fast index building for the dataset size. +The test connected to MongoDB, switched to the `baselineDB` database, and created an index on the value field in the `perf` collection. The index creation process completed in 22 milliseconds, indicating relatively fast index building for the dataset size. -You should see an output similar to: +You should see output similar to: ```output Index Creation Time (ms): 22 @@ -178,14 +189,16 @@ Index Creation Time (ms): 22 6. Concurrency Smoke Test +You will now verify that MongoDB can handle concurrent client connections and inserts without errors: + ```console for i in {1..5}; do mongosh --eval 'use baselineDB; db.concurrent.insertMany([...Array(1000).keys()].map(k => ({ test: k, ts: new Date() })))' & done wait ``` -This command runs **five MongoDB insert jobs at the same time**, each adding **1,000 new records** to the **baselineDB.concurrent** collection. -It’s a quick way to test how MongoDB handles **multiple users writing data at once**. +This command runs five MongoDB insert jobs at the same time, each adding 1,000 new records to the `baselineDB.concurrent` collection. +It is a quick way to test how MongoDB handles multiple users writing data at once. You should see an output similar to: @@ -207,8 +220,8 @@ switched to db baselineDB; [5]+ Done mongosh --eval 'use baselineDB; db.concurrent.insertMany([...Array(1000).keys()].map(k => ({ test: k, ts: new Date() })))' ``` -**Five parallel MongoDB shell sessions** were executed, each inserting **1,000** test documents into the baselineDB.concurrent collection. All sessions completed successfully, confirming that concurrent data insertion works as expected. +Five parallel MongoDB shell sessions were executed, each inserting 1,000 test documents into the baselineDB.concurrent collection. All sessions completed successfully, confirming that concurrent data insertion works as expected. -The above operations confirm that MongoDB is installed successfully and is functioning as expected on the Azure Cobalt 100 (Arm64) environment. +With these tests you have confirmed that MongoDB is installed successfully and is functioning as expected on the Azure Cobalt 100 (Arm64) environment. -Now, your MongoDB instance is ready for further benchmarking and production use. +You are now ready to perform further benchmarking for MongoDB. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/benchmarking.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/benchmarking.md index 10e45dbe86..ae7a0a4276 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/benchmarking.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/benchmarking.md @@ -8,8 +8,8 @@ layout: learningpathall ## Benchmark MongoDB with **mongotop** and **mongostat** -This guide will help the user measure MongoDB’s performance in real time. -The user will install the official MongoDB database tools, start MongoDB, run a script to simulate heavy load, and watch the database’s live performance using **mongotop** and **mongostat**. +In this section, you will measure MongoDB's performance in real time. +You will install the official MongoDB database tools, start MongoDB and run a script to simulate heavy load. With the script running you will then meassure the database's live performance using **mongotop** and **mongostat**. 1. Install MongoDB Database Tools @@ -20,7 +20,7 @@ sudo apt install -y ./mongodb-database-tools-ubuntu2404-arm64-100.13.0.deb echo 'export PATH=$PATH:~/mongodb-database-tools-ubuntu2404-arm64-100.13.0/bin' >> ~/.bashrc source ~/.bashrc ``` -These commands download and unpack MongoDB’s official monitoring tools (**mongotop** & **mongostat**), then add them to your PATH so you can run them from any terminal. +These commands download and unpack MongoDB's official monitoring tools (**mongotop** & **mongostat**), then add them to your PATH so you can run them from any terminal. 2. Verify the Installation @@ -30,7 +30,7 @@ mongostat --version ``` This checks that both tools were installed correctly and are ready to use. -You should see an output similar to: +You should see output similar to: ```output mongostat --version mongotop version: 100.13.0 @@ -52,11 +52,11 @@ Go version: go1.23.11 ```console mongod --dbpath /var/lib/mongo --logpath /var/log/mongodb/mongod.log --fork ``` -These commands create a folder for MongoDB’s data, then start the database server in the background, allowing connections from any IP, and save logs for troubleshooting. +These commands create a folder for MongoDB's data, then start the database server in the background, allowing connections from any IP, and save logs for troubleshooting. 4. Create a Long-Running Load Script for Benchmarking -Save this script file as **long_system_load.js**: +Use a file editor of your choice and create a file named `long_system_load.js` with the content below: ```javascript function randomString(len) { @@ -109,7 +109,7 @@ for (let cycle = 0; cycle < totalCycles; cycle++) { print("=== Long load generation completed ==="); ``` -This is the load generator script, it creates several collections and repeatedly **inserts, queries, updates** and **deletes** data. Running it simulates real application traffic so the monitors have something to measure. +This is the load generator script, it creates several collections and repeatedly inserts, queries, updates and deletes data. Running it simulates real application traffic so the monitors have something to measure. {{% notice Note %}} Before proceeding, the load script and the monitoring tools must be run in separate terminals simultaneously. @@ -117,7 +117,7 @@ Before proceeding, the load script and the monitoring tools must be run in separ - The load script continuously generates activity in MongoDB, keeping the database busy with multiple operations. - The mongotop and mongostat tools monitor and report this activity in real time as it happens. -If all commands are run in the same terminal, the monitoring tools will only start after the script finishes, preventing real-time observation of MongoDB’s performance. +If all commands are run in the same terminal, the monitoring tools will only start after the script finishes, preventing real-time observation of MongoDB's performance. {{% /notice %}} ### Run the load script (start the workload) — Terminal 1 @@ -128,7 +128,7 @@ mongosh < long_system_load.js This command tells the MongoDB shell to execute the entire script. The script will run through its cycles and print the progress while generating the read/write activity on the server. -You should see an output similar to: +You should see output similar to: ```output test> // long_system_load.js @@ -255,7 +255,7 @@ test> print("=== Long load generation completed ==="); ``` -The load has been generated successfully. Now, you can proceed with the monitoring: +The load has been generated successfully. Now, you can proceed to the next section where you will monitor this running workload with: - **mongotop** to observe activity per collection. - **mongostat** to monitor overall operations per second, memory usage, and network activity. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/create-instance.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/create-instance.md index 9571395aa2..b870b9b96c 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/create-instance.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/create-instance.md @@ -8,11 +8,11 @@ layout: learningpathall ## Introduction -There are several ways to create an Arm-based Cobalt 100 virtual machine : the Microsoft Azure console, the Azure CLI tool, or using your choice of IaC (Infrastructure as Code). This guide will use the Azure console to create a virtual machine with Arm-based Cobalt 100 Processor. +There are several ways to create an Arm-based Cobalt 100 virtual machine : the Microsoft Azure console, the Azure CLI tool, or using your choice of IaC (Infrastructure as Code). In this section, you will use the Azure console to create a virtual machine with Arm-based Azure Cobalt 100 Processor. This learning path focuses on the general-purpose virtual machine of the D series. Please read the guide on [Dpsv6 size series](https://learn.microsoft.com/en-us/azure/virtual-machines/sizes/general-purpose/dpsv6-series) offered by Microsoft Azure. -If you have never used the Microsoft Cloud Platform before, please review the microsoft [guide to Create a Linux virtual machine in the Azure portal](https://learn.microsoft.com/en-us/azure/virtual-machines/linux/quick-create-portal?tabs=ubuntu). +While the steps to create this instance are included here for your convenience, you can also refer to the [Deploy a Cobalt 100 Virtual Machine on Azure Learning Path](/learning-paths/servers-and-cloud-computing/cobalt/) #### Create an Arm-based Azure Virtual Machine @@ -43,8 +43,4 @@ Creating a virtual machine based on Azure Cobalt 100 is no different from creati ![Azure portal VM creation — Azure Cobalt 100 Arm64 virtual machine (D4ps_v6) alt-text#center](images/final-vm.png "Figure 5: VM deployment confirmation in Azure portal") -{{% notice Note %}} - -To learn more about Arm-based virtual machine in Azure, refer to “Getting Started with Microsoft Azure” in [Get started with Arm-based cloud instances](/learning-paths/servers-and-cloud-computing/csp/azure). - -{{% /notice %}} +While the virtual machine ready, proceed to the next section to delpoy MongoDB on your running instance. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/deploy.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/deploy.md index 6509c3d334..2bee07f312 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/deploy.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/deploy.md @@ -36,7 +36,7 @@ echo 'export PATH=/usr/local/mongodb/bin:$PATH' | sudo tee /etc/profile.d/mongod source /etc/profile.d/mongodb.sh ``` -4. Create a data and log directories +4. Create data and log directories to use with MongoDB: Set up the database data directory: ```console @@ -47,7 +47,7 @@ sudo chown -R $USER:$USER /var/lib/mongo /var/log/mongodb 5. Start MongoDB Server -Start MongoDB manually: +You can start MongoDB manually as shown: ```console mongod --dbpath /var/lib/mongo --logpath /var/log/mongodb/mongod.log --fork ``` @@ -77,12 +77,12 @@ source /etc/profile.d/mongosh.sh ### Verify MongoDB and mongosh Installation -Check if MongoDB and mongosh is properly installed: +Check if MongoDB and mongosh are properly installed on your machine: ```console mongod --version mongosh --version ``` -You should see an output similar to: +You should see output similar to: ```output db version v8.0.12 Build Info: { @@ -102,11 +102,11 @@ Build Info: { ### Connect to MongoDB via mongosh -Start interacting with MongoDB through its shell interface: +You can now start interacting with MongoDB through its shell interface: ```console mongosh mongodb://127.0.0.1:27017 ``` -You should see an output similar to: +You should see output on your terminal similar to: ```output Current Mongosh Log ID: 68b573411523231d81a00aa0 Connecting to: mongodb://127.0.0.1:27017/?directConnection=true&serverSelectionTimeoutMS=2000&appName=mongosh+2.3.8 @@ -130,4 +130,4 @@ For mongosh info see: https://www.mongodb.com/docs/mongodb-shell/ test> ``` -MongoDB installation is complete. You can now proceed with the baseline testing. +With this you have verified that the MongoDB installation is complete. You can now proceed with the baseline testing of MongoDB on your Azure Cobalt 100 based VM. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongostat.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongostat.md index 17fccf65e0..73fff11963 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongostat.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongostat.md @@ -7,39 +7,19 @@ layout: learningpathall --- ## Monitoring MongoDB Performance using mongostat -This guide demonstrates real-time MongoDB monitoring using **mongostat** on Arm64 Azure virtual machines. It **shows low-latency, stable insert, query, update, and delete operations**, with consistent memory usage and network throughput, providing a quick health-and-performance overview during benchmarking. +In this section you will monitor MongoDB in real-time using **mongostat** on Arm64 Azure virtual machines. You will notice low-latency, stable insert, query, update, and delete operations, with consistent memory usage and network throughput. ## Monitor with mongostat — Terminal 3 +With the workload script running on your first terminal, you will now run mongostat on another terminal to view the real-time performance: + ```console mongostat 2 ``` -**mongostat** gives a one-line summary every 2 seconds of inserts, queries, updates, deletes, memory use and network I/O. It’s your quick health-and-throughput dashboard during the test. +**mongostat** gives a one-line summary every 2 seconds of inserts, queries, updates, deletes, memory use and network I/O. It is your quick health-and-throughput dashboard during the test. -You should see an output similar to: +You should see output similar to: ```output -insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time - *0 *0 *0 *0 0 4|0 0.0% 0.0% 0 3.53G 140M 0|0 0|0 664b 52.7k 6 Sep 4 04:57:16.761 - 50 *0 *0 *0 0 7|0 0.0% 0.0% 0 3.53G 141M 0|0 0|0 10.9k 57.8k 10 Sep 4 04:57:18.761 - 404 13 4 4 71 8|0 0.0% 0.0% 0 3.53G 143M 0|0 0|0 96.3k 114k 10 Sep 4 04:57:20.761 - 7 14 7 7 108 2|0 0.0% 0.0% 0 3.53G 143M 0|0 0|0 21.8k 118k 10 Sep 4 04:57:22.760 - 6 12 6 6 112 0|0 0.0% 0.0% 0 3.53G 143M 0|0 0|0 21.9k 120k 10 Sep 4 04:57:24.760 - 8 16 8 8 136 1|0 0.0% 0.0% 0 3.53G 144M 0|0 0|0 27.1k 137k 10 Sep 4 04:57:26.762 - 5 10 5 5 93 2|0 0.0% 0.0% 0 3.54G 144M 0|0 0|0 18.2k 111k 11 Sep 4 04:57:28.760 - 7 15 7 7 135 0|0 0.0% 0.0% 0 3.54G 144M 0|0 0|0 26.5k 139k 11 Sep 4 04:57:30.761 - 5 11 5 5 102 1|0 0.0% 0.0% 0 3.54G 144M 0|0 0|0 19.7k 118k 11 Sep 4 04:57:32.761 - 7 16 10 7 138 2|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 27.0k 143k 11 Sep 4 04:57:34.761 -insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time - 5 10 5 5 104 1|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 20.1k 121k 11 Sep 4 04:57:36.761 - 8 16 8 8 142 2|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 27.6k 144k 11 Sep 4 04:57:38.761 - 5 11 5 5 114 1|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 21.3k 125k 11 Sep 4 04:57:40.760 - 7 15 7 7 134 1|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 25.9k 141k 11 Sep 4 04:57:42.760 - 5 11 5 5 126 1|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 23.6k 133k 11 Sep 4 04:57:44.761 - 6 12 6 6 128 1|0 0.0% 0.0% 0 3.54G 145M 0|0 0|0 24.4k 136k 11 Sep 4 04:57:46.761 - 6 13 6 6 140 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 26.5k 144k 11 Sep 4 04:57:48.762 - 6 12 6 6 114 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 21.7k 128k 11 Sep 4 04:57:50.762 - 7 15 7 7 164 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 30.4k 157k 11 Sep 4 04:57:52.761 - 5 10 5 5 100 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 18.9k 118k 11 Sep 4 04:57:54.761 insert query update delete getmore command dirty used flushes vsize res qrw arw net_in net_out conn time 8 16 8 8 182 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 34.0k 172k 11 Sep 4 04:57:56.761 4 8 4 4 98 1|0 0.0% 0.0% 0 3.54G 146M 0|0 0|0 18.3k 116k 11 Sep 4 04:57:58.762 @@ -99,25 +79,9 @@ Here is a summary of benchmark results collected on an Arm64 **D4ps_v6 Ubuntu Pr | 7 | 16 | 10 | 7 | 138 | 2/0 | 0.0% | 0.0% | 0 | 3.54G | 145M | 0/0 | 0/0 | 27.0k | 143k | 11 | Sep 4 04:57:34.761 | | 5 | 10 | 5 | 5 | 104 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 145M | 0/0 | 0/0 | 20.1k | 121k | 11 | Sep 4 04:57:36.761 | -## Benchmark summary on x86_64: -Here is a summary of the benchmark results collected on x86_64 **D4s_v6 Ubuntu Pro 24.04 LTS virtual machine**. - -| insert | query | update | delete | getmore | command | dirty | used | flushes | vsize | res | qrw | arw | net_in | net_out | conn | time | -|--------|-------|--------|--------|---------|---------|-------|------|---------|-------|------|------|------|--------|---------|------|----------------------| -| 249 | 2 | 0 | 0 | 0 | 11/0 | 0.0% | 0.0% | 0 | 3.54G | 186M | 0/1 | 0/0 | 52.5k | 66.9k | 10 | Sep 4 05:52:36.629 | -| 208 | 18 | 8 | 8 | 120 | 5/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 64.8k | 134k | 10 | Sep 4 05:52:38.629 | -| 5 | 10 | 5 | 5 | 95 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 18.6k | 110k | 10 | Sep 4 05:52:40.629 | -| 8 | 17 | 8 | 8 | 152 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 30.0k | 144k | 10 | Sep 4 05:52:42.630 | -| 9 | 18 | 9 | 9 | 153 | 2/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 30.2k | 150k | 11 | Sep 4 05:52:46.629 | -| 8 | 17 | 8 | 8 | 161 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 31.3k | 158k | 11 | Sep 4 05:52:52.629 | -| 7 | 15 | 7 | 7 | 150 | 2/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 28.4k | 148k | 11 | Sep 4 05:52:56.628 | -| 8 | 17 | 8 | 8 | 170 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 32.6k | 164k | 11 | Sep 4 05:52:58.629 | -| 8 | 17 | 8 | 8 | 179 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 33.8k | 168k | 11 | Sep 4 05:53:02.631 | -| 9 | 18 | 9 | 9 | 193 | 1/0 | 0.0% | 0.0% | 0 | 3.54G | 190M | 0/0 | 0/0 | 35.8k | 177k | 11 | Sep 4 05:53:12.628 | ### Highlights from Azure Ubuntu Pro 24.04 LTS Arm64 Benchmarking -When comparing the results on Arm64 vs x86_64 virtual machines: - **Insert, Query, Update, Delete Rates:** Throughput remains consistent, with inserts and queries ranging from **5–50 ops/sec**, while updates and deletes generally track queries. A workload burst is observed with an **insert spike of 404**, highlighting MongoDB’s ability to handle sudden surges. - **Memory Usage:** Resident memory remains stable at **141–145 MB**, with virtual memory steady at **3.53–3.54 GB**, confirming efficient memory allocation and stability. @@ -127,4 +91,4 @@ When comparing the results on Arm64 vs x86_64 virtual machines: - **Overall System Behavior:** MongoDB demonstrates stable throughput, predictable memory usage, and balanced network performance, while also showcasing resilience under workload bursts on Arm64. -You have now benchmarked MongoDB on an Azure Cobalt 100 Arm64 virtual machine and compared results with x86_64. +You have now successfully benchmarked MongoDB on an Azure Cobalt 100 Arm64 virtual machine. diff --git a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongotop.md b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongotop.md index 3886242050..5ce917d298 100644 --- a/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongotop.md +++ b/content/learning-paths/servers-and-cloud-computing/mongodb-on-azure/mongotop.md @@ -6,8 +6,8 @@ weight: 7 layout: learningpathall --- -## Monitoring MongoDB Performance using Mongotop -This guide demonstrates how to monitor MongoDB performance using **mongotop**, showing **read/write** activity across collections in **real time**. It includes benchmark results collected on Azure Arm64 virtual machines, providing a reference for expected latencies. +## Monitor MongoDB Performance using Mongotop +This guide demonstrates how to monitor MongoDB performance using **mongotop**, showing read and write activity across collections in real time. It includes benchmark results collected on Azure Arm64 virtual machines, providing a reference for expected latencies. ## Run mongotop — Terminal 2 @@ -16,379 +16,8 @@ mongotop 2 ``` **mongotop** shows how much time the server spends reading and writing each collection (refreshes every 2 seconds here). It helps you see which collections are busiest and whether reads or writes dominate. -You should see an output similar to: +The tail end of the output should look like: ```output - ns total read write 2025-09-04T04:57:21Z - benchmarkDB.cursorTest 7ms 1ms 6ms - admin.atlascli 4ms 1ms 2ms -config.system_sessions_bench 3ms 1ms 2ms - benchmarkDB.testCollection 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - baselineDB.perf 0ms 0ms 0ms - baselineDB.testCollection 0ms 0ms 0ms - config.system.sessions 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:23Z - benchmarkDB.cursorTest 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 2ms -test.admin_system_version_test 4ms 1ms 2ms - test.atlascli 4ms 1ms 2ms - test.system_sessions_bench 4ms 1ms 2ms - local.system_replset_bench 3ms 1ms 2ms - admin.atlascli 2ms 0ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:25Z - admin.atlascli 4ms 1ms 2ms - config.system_sessions_bench 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 2ms - local.system_replset_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 2ms 0ms 1ms - benchmarkDB.testCollection 2ms 0ms 1ms -test.admin_system_version_test 2ms 0ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:27Z - benchmarkDB.cursorTest 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms -test.admin_system_version_test 4ms 1ms 2ms - test.atlascli 4ms 1ms 2ms - test.system_sessions_bench 4ms 1ms 2ms - admin.atlascli 2ms 0ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:29Z - admin.atlascli 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.system_sessions_bench 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 2ms - local.system_replset_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 3ms 1ms 2ms -test.admin_system_version_test 2ms 0ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:31Z -test.admin_system_version_test 4ms 2ms 2ms - test.atlascli 4ms 2ms 2ms - test.system_sessions_bench 4ms 2ms 2ms - benchmarkDB.cursorTest 3ms 1ms 1ms - admin.atlascli 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 0ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:33Z - admin.atlascli 4ms 2ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.system_sessions_bench 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 2ms - local.system_replset_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:35Z - benchmarkDB.cursorTest 4ms 1ms 2ms -test.admin_system_version_test 4ms 1ms 2ms - test.atlascli 4ms 1ms 2ms - test.system_sessions_bench 4ms 1ms 2ms - admin.atlascli 2ms 0ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:37Z - admin.atlascli 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.system_sessions_bench 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 2ms - local.system_replset_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 2ms 0ms 1ms -test.admin_system_version_test 2ms 0ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:39Z - benchmarkDB.cursorTest 4ms 2ms 2ms -test.admin_system_version_test 4ms 1ms 2ms - test.atlascli 4ms 1ms 2ms - test.system_sessions_bench 4ms 1ms 2ms - admin.atlascli 2ms 0ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:41Z - admin.atlascli 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.system_sessions_bench 4ms 2ms 2ms - config.transactions_bench 4ms 2ms 2ms - local.system_replset_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:43Z - benchmarkDB.cursorTest 5ms 2ms 2ms - test.system_sessions_bench 5ms 2ms 2ms -test.admin_system_version_test 4ms 2ms 2ms - test.atlascli 4ms 1ms 2ms - benchmarkDB.testCollection 3ms 2ms 1ms - admin.atlascli 2ms 1ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:45Z - admin.atlascli 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 2ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:47Z - benchmarkDB.cursorTest 5ms 2ms 2ms - benchmarkDB.testCollection 5ms 2ms 2ms - local.system_replset_bench 5ms 2ms 2ms -test.admin_system_version_test 5ms 2ms 3ms - test.atlascli 5ms 2ms 2ms - test.system_sessions_bench 4ms 2ms 2ms - admin.atlascli 2ms 1ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:49Z - admin.atlascli 5ms 1ms 3ms - config.system_sessions_bench 4ms 1ms 2ms - benchmarkDB.cursorTest 2ms 0ms 1ms - benchmarkDB.testCollection 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 0ms 1ms -test.admin_system_version_test 2ms 0ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 0ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:51Z - benchmarkDB.cursorTest 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.transactions_bench 4ms 1ms 3ms - local.system_replset_bench 4ms 1ms 2ms -test.admin_system_version_test 4ms 1ms 2ms - test.atlascli 4ms 1ms 2ms - test.system_sessions_bench 4ms 1ms 2ms - admin.atlascli 2ms 0ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:53Z - admin.atlascli 2ms 0ms 1ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 0ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 0ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:55Z - admin.atlascli 5ms 2ms 2ms - config.transactions_bench 5ms 2ms 2ms - test.system_sessions_bench 5ms 2ms 2ms - benchmarkDB.cursorTest 4ms 1ms 2ms - benchmarkDB.testCollection 4ms 1ms 2ms - config.system_sessions_bench 4ms 2ms 2ms - local.system_replset_bench 4ms 1ms 2ms -test.admin_system_version_test 4ms 2ms 2ms - test.atlascli 4ms 2ms 2ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:57Z - admin.atlascli 2ms 1ms 1ms - benchmarkDB.cursorTest 2ms 0ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - config.transactions_bench 2ms 0ms 1ms - local.system_replset_bench 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 0ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:57:59Z - admin.atlascli 5ms 2ms 3ms - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 2ms -test.admin_system_version_test 5ms 2ms 3ms - test.atlascli 5ms 2ms 3ms - test.system_sessions_bench 5ms 2ms 3ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:01Z - admin.atlascli 2ms 1ms 1ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - config.transactions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:03Z - admin.atlascli 5ms 2ms 3ms - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 3ms -test.admin_system_version_test 5ms 2ms 3ms - test.atlascli 5ms 2ms 3ms - test.system_sessions_bench 5ms 2ms 3ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:05Z - config.transactions_bench 3ms 1ms 1ms - admin.atlascli 2ms 1ms 1ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:07Z - admin.atlascli 5ms 2ms 3ms - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 3ms - test.atlascli 5ms 1ms 3ms -test.admin_system_version_test 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:09Z -test.admin_system_version_test 5ms 2ms 3ms - test.system_sessions_bench 5ms 2ms 3ms - admin.atlascli 2ms 1ms 1ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - config.transactions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:11Z - admin.atlascli 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 3ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:13Z - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 3ms -test.admin_system_version_test 5ms 2ms 3ms - test.atlascli 5ms 2ms 3ms - test.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 3ms 1ms 1ms - admin.atlascli 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:15Z - admin.atlascli 3ms 1ms 1ms - config.transactions_bench 3ms 1ms 1ms -test.admin_system_version_test 3ms 1ms 1ms - benchmarkDB.cursorTest 2ms 1ms 1ms - benchmarkDB.testCollection 2ms 1ms 1ms - config.system_sessions_bench 2ms 1ms 1ms - local.system_replset_bench 2ms 1ms 1ms - test.atlascli 2ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:17Z - admin.atlascli 6ms 2ms 3ms - config.system_sessions_bench 6ms 2ms 3ms - config.transactions_bench 6ms 2ms 3ms - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 3ms -test.admin_system_version_test 5ms 2ms 3ms - test.atlascli 5ms 2ms 3ms - test.system_sessions_bench 5ms 2ms 3ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:19Z - admin.atlascli 3ms 1ms 1ms - benchmarkDB.cursorTest 3ms 1ms 1ms - benchmarkDB.testCollection 3ms 1ms 1ms - config.system_sessions_bench 3ms 1ms 1ms - config.transactions_bench 3ms 1ms 1ms - local.system_replset_bench 3ms 1ms 1ms -test.admin_system_version_test 3ms 1ms 1ms - test.atlascli 3ms 1ms 1ms - test.system_sessions_bench 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms - - ns total read write 2025-09-04T04:58:21Z - admin.atlascli 5ms 2ms 3ms - benchmarkDB.cursorTest 5ms 2ms 3ms - benchmarkDB.testCollection 5ms 2ms 3ms - config.system_sessions_bench 5ms 2ms 3ms - config.transactions_bench 5ms 2ms 3ms - local.system_replset_bench 5ms 2ms 3ms - test.atlascli 5ms 1ms 3ms - test.system_sessions_bench 3ms 1ms 1ms -test.admin_system_version_test 2ms 1ms 1ms - admin.system.version 0ms 0ms 0ms ns total read write 2025-09-04T04:58:23Z test.admin_system_version_test 5ms 2ms 3ms @@ -450,7 +79,7 @@ test.admin_system_version_test 6ms 2ms 3ms - **admin.system.version** – Static metadata collection with minimal activity. ## Benchmark summary on Arm64 -For easier comparison, shown here is a summary of benchmark results collected on an Arm64 **D4ps_v6 Azure Ubuntu Pro 24.04 LTS virtual machine**. +For easier visualization, shown here is a summary of benchmark results collected on an Arm64 **D4ps_v6 Azure Ubuntu Pro 24.04 LTS virtual machine**. | Namespace (ns) | Total Time Range | Read Time Range | Write Time Range | Notes | | :------------------------------- | :--------------- | :-------------- | :--------------- | :------------------------------------------------------------ | @@ -465,30 +94,12 @@ For easier comparison, shown here is a summary of benchmark results collected on | **test.system_sessions_bench** | 2–5 ms | 0–2 ms | 1–3 ms | Session benchmark (test namespace). | | **admin.system.version** | 0 ms | 0 ms | 0 ms | Appears inactive or instantaneous responses. | -### Benchmark summary on x86_64: -Here is a summary of the benchmark results collected on x86_64 **D4s_v6 Ubuntu Pro 24.04 LTS virtual machine**. - -| Namespace (ns) | Total Time Range | Read Time Range | Write Time Range | Notes | -| :-------------------------------- | :--------------- | :-------------- | :--------------- | :--------------------------------------------------------------- | -| **admin.atlascli** | 1–5 ms | 0–3 ms | 0–2 ms | Admin CLI activity. | -| **benchmarkDB.cursorTest** | 1–3 ms | 0–1 ms | 0–1 ms | Cursor iteration benchmark workload. | -| **benchmarkDB.testCollection** | 1–4 ms | 0–2 ms | 0–2 ms | Main insert/query benchmark activity. | -| **config.system_sessions_bench** | 1–5 ms | 0–2 ms | 0–2 ms | Session handling benchmark. | -| **config.transactions_bench** | 1–4 ms | 0–2 ms | 0–2 ms | Transaction handling benchmark. | -| **local.system_replset_bench** | 1–4 ms | 0–2 ms | 0–2 ms | Local replica set performance test. | -| **test.admin_system_version_test**| 1–4 ms | 0–1 ms | 0–1 ms | Versioning metadata check. | -| **test.atlascli** | 1–4 ms | 0–1 ms | 0–2 ms | CLI/system background workload in test DB. | -| **test.system_sessions_bench** | 1–3 ms | 0–1 ms | 0–2 ms | Session simulation in test namespace. | -| **admin.system.version** | 0 ms | 0 ms | 0 ms | Always inactive/instantaneous response. | - -### Highlights from Azure ubuntu Arm64 Benchmarking -When comparing the results on Arm64 vs x86_64 virtual machines: +With the MongoDB performance summary of the results on your Arm-based Azure Cobalt 100 VM, you will notice: + - Stable, low-latency behavior across all tested namespaces. + - Read operations are near-instant (sub-2 ms), showing efficient query performance. + - Write operations remain consistently low, supporting reliable data modifications. + - System and transaction overheads are predictable, indicating a well-tuned environment for concurrent/replicated workloads. -- **Most active namespaces:** `admin.atlascli`, `benchmarkDB.testCollection`, `benchmarkDB.cursorTest`, and `test.atlascli` — total times **2–6 ms**. -- **Read patterns:** Reads across collections remain **0–2 ms**, showing consistently low-latency performance on Arm64. -- **Write patterns:** Writes are mostly **1–3 ms**, indicating stable and balanced write performance. -- **System-related namespaces:** `config.system_sessions_bench` and `config.transactions_bench` — total times **2–6 ms**, showing manageable system and transaction activity. -- **Idle collections:** `admin.system.version` remains at **0 ms**, confirming minimal or no activity. -- **Overall observation:** MongoDB operations on Arm64 are lightweight with **predictable, low-latency reads and writes**, confirming efficient performance on Azure Ubuntu Pro 24.04 LTS Arm64 Virtual machines. +**Overall observation:** MongoDB operations on Arm64 are lightweight with predictable, low-latency reads and writes, confirming efficient performance on Azure Ubuntu Pro 24.04 LTS Arm64 Virtual machines.