Update $set vs document replacement operations

Ops and Admin
1

I’m facing a completely different behaviour on a data node between $set and document replacement operations.
Whenever I use $set, there is a huge spike of WiredTiger cache eviction plus an increase of read IOPS. If I replace the document, I don’t see this behaviour.
Note: the $set is not setting any array field.

Can someone please help me to understand the different behaviour? Is it due to the fact that document replacement doesn’t pull the document into memory?

Thanks!

2

It would be helpful to have more details. For instance: what version of MongoDB? Default settings? Replica set? Size of document? Exact $set clause? Single document update? What’s the query? Both updates would be most useful.

3

Hi @Asya_Kamsky, thanks for your reply.
We have found the problem and it was definitely not related with $set operation. The fact that we saw different behaviour was that working set was not fitting in memory due to another big index that we added to accommodate a new operation for the $set operation.
Once we dropped the old index, performance went back to previous numbers.

1 Like