我知道[1]。通过几行代码,我只想从CPU使用率最高的前n个进程中提取当前的CPU使用率。或多或少是top的前5行。使用 github.com/shirou/gopsutil/process 这很简单:
// file: gotop.go
package main
import (
"log"
"time"
"sort"
"github.com/shirou/gopsutil/process"
)
type ProcInfo struct{
Name string
Usage float64
}
type ByUsage []ProcInfo
func (a ByUsage) Len() int { return len(a) }
func (a ByUsage) Swap(i, j int) { a[i], a[j] = a[j], a[i] }
func (a ByUsage) Less(i, j int) bool {
return a[i].Usage > a[j].Usage
}
func main() {
for {
processes, _ := process.Processes()
var procinfos []ProcInfo
for _, p := range processes{
a, _ := p.CPUPercent()
n, _ := p.Name()
procinfos = append(procinfos, ProcInfo{n, a})
}
sort.Sort(ByUsage(procinfos))
for _, p := range procinfos[:5]{
log.Printf(" %s -> %f", p.Name, p.Usage)
}
time.Sleep(3 * time.Second)
}
}
虽然此实现中的刷新率 gotop 与 top 一样为 3 秒,但 gotop 的刷新率约为 3 秒。像 top 那样获取这些值对 CPU 使用率的要求高出 5 倍。有什么技巧可以更有效地读取 5 个最消耗的进程吗?我还尝试找到 top 的实现,看看它是如何实现的。
psutils 是造成这种速度减慢的原因吗?我发现 cpustat 也在 GO 中实现。但即使
sudo ./cpustat -i 3000 -s 1
似乎也没有top
那么有效。
主要动机是用相当少量的计算量来监控当前机器的使用情况,以便它可以作为服务在后台运行。
看来,甚至htop也只是阅读/proc/stat。
编辑 正如评论中所建议的,这是分析时的结果
Showing top 10 nodes out of 46 (cum >= 70ms)
flat flat% sum% cum cum%
40ms 40.00% 40.00% 40ms 40.00% syscall.Syscall
10ms 10.00% 50.00% 30ms 30.00% github.com/shirou/gopsutil/process.(*Process).fillFromStatusWithContext
10ms 10.00% 60.00% 30ms 30.00% io/ioutil.ReadFile
10ms 10.00% 70.00% 10ms 10.00% runtime.slicebytetostring
10ms 10.00% 80.00% 20ms 20.00% strings.FieldsFunc
10ms 10.00% 90.00% 10ms 10.00% syscall.Syscall6
10ms 10.00% 100% 10ms 10.00% unicode.IsSpace
0 0% 100% 10ms 10.00% bytes.(*Buffer).ReadFrom
0 0% 100% 70ms 70.00% github.com/shirou/gopsutil/process.(*Process).CPUPercent
0 0% 100% 70ms 70.00% github.com/shirou/gopsutil/process.(*Process).CPUPercentWithContext
似乎系统调用需要很长时间。树堆在这里: https://gist.github.com/PatWie/4fa528b7d7b1d0b5c1b665c056671477
这将问题变成: - 系统调用有问题吗? - 是否有
top
程序的 c 源代码?我刚刚找到了 htop 的实现
- 有简单的解决办法吗?我考虑用 c 语言编写,然后将其包装起来供 go 使用。
github.com/shirou/gopsutil/process
使用 ioutil.ReadFile
访问文件系统的效率低于 top。特别是ReadFile
:
Stat
,这会添加额外的不必要的系统调用。os.Open
而不是 unix.Openat
+ os.NewFile
,这会导致在解析路径时需要额外的内核时间遍历 /proc
。 os.NewFile
仍然有点低效,因为它总是检查文件描述符是否是非阻塞的。直接使用 golang.org/x/sys/unix
或 syscall
包可以避免这种情况。在 Linux 下检索进程详细信息通常效率相当低(大量文件系统扫描、编组文本数据)。但是,您可以通过修复文件系统访问(如上所述)来使用 Go 实现与
top
类似的性能。