[SERVER-68978] Log memory allocations triggered by an operation Created: 19/Aug/22 Updated: 28/Aug/23 |
|
| Status: | Backlog |
| Project: | Core Server |
| Component/s: | Logging |
| Affects Version/s: | None |
| Fix Version/s: | None |
| Type: | Improvement | Priority: | Major - P3 |
| Reporter: | Dmitry Ryabtsev | Assignee: | Backlog - Storage Execution Team |
| Resolution: | Unresolved | Votes: | 4 |
| Labels: | allocation, memory | ||
| Remaining Estimate: | Not Specified | ||
| Time Spent: | Not Specified | ||
| Original Estimate: | Not Specified | ||
| Issue Links: |
|
||||||||
| Assigned Teams: |
Storage Execution
|
||||||||
| Participants: | |||||||||
| Description |
|
The current problem in troubleshooting of OOM incidents often boils down to figuring out which operations were responsible for excessive memory allocations. Very often even with knowing the exact operations that were executed at the time of the incident, the memory requirements of those can only be speculated about but never known with a greater degree of confidence. This presents a pain point for the support team. This ticket is raised to explore if it is possible to log memory allocations if those happen as a result of an execution of a particular operation. |
| Comments |
| Comment by Louis Williams [ 02/Sep/22 ] |
|
Another complexity with this idea is that in WiredTiger, one thread may allocate memory that is then freed by another thread. So if we tracked memory allocations, we would not have an accurate picture of how much memory is actually being used by operations. We would potentially want to exclude allocations from within WiredTiger from any reporting. |