Re: relating MongoDB performance on SATA disk

From: Kevin Adistambha <kevinadi@xxxxxxxxxxx>
To: mongodb-user <mongodb-user@xxxxxxxxxxxxxxxx>
Date: Wed, 11 May 2016 15:47:34 -0700 (PDT)
Why ads?


Hi Kashif,

How do i relate MongoDB 3.2.1 (WiredTiger Storage Enginer) INSERT and READ 
performance with disk performance of SATA disk ?

Performance measurement is a deep subject and depends on many interrelated 
things. Disk is only one part of the equation, and its performance may 
depend on the interplay between the CPU speed, the amount of RAM, the 
nature of the collection (e.g. document sizes, index sizes, etc.), the size 
of the swap file, the use of compression in WiredTiger, the use of caching, 
other processes running in the system, the configuration of the O/S, and 
many other things. This is the reason why relating advertised disk 
performance to actual MongoDB performance is difficult.

In the write test, please note that besides writing the data files into 
disk, WiredTiger also uses journaling by default, and will write the 
journal every 50 ms to disk. Please see Journaling Process 
<https://docs.mongodb.com/manual/core/journaling/#journaling-process> for 
more information. Enabling WiredTiger compression could also alter the 
result, since highly compressible documents will result in smaller amount 
of disk writes compared to incompressible documents. However, please note 
that compression also depends on CPU speed.

In the read test, the nature of the data in the database directly affects 
the outcome. For example, if you have enough RAM to hold the working set in 
memory, then the only way to induce MongoDB to use the disk is to perform a 
collection scan. But this also depends on whether the data is also present 
in the filesystem cache (in which case, MongoDB does not need to pull data 
from disk). Enabling WiredTiger compression also allows the filesystem 
cache to hold more data, thus lessening the need for MongoDB to read from 
disk.

If you need to satisfy a certain Service Level Agreement (SLA) with your 
MongoDB deployment (e.g. reads and writes should not take more than 10ms), 
then measuring the response time of the overall system could be a better 
metric compared to disk performance alone.

For best results, MongoDB recommends the use of SSD 
<https://docs.mongodb.com/manual/administration/production-notes/#use-solid-state-disks-ssds
due to its typically superior random I/O operations compared to spinning 
disks. For spinning disks, there are recommended settings 
<https://docs.mongodb.com/manual/administration/production-notes/#recommended-configuration
for optimal performance.

Best regards,
Kevin


-- 
You received this message because you are subscribed to the Google Groups "mongodb-user"
group.

For other MongoDB technical support options, see: https://docs.mongodb.org/manual/support/
--- 
You received this message because you are subscribed to the Google Groups "mongodb-user" group.
To unsubscribe from this group and stop receiving emails from it, send an email to mongodb-user+unsubscribe@xxxxxxxxxxxxxxxx.
To post to this group, send email to mongodb-user@xxxxxxxxxxxxxxxx.
Visit this group at https://groups.google.com/group/mongodb-user.
To view this discussion on the web visit https://groups.google.com/d/msgid/mongodb-user/28f6de2b-412e-4a7a-a5c5-23dcb18b552d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Why ads?