[SERVER-31399] repl.apply.batches.totalMillis does not record the time spent applying batches Created: 05/Oct/17 Updated: 30/Oct/23 Resolved: 16/Feb/18 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | Diagnostics, Replication |
| Affects Version/s: | 3.4.4, 3.5.13 |
| Fix Version/s: | 3.4.14, 3.6.4, 3.7.3 |
| Type: | Bug | Priority: | Major - P3 |
| Reporter: | Bruce Lucas (Inactive) | Assignee: | Vesselina Ratcheva (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | SWDI, neweng | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||||||||||||||
| Backwards Compatibility: | Fully Compatible | ||||||||||||||||||||
| Operating System: | ALL | ||||||||||||||||||||
| Backport Requested: |
v3.6, v3.4
|
||||||||||||||||||||
| Sprint: | Storage 2018-01-01, Repl 2018-01-15, Repl 2018-01-29, Repl 2018-02-12, Repl 2018-02-26 | ||||||||||||||||||||
| Participants: | |||||||||||||||||||||
| Description |
|
This behavior was observed in 3.4.4 (at least). The reason is that TimerHolder is declared here in applyOps, but applyOps doesn't wait for the batch to finish. This can be solved by moving TimerHolder to this block which does wait for the batch to finish. This would need to be done at each place where applyOps is called. This makes it difficult to determine whether the node is under heavy replication load and to diagnose issues related to that. |
| Comments |
| Comment by Githook User [ 01/Mar/18 ] |
|
Author: {'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}Message: (cherry picked from commit d9038eb6236a7351addf8a58ce204be575bcb079)
(cherry picked from commit 04cc084048a5f37c9d10ee3bac9dbef1e89672c5) |
| Comment by Githook User [ 01/Mar/18 ] |
|
Author: {'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}Message: (cherry picked from commit d9038eb6236a7351addf8a58ce204be575bcb079)
(cherry picked from commit 04cc084048a5f37c9d10ee3bac9dbef1e89672c5) |
| Comment by Githook User [ 16/Feb/18 ] |
|
Author: {'email': 'vesselina.ratcheva@10gen.com', 'name': 'Vesselina Ratcheva', 'username': 'vessy-mongodb'}Message: |
| Comment by Bruce Lucas (Inactive) [ 06/Oct/17 ] |
|
I think moderate importance. If the information were missing entirely it might be less than that, but as it is the metric is present but incorrect (whereas I believe it used to be correct), and that has led to some misdirection and delay. If 3.6.0 isn't possible early 3.7 with a backport to 3.6 (and maybe 3.4, if the fix is as simple as it appears to me) would be helpful. |
| Comment by Spencer Brody (Inactive) [ 06/Oct/17 ] |
|
bruce.lucas, can you provide any guidance as to the severity of this issue and how much burden it places on the support team to help us prioritize the work? |