Too many thread created for SamplingProfiler |
|||
Issue descriptionWe are receiving slow-reports with too many Sampling thread. This reports "bfe091f490bce065" (see attachment) is having more than 100 threads in the GPU process. ReportID version process_id thread_name amount_of_threads bfe091f490bce065 71.0.3552.2 7048 StackSamplingProfiler 106 39a21cd26ede979c 71.0.3552.2 12224 StackSamplingProfiler 100 d8b2370ce37760f3 71.0.3551.3 589 StackSamplingProfiler 92 1aaaf5092d21ee86 71.0.3553.2 12812 StackSamplingProfiler 85 f9564b819047db50 70.0.3538.16 9736 StackSamplingProfiler 78 52e69dbf260ad1f7 71.0.3554.0 3652 StackSamplingProfiler 69 692e3c96ab822975 71.0.3554.0 10352 StackSamplingProfiler 69 ef0ccb09f8c7b5a8 71.0.3554.0 6024 StackSamplingProfiler 63 7ecb3181f31be864 71.0.3551.3 7000 StackSamplingProfiler 62 453b10b0057d9679 71.0.3554.0 5716 StackSamplingProfiler 55
,
Sep 19
As observed by Erik, a thread that is alive for a short period of time will be in the trace after it's death. These threads are not active at the same time. I'm double checking to confirm, but this may be working as intended.
,
Sep 19
If that were the case, there wouldn't be multiple events on the same thread (after other threads have had some) -- i.e. events would be sequential across all threads
,
Sep 19
exact. There is no multiple sequence of events for a given thread. I don't get your point for "being sequential"? Events are sequential, but the thread ordering is probably random.
,
Sep 19
I mean if the trace looked like this: T1 | T2 | T3 | T4 | then maybe we could make the case that each previous thread was dead before the next one, but that can't be the case here because it looks like: T1 | | T2 | | T3 | | T4 | |
,
Sep 19
I believe that tracing is stateless -- so if a new thread is recreated with the same id as an old thread, it will show up as the same thread in tracing.
,
Sep 19
Oh, possibly if thread ids are reused
,
Sep 19
The StackSamplingProfiler threads typically exist for 60s, long enough collect the stacks plus a delay before exiting in case new collection requests are received. So it seems likely that this is due to tracing seeing a large number of different thread ids for the StackSamplingProfiler, plus some thread id reuse. Assigning to Etienne since he's double checking the data.
,
Sep 20
Closing. This is working as intended.
,
Sep 27
How long was the trace in the OP?! If there should be only one thread at a time for 60s+, we'd need a _really_ long trace to see so many threads.. |
|||
►
Sign in to add a comment |
|||
Comment 1 by gab@chromium.org
, Sep 19