What factors contribute to lock-percentage with MongoDB

We're attempting to better optimize how we're using our MongoDB instance. We seem to be routinely getting high lock-percentages, and are looking to help minimize that. Here is some mongostat output:

`insert query update delete getmore command flushes mapped vsize res faults locked % idx miss % qr|qw ar|aw netIn netOut conn time
1 107 186 0 0 196 0 3.06g 7.3g 333m 0 11.2 0 0|0 2|0 66k 224k 85 15:55:22
2 102 285 0 0 296 0 3.06g 7.3g 333m 0 15.7 0 0|0 2|0 89k 216k 84 15:55:23
2 79 325 0 0 335 0 3.06g 7.3g 333m 0 20.2 0 0|0 3|0 96k 149k 85 15:55:24
2 92 193 0 0 203 0 3.06g 7.3g 333m 0 10.9 0 1|1 6|1 63k 149k 86 15:55:25
3 102 235 0 0 245 0 3.06g 7.3g 331m 0 14.5 0 0|0 2|0 75k 177k 84 15:55:26
3 79 267 0 0 275 0 3.06g 7.3g 331m 0 16.5 0 1|0 2|0 80k 133k 86 15:55:27
2 66 219 0 0 226 0 3.06g 7.3g 264m 0 14.3 0 0|0 2|0 66k 112k 88 15:55:28
2 100 201 0 0 211 0 3.06g 7.3g 334m 0 10.2 0 0|0 3|0 67k 142k 87 15:55:29
3 118 227 0 0 244 0 3.06g 7.3g 322m 0 13.8 0 3|1 6|1 78k 150k 87 15:55:30
2 112 189 0 0 198 0 3.06g 7.3g 334m 0 10.8 0 0|1 2|2 64k 213k 87 15:55:31
2 80 266 0 0 278 0 3.06g 7.3g 246m 0 15.8 0 0|1 3|1 82k 179k 86 15:55:32

Those are interesting stats. I think you might be suffering from document size growth in your updates, where the document needs to be copied to a new spot on the disk. If this is indeed the case, you might be able to recover some of that lock percentage by manually padding your documents. It adds a bit more complexity on the first insert, but isn't too bad. See this document from the official docs: http://www.mongodb.org/display/DOCS/Padding+Factor#PaddingFactor-ManualPadding

Just an idea...

StackExchange Database Administrators Q#16913, answer score: 3