MongoDB 3 with WiredTiger: High CPU load

[Dmitry Sidorov]

We have 3 instances in replica. Primary with 2 cores CPU and 4 GB RAM. Secondary with 1 core CPU and 4 GB RAM. Arbiter with 1 core CPU and 2 GB RAM.

The first test:

mongodb-org-server-2.6.10-1.x86_64

logpath=/var/log/mongodb/mongod.log
logappend=true
fork=true
dbpath=/mnt/mongo
pidfilepath=/var/run/mongodb/mongod.pid

And the second test: mongodb-org-server-3.0.4-1.x86_64

processManagement:
    pidFilePath: "/var/run/mongodb/mongod.pid"
    fork: true
storage:
    dbPath: "/mnt/mongo/"
    engine: "wiredTiger"
    wiredTiger:
        collectionConfig: 
            blockCompressor: none
        engineConfig: 
            cacheSizeGB: 2
            journalCompressor: none
        indexConfig:
            prefixCompression: false
systemLog:
    destination: file
    path: "/var/log/mongodb/mongod.log"
    logAppend: true
replication:
    replSetName: testrepl

CPU usage: http://i.imgur.com/Nmj021g.png

With the same loadtest we have 2x CPU load on MongoDB 3 with WiredTiger engine.

MongoDB Stats: http://i.imgur.com/cxrfUIC.png

So the question is why MongoDB 3 with WiredTiger uses 2 times more CPU? Is it normal for WiredTiger? Data in database was not changed between test. We have the same load test scenario in both times.

[s.molinari]

If you have compression turned on in WiredTiger (Snappy is on as default), I would imagine some higher CPU usage should be measurable. But, double CPU usage? I would venture to say the MongoDB team would have to answer this for a much better answer. 

Scott 

[Dmitry Sidorov]

wiredTiger:
        collectionConfig: 
            blockCompressor: none
        engineConfig: 
            cacheSizeGB: 2
            journalCompressor: none
        indexConfig:
            prefixCompression: false

As you can see, compression was disabled.
понедельник, 22 июня 2015 г., 17:00:43 UTC+3 пользователь s.molinari написал:

[Dmitry Sidorov]

Any ideas? :)

[Alexander Gorrod]

Hi,

I would expect WiredTiger to use more CPU than mmap. The exact amount depends a lot on the workload you are running. What is the workload you are running to generate these graphs? Are you seeing exactly the same throughput with WiredTiger as you do with mmap?

The WiredTiger statistics indicate that there are a lot of query operations happening. Some of those can probably be attributed to maintaining the replication log, but some appear to be due to getMore operations.

Which version of MongoDB are you running this test with? What do you expect to see i.e: is the greater resource usage meaning you are getting less throughput?

[Dmitry Sidorov]

Hi, Alexander! Thank you for your time!

We use Tsung for load testing. We simulate near 100-200 online users in chat which post different chat messages (private and group chats). So most of queries are insert or update. 

If we count messages written to database, we have the same number on 2.6.10 and 3.0.4 (with WT). But on 2.6.10 we have a lot IOPS, and on 3.0.4 with WT we have less IOPS but 2 times higher the CPU load. Actually we didn't expect such CPU load.

So, as i understand, this is normal work of WiredTiger and we must use it as is?

четверг, 25 июня 2015 г., 6:17:21 UTC+3 пользователь Alexander Gorrod написал: 

[Alexander Gorrod]

Hi Dmitry,

Yes - I would say this is expected behavior with WiredTiger.

Regards,
Alex

[Dmitry Sidorov]

Thank You!