[SERVER-3357] disk/yield lock - any update Created: 01/Jul/11 Updated: 12/Jul/16 Resolved: 07/Jan/12 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Concurrency |
| Affects Version/s: | None |
| Fix Version/s: | 2.1.0 |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Eliot Horowitz (Inactive) | Assignee: | Eliot Horowitz (Inactive) |
| Resolution: | Done | Votes: | 13 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||
| Participants: | |||||||||||||
| Comments |
| Comment by Eliot Horowitz (Inactive) [ 07/Jan/12 ] |
|
This was done as part of |
| Comment by Eliot Horowitz (Inactive) [ 10/Dec/11 ] |
|
Are you sure they query isn't page faulting? |
| Comment by Benedikt Waldvogel [ 10/Dec/11 ] |
|
Could you explain your comment in more detail? Why should the query yield? 100% of the data are in RAM so the query usually finishes in 0.x ms. |
| Comment by Eliot Horowitz (Inactive) [ 10/Dec/11 ] |
|
I think that's the opposite problem, queries not yielding making the update slow. |
| Comment by Benedikt Waldvogel [ 10/Dec/11 ] |
|
Today I had an update by-id (fsync safe) that took 1.5s: Sat Dec 10 03:51:17 [conn958] update db.collection query: { _id: 415293937 }update: { _id: 415293937, ... }idhack:1 1554ms Exactly at that time I had simple queries by-id running. One of them took 721 ms, another took 1415 ms. Server version: 2.0.1, Linux 64 bit. This happens a few times per day when the number of updates is high. |
| Comment by Scott Hernandez (Inactive) [ 31/Aug/11 ] |
|
Yes, it will. The upsert (true) option changes the update to do an insert if the query results in no document(s) found; it is still an "update" in the write sense. |
| Comment by Chris Griego [ 31/Aug/11 ] |
|
Does this cover upserts? |