[SERVER-10432] Windows stack trace is very slow Created: 05/Aug/13  Updated: 19/Nov/16  Resolved: 03/Nov/16

Status: Closed
Project: Core Server
Component/s: Diagnostics
Affects Version/s: None
Fix Version/s: 3.4.0-rc3

Type: Bug Priority: Minor - P4
Reporter: Tad Marshall Assignee: Jonathan Reams
Resolution: Done Votes: 0
Labels: None
Remaining Estimate: Not Specified
Time Spent: Not Specified
Original Estimate: Not Specified
Environment:

Windows


Backwards Compatibility: Fully Compatible
Operating System: Windows
Sprint: Platforms 2016-10-31, Platforms 2016-11-21
Participants:

 Description   

Stack traces on Windows take more than half a second, even on fast machines.

You can see the delay in the timestamps in this sample output:

Mon Aug 05 04:33:02.463 *** stack trace for unhandled exception:
Mon Aug 05 04:33:03.340 dbclient_rs_test.exe  ...\src\mongo\client\dbclient_rs_test.cpp(197)                       `anonymous namespace'::UnitTest__AllNodesDown__ReadFromPrimary::_doTest+0x50

This stack trace took 0.877 seconds to generate, which is basically forever for a 3.3 GHz CPU.

The slow code is this line: src/mongo/util/stacktrace.cpp line 183:

        BOOL ret = SymInitialize(process, getSymbolSearchPath(process), TRUE);

The TRUE parameter is "fInvadeProcess":
http://msdn.microsoft.com/en-us/library/windows/desktop/ms681351%28v=vs.85%29.aspx

fInvadeProcess [in]
 
    If this value is TRUE, enumerates the loaded modules for the process and effectively calls the SymLoadModule64 function for each module.

The issue is that there are (on my machine) 33 DLLs mapped into the address space that mongod.exe is running in, and calling SymLoadModule64() for any of them is almost always a waste of time. Essentially every stack trace we print contains only locations in mongod.exe, so the time spent loading symbol information that will not be used is wasted.

The code should instead call SymLoadModule64() for the running .exe file and print only the module name for any address that is not in that file.



 Comments   
Comment by Jonathan Reams [ 03/Nov/16 ]

resolved by SERVER-26270

Comment by Jonathan Reams [ 18/Oct/16 ]

I think this will be fixed by SERVER-26270.

Generated at Thu Feb 08 03:23:09 UTC 2024 using Jira 9.7.1#970001-sha1:2222b88b221c4928ef0de3161136cc90c8356a66.