relating MongoDB performance on SATA disk

72 views

Skip to first unread message

Kashif islam

unread,

May 1, 2016, 4:24:25 PM5/1/16

to mongodb-user

GoodDay People

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

I have bench-marked MongoDB performance using YCSB as shown in "write latency.png"

I varied throughput and measured corresponding latency for a record size of 200 bytes to 2000 bytes.

I measured metrics such as iostat and mongostat for each test.

My disk has following metrics:

78 seeks/second, 12.73 ms random access time

Disk Geometry:

cylinders 16383

heads 16

sectors/track 63

Logical/Physical Sector size 512 bytes

Disk performance: According to vendor provided metrics:

Internal Data Rate 125 MBps

Drive Transfer Rate 300 MBps (external)

Average Latency 4.16 ms, 4.17 ms

Spindle Speed 7200 rpm

Similarly i have measured READ workload and plotted a similar curve in "read latency.png"

i can explain these results by little's law but finding it difficult to relate to disk performance.

Appreciate any help or guidance.

read latency.png

write latency.png

Kevin Adistambha

unread,

May 11, 2016, 6:47:34 PM5/11/16

to mongodb-user

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 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 due to its typically superior random I/O operations compared to spinning disks. For spinning disks, there are recommended settings for optimal performance.