XeLabs/go-profiler-notes
2
0
Fork 0
mirror of https://github.com/DataDog/go-profiler-notes.git synced 2026-06-21 00:46:51 +08:00
Code Issues Projects Releases Wiki Activity

CPU Profiler: Mention syscalls

Browse source
This commit is contained in:
Felix Geisendörfer 2021-09-10 10:15:15 +02:00
parent 6b9adbfc74
commit 046954caa7
1 changed files with 5 additions and 0 deletions
Show stats Download patch file Download diff file Expand all files Collapse all files

5
guide/README.md
View file

@ -198,6 +198,10 @@ Entering interactive mode (type "help" for commands, "o" for options)
Another popular way to express CPU utilization is CPU cores. In the example above the program was using an average of `1.47` CPU cores during the profiling period. Another popular way to express CPU utilization is CPU cores. In the example above the program was using an average of `1.47` CPU cores during the profiling period.
⚠️ Due to one of the known issues below you shouldn't put too much trust in this number if it's near or higher than `250%`. However, if you see a very low number such as `10%` this usually indicates that CPU consumption is not an issue for your application. A common mistake is to ignore this number and start worrying about a particular function taking up a long time relative to the rest of the profile. This is usually a waste of time when overall CPU utilization is low, as not much can be gained from optimizing this function. ⚠️ Due to one of the known issues below you shouldn't put too much trust in this number if it's near or higher than `250%`. However, if you see a very low number such as `10%` this usually indicates that CPU consumption is not an issue for your application. A common mistake is to ignore this number and start worrying about a particular function taking up a long time relative to the rest of the profile. This is usually a waste of time when overall CPU utilization is low, as not much can be gained from optimizing this function.
### System Calls in CPU Profiles
If you see system calls such as `syscall.Read()` or `syscall.Write()` using a lot of time in your CPU profiles, please note that this is only the CPU time spend inside of these functions in the kernel. The I/O time itself is not being tracked. Spending a lot of time on system calls is usually a sign of making too many of them, so perhaps increasing buffer sizes can help. For more complicated situations like this, you should consider using Linux perf, as it can also show you kernel stack traces that might provide you with additional clues.
### Known CPU Profiler Issues ### Known CPU Profiler Issues
There are a few known issues and limitations of the CPU profiler that you might want to be aware of: There are a few known issues and limitations of the CPU profiler that you might want to be aware of:
@ -225,5 +229,6 @@ Notes:
- Reducing Costs: Talk about CPU, Memory and Networking. Is it possible to profile the latter? - Reducing Costs: Talk about CPU, Memory and Networking. Is it possible to profile the latter?
- pprof: Maybe host a service to convert perf.data files into pprof files? - pprof: Maybe host a service to convert perf.data files into pprof files?
- Reuse cute gophers from conf talks. - Reuse cute gophers from conf talks.
- pprof cli tips from rhys h. on gopher slack: Favorite options include edgefraction=0, nodefraction=0, and nodecount of something larger than 80 (but rendering gets slow). Plus focus, and an ever-growing regexp (as I dive in to the profile) in ignore.
--> -->