MongoDB capped collection replication & extremely high CPU usage - mongodb

Question

Should there be a problem running a replica set that contains capped collections?
For some reason one of the secondary nodes on my replica set is periodically at 90% CPU for a few hours.
Breaking into it with gdb shows the following stack trace nearly every time:
#0 0x00000000008c3e3a in mongo::ps::Rolling::access(unsigned long, short, bool) ()
#1 0x00000000008c3bd6 in mongo::Record::accessed() ()
#2 0x000000000086eb03 in mongo::CoveredIndexMatcher::matches(mongo::BSONObj const&, mongo::DiskLoc const&, mongo::MatchDetails*, bool) ()
#3 0x000000000086ed78 in mongo::CoveredIndexMatcher::matchesCurrent(mongo::Cursor*, mongo::MatchDetails*) ()
#4 0x00000000009794dc in mongo::UpdateOp::next() ()
#5 0x00000000008c9a96 in mongo::QueryPlanSet::Runner::nextOp(mongo::QueryOp&) ()
#6 0x00000000008d9930 in mongo::QueryPlanSet::Runner::next() ()
#7 0x00000000008d9f86 in mongo::QueryPlanSet::Runner::runUntilFirstCompletes() ()
#8 0x00000000008ddc3e in mongo::QueryPlanSet::runOp(mongo::QueryOp&) ()
#9 0x00000000008df5f5 in mongo::MultiPlanScanner::runOpOnce(mongo::QueryOp&) ()
#10 0x00000000008dfaf0 in mongo::MultiCursor::nextClause() ()
#11 0x00000000008e1bcd in mongo::MultiCursor::MultiCursor(char const*, mongo::BSONObj const&, mongo::BSONObj const&, boost::shared_ptr<mongo::MultiCursor::CursorOp>, bool) ()
#12 0x000000000095f542 in mongo::_updateObjects(bool, char const*, mongo::BSONObj const&, mongo::BSONObj, bool, bool, bool, mongo::OpDebug&, mongo::RemoveSaver*) ()
#13 0x00000000009642d5 in mongo::updateObjects(char const*, mongo::BSONObj const&, mongo::BSONObj, bool, bool, bool, mongo::OpDebug&) ()
#14 0x00000000008339cf in mongo::applyOperation_inlock(mongo::BSONObj const&, bool) ()
#15 0x00000000008232cb in mongo::ReplSetImpl::syncApply(mongo::BSONObj const&) ()
#16 0x0000000000826f65 in mongo::ReplSetImpl::syncTail() ()
#17 0x00000000008283e5 in mongo::ReplSetImpl::_syncThread() ()
#18 0x0000000000828438 in mongo::ReplSetImpl::syncThread() ()
#19 0x00000000008288d0 in mongo::startSyncThread() ()
#20 0x0000000000aabd90 in thread_proxy ()
#21 0x00007effd9cd09ca in start_thread () from /lib/libpthread.so.0
#22 0x00007effd927fcdd in clone () from /lib/libc.so.6
Is there some extra magic one needs to use in order to get capped collections to replicate right?

Answer 1

You need to have a unique index on _id for replication to be fast (otherwise it has to do a full table scan for each op on the collection, which is what you're seeing in the trace). The _id index is not created automatically on capped collections. Create the index on your primary and then you may want to resync your secondary: if you had non-unique _ids, it can mess up replication.
Make sure you create a unique index on _id. If you create a non-unique index, it's very difficult to recover from: mongod "protects" this index by not letting you drop it and not letting you create any other index on _id.
See the warning at http://www.mongodb.org/display/DOCS/Capped+Collections#CappedCollections-UsageandRestrictions.