-
Type: Task
-
Resolution: Done
-
Priority: Major - P3
-
None
-
Affects Version/s: None
-
Component/s: Internal Code
-
Service Arch
-
Service Arch 2024-03-18, Service Arch 2024-04-01
Running a simple ready-only workload and collecting the frequency of branch and icache misses (using the command below) shows that more than 30% of branches are not correctly predicted:
perf record -e branch-misses,br_mis_pred ./build/install/bin/mongod
Looking at the collected profile, many of the missed branches are on the command path (i.e. ServiceEntryPoint), and many point to the function call that checks if a log statement should be emitted:
... if (shouldLog(logv2::LogComponent::kTracking, logv2::LogSeverity::Debug(1)) && rpc::TrackingMetadata::get(opCtx).getParentOperId()) { rpc::TrackingMetadata::get(opCtx).initWithOperName(command->getName()); LOGV2_DEBUG_OPTIONS(4615605, 1, {logv2::LogComponent::kTracking}, "Command metadata", "trackingMetadata"_attr = rpc::TrackingMetadata::get(opCtx)); rpc::TrackingMetadata::get(opCtx).setIsLogged(true); } }
For example, the above shows up very high on the list of missed branches when running a multi-threaded, read-only Genny workload that issues findOne for a small document:
This ticket should investigate the performance implications of logging, in particular its effects on icache and branch misses. It can estimate the maximum gains by disabling all logs on the hot path (compiling them out).
- related to
-
SERVER-88481 Remove TrackingMetadata log in ServiceEntryPointCommon
- Closed