The beginning: We are using uwsgi and I decided to switch our configuration to use more workers/processes.

Why: We have been seeing a traffic increase lately and in my tests with apache benchmark, the new configuration with more workers and processes performed much better (faster, significantly less dropped requests).

What happened: After pushing the configuration change to our app servers, we saw an immediate spike in the app server cpu (which isn't surprising), and an equally enormous rise in our mongodb server cpu.

The behavior in question: Why, when the reads and writes stayed exactly the same as before the app configuration change, should the mongodb cpu or anything else on the mongo server change at all?

A few more details:

  • We host everything on Amazon AWS
  • we use a mongo replica set
  • the secondary mongo server was more impacted (as well as the app servers that read from it)
  • Mongo version 2.2

Edit: I've also noticed that during the new configuration time period there was a huge increase in connections on the mongo server (3x), more workers = more connections?

  • Can you mention what version of MongoDB you are using?
    – Adam C
    Feb 15 '13 at 10:52

So your question about more workers means more connections, this is true. I am not sure if your using mongos or not but the scripts are going to generate connections to mongo while they are waiting to get more work.

Now about your question why the cpu load is getting more load on it when your doing nothing. But adding more workers. I am not sure if you are running mongo and workers on the same box but what could be going on is the overhead of linux kernel sechdualing the processes. It has to wake them up let them run or see if they need to run and then switch. this is not free, but its not like its a crazy cost.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.