Fix the wrong thread name in the trace profiling function. #385
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Signed-off-by: yaofighting siyao@zju.edu.cn
Fix the thread name error in the trace profiling function, and optimize the segment field in the cycle_queue in collector.
Problem1. Thread name error
Analysis-Probe
When the java probe thread itself generates its own java_futex information for the first time, it enters Probe-side
parse_ jf()
function, at this timeparse_ tm()
thread has not been processed yet, so theptid_comm
map has no thread name information of this thread. However, in the code logic, it only writes the logic to assign the thread name when the thread exists in theptid_comm
map. When the map does not exist, it does nothing. (Therefore, the comm field in kindling_event is actually the comm of the previous data.) like this:if (key != ptid_comm.end()) { strcpy(p_kindling_event->context.tinfo.comm, key->second); }
Analysis-Collector
At this time, the incorrect comm data will enter the
ConsumeEvent ->ConsumeJavaFutexEvent ->PutEventToSegments
logic in the Go side cpuanalyzer to establish the first entry information of the thread. At this time, a ring will be initialized and the thread name information will be initialized. Unless the ring is cleaned up later, the thread name information will not be updated in a timely manner, so it's also a problem in collector.Solution
For theProbe-side, add the default comm data value, and for the Collector-side, ensure that the thread name information is updated every time the ring is updated.
Problem2. Data redundancy in Collector-Segment
optimize the segment field in the cycle_queue in collector.