[SERVER-51449] Mongodb unusually high iops during fsync mongoversion 3.2.10 Created: 09/Oct/20 Updated: 20/Oct/20 Resolved: 20/Oct/20 |
|
| Status: | Closed |
| Project: | Core Server |
| Component/s: | None |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Question | Priority: | Major - P3 |
| Reporter: | maneesh bhunwal | Assignee: | Edwin Zhou |
| Resolution: | Done | Votes: | 0 |
| Labels: | None | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Participants: |
| Description |
|
we have mongodb with 1 primary and 2 secondaries. On primary node the disk write iops are spiking every minute and latencies go up. It has helped us a lot but still the write iops on 60 qps update are around 1300 in every fsync. I did a test on another mongodb instance, on 1300 qps 363 iop we used during fsync (every 30 sec). the major difference between 2 mongos is the db size. IOPS in my mongo seems like an exceptional. I want to understand how db size impacts write iops during fsync. (In my understanding it should not have). |
| Comments |
| Comment by Edwin Zhou [ 20/Oct/20 ] |
|
c.programming.doubts@gmail.com, I'm happy to hear that you were able to resolve the issue. I'll be closing the ticket as requested. Best, |
| Comment by maneesh bhunwal [ 19/Oct/20 ] |
|
We were able to reproduce the issue on a much smaller data set, hence it seems like a constrain only. I am sorry i can not share any data due to some constrains. Please feel free to close this ticket. Thanks for spending your time on this. |
| Comment by Edwin Zhou [ 19/Oct/20 ] |
|
Hi c.programming.doubts@gmail.com, We still need additional information to diagnose the problem. If this is still an issue for you, would you please archive (tar or zip) the $dbpath/diagnostic.data directory (the contents are described here) and attach it to this ticket? Thanks, Edwin |
| Comment by Edwin Zhou [ 09/Oct/20 ] |
|
Hi c.programming.doubts@gmail.com, Thanks for the information you provided so far. Would you please archive (tar or zip) the $dbpath/diagnostic.data directory (the contents are described here) and attach it to this ticket? |