0

Short question is on the title: I work with my mongo Shell wich is in safe mode by default, and I want to gain better performance by deactivating this behaviour.

Long Question for those willing to know the context: I am working on a huge set of data like

{
_id:ObjectId("azertyuiopqsdfghjkl"),
stringdate:"2008-03-08 06:36:00"
}

and some other fields and there are about 250M documents like that (whole database with the indexes weights 36Go). I want to convert the date in a real ISODATE field. I searched a bit how I could make an update query like

db.data.update({},{$set:{date:new Date("$stringdate")}},{multi:true})

but did not find how to make this work and resolved myself to make a script that take the documents one after the other and make an update to set a new field which takes the new Date(stringdate) as its value. The query use the _id so the default index is used.

Problem is that it takes a very long time. I already figured out that if only I had inserted empty dates object when I created the database I would now get better performances since there is the problem of data relocation when a new field is added. I also set an index on a relevant field to process the database chunk by chunk. Finally I ran several concurrent mongo clients on both the server and my workstation to ensure that the limitant factor is the database lock availability and not any other factor like cpu or network costs.

I monitored the whole thing with mongotop, mongostats and the web monitoring interfaces which confirmed that write lock is taken 70% of the time. I am a bit disappointed mongodb does not have a more precise granularity on its write lock, why not allowing concurrent write operations on the same collection as long as there is no risk of interference? Now that I think about it I should have sharded the collection on a dozen shards even while staying on the same server, because there would have been individual locks on each shard.

But since I can't do a thing right now to the current database structure, I searched how to improve performance to at least spend 90% of my time writing in mongo (from 70% currently), and I figured out that since I ran my script in the default mongo shell, every time I make an update, there is also a getLastError() which is called afterwards and I don't want it because there is a 99.99% chance of success and even in case of failure I can still make an aggregation request after the end of the big process to retrieve the single exceptions.

I don't think I would gain so much performance by deactivating the getLastError calls, but I think itis worth trying.

I took a look at the documentation and found confirmation of the default behavior, but not the procedure for changing it. Any suggestion?

Aldian
  • 2,592
  • 2
  • 27
  • 39
  • `db.getLastError({w:0})` will do it I beleive but you are maing a big mistake, I am still reading the long answer – Sammaye Jan 03 '14 at 14:09
  • "performances since there is the problem of data relocation when a new field is added" I did tell people this in my answers when they asked if they should add certain fields or not, instead they listened to the guy who said "No leave those fields out", I know I shouldn't feel smug but I do – Sammaye Jan 03 '14 at 14:14
  • The reason for the lock granularity is because of the reliance on subsiding operations for queued ones, as such if operations are waiting to run your update operation will actually give way to them, etc etc based upon a set of rules, but your lock is building up because of movement – Sammaye Jan 03 '14 at 14:19
  • Do be aware that getlasterror only calls in interactive mode, i.e. when in a loop it won't actually call as such your attempt, using a loop, would never have called getlasterror until the end. As such downing the getlasterror wont help – Sammaye Jan 03 '14 at 14:22
  • % of time lock is used does not tell you anything except the fact that writes are happening. what you should look at are sizes of queues - in particular write queues, that's what will indicate whether you are being held up by the lock. Even if you are, if it's only because you are resizing the document, but it seems if you *replace* stringdate with new date value, that would leave your document the same size... – Asya Kamsky Jan 03 '14 at 18:28

1 Answers1

1

I work with my mongo Shell wich is in safe mode by default, and I want to gain better performance by deactivating this behaviour.

You can use db.getLastError({w:0}) ( http://docs.mongodb.org/manual/reference/method/db.getLastError/ ) to do what you want but it won't help.

This is because for one:

make a script that take the documents one after the other and make an update to set a new field which takes the new Date(stringdate) as its value.

When using the shell in a non-interactive mode like within a loop it doesn't actually call getLastError(). As such downing your write concern to 0 will do nothing.

I already figured out that if only I had inserted empty dates object when I created the database I would now get better performances since there is the problem of data relocation when a new field is added.

I did tell people when they asked about this stuff to add those fields incase of movement but instead they listened to the guy who said "leave them out! They use space!".

I shouldn't feel smug but I do. That's an unfortunately side effect of being right when you were told you were wrong.

mongostats and the web monitoring interfaces which confirmed that write lock is taken 70% of the time

That's because of all the movement in your documents, kinda hard to fix that.

I am a bit disappointed mongodb does not have a more precise granularity on its write lock

The write lock doesn't actually denote the concurrency of MongoDB, this is another common misconception that stems from the transactional SQL technologies.

Write locks in MongoDB are mutexs for one.

Not only that but there are numerous rules which dictate that operations will subside to queued operations under certain circumstances, one being how many operations waiting, another being whether the data is in RAM or not, and more.

Unfortunately I believe you have got yourself stuck in between a rock and hard place and there is no easy way out. This does happen.

Sammaye
  • 43,242
  • 7
  • 104
  • 146
  • I will take a look at that mutex thing, but the web interface gives me con8|waitingForLock: true; con19|waitingForLock: true; con20|waitingForLock: true; con21|waitingForLock: true; con22|waitingForLock: true; con23|waitingForLock: true; con24|waitingForLock: true; con25|waitingForLock: true; con26|waitingForLock: **false** which lead me to think that one client was having its modification performed while the others were just waiting. Anyway thanks for the long reply – Aldian Jan 03 '14 at 15:24
  • @Aldian Yeah I believe movement of documents counts as write lock :( – Sammaye Jan 03 '14 at 15:25
  • @Aldian oh yeah within a given microsecond only one client does have it work done, sorry I didn't see your entire comment until just now. So it is a per database lock but the speed of the lock and its subsiding abilities makes up for that – Sammaye Jan 03 '14 at 15:32
  • @Aldian think of interloping instead of running at the same time, it works ops off bits at a time – Sammaye Jan 03 '14 at 15:38