Closed withlin closed 7 months ago
@maoni0 @jkotas @noahfalk Links to advice?
the stack you are showing in lldb doesn't make a whole of sense (eg, gc_heap::background_written_addresses is just an array). would it be possible to fix the symbols?
but assuming the 4 frames you highlighted are showing correct symbols, this is not the same thread that's shown in perf. in perf you are showing a threadpool thread which cannot be a server GC thread which is what the lldb stack is showing. also the stack in lldb most likely just says there's no GC's happening so that GC thread is blocked.
in general we recommend folks to collect CLR events with this kind of investigation. looping in @billwert. Bill, would you have time to help with this investigation?
Hi @Maoni0,thank you for your reply,it is my first time using lldb.I am not very familiar with its usage, I try to dump the stack again. Have you any tools view hight cpu problem in linux?
Hi @withlin!
We have docs for Linux performance tracing here. If you take a trace with perfcollect and share it somewhere, we can take a look at what's going on.
hi @billwert
i have fllow the doc,which is not tracing. excuete log :
root@zd:~# docker exec -it --privileged c50032b01447 /bin/bash
root@c50032b01447:/tmp# ./perfcollect collect sampleTrace
Collection started. Press CTRL+C to stop.
...STOPPED.
Starting post-processing. This may take some time.
zero-sized file (perf.data), nothing to do!
Generating native image symbol files
zero-sized file (perf.data), nothing to do!
libcoreclr.so not found in perf data. Please verify that your .NET Core process is running and consuming CPU.
Saving native symbols
zero-sized file (perf.data), nothing to do!
...FINISHED
Exporting perf.data file
...FINISHED
Compressing trace files
...FINISHED
Cleaning up artifacts
...FINISHED
Trace saved to sampleTrace.trace.zip
link issue how to fix it ? Would you tell me? Tks.
This issue will now be closed since it had been marked no-recent-activity
but received no further activity in the past 14 days. It is still possible to reopen or comment on the issue, but please note that the issue will be locked if it remains inactive for another 30 days.
In our production environment, our webapi which it is several delays in an hour, such as: 6s 8s, even 11s(only read redis and then resonse data). So I try to see the load on the server
1.some Env:
The pid of 27824,which it is hight cpu(89.4%). sometimes it will rise to 150%。 The average CPU is 89.4%
use perf tool view it:
use lldb view it:
so i have some assumption: 1.Whether the program hangs because of garbage collection, and then waits for the garbage to be collected before responding.(such as: 6s 8s, even 11s(only read redis and then resonse data).) 2.The current sdk version is still very low( 2.1.2.), I don't know if it is a problem with the sdk version?