我有一个程序,它从共享内存读取数据并以单线程方式将其发送到非阻塞套接字。当我将流量推送到该应用程序时,我只能看到 TOP CPU 百分比约为 60%,并且不会更高,即使我泵入共享内存的数据也在生产者端溢出。
我想了解这 60% 是否是真正的极限,或者是一些需要优化的可疑行为。
以下是我对问题的分析:
- 顶级 CPU 是否包括与套接字发送/接收 API 相关的内核函数执行时间?
- 我正在使用阻塞模式的 epoll,并且顶级 CPU 是否将阻塞时间视为繁忙时间?(可能不是,但想确认一下)
- (不直接相关)如果我使用阻塞套接字,顶级 CPU 是否会将阻塞时间视为繁忙时间?
答案1
来自以下进程的“%CPU 字段”定义top 的手册页:
该任务自上次屏幕更新以来所占的 CPU 时间份额,以占总 CPU 时间的百分比表示。
“CPU 时间”的定义来自维基百科
CPU 时间(或处理时间)是中央处理单元 (CPU) 用于处理计算机程序或操作系统指令的时间。
问题
- 顶级 CPU 是否包括与套接字发送/接收 API 相关的内核函数执行时间?
- 我正在使用阻塞模式的 epoll,并且顶级 CPU 是否将阻塞时间视为繁忙时间?(可能不是,但想确认一下)
- (不直接相关)如果我使用阻塞套接字,顶级 CPU 是否会将阻塞时间视为繁忙时间?
问题 2 和 3 的答案
阻塞时间不计入 %CPU,因为“CPU 时间”定义为在 CPU 上执行指令所花费的时间。
问题 1 的答案
根据维基百科CPU 时间是“用户 CPU 时间”和“系统 CPU 时间”的总和。
我们期望代表进程的内核模式执行时间和进程的用户模式执行时间都计入 %CPU 的计算中。为了测试是否是这种情况,您可以运行一个系统时间使用量很大的进程,并通过 top 检查该进程的 %CPU,我曾在博客文章。
$ dd if=/dev/zero of=/dev/null bs=65536
Cpu(s): 0.2%us, 12.8%sy, 0.0%ni, 87.0%id, 0.0%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 16330524k total, 7869052k used, 8461472k free, 464240k buffers
Swap: 18563064k total, 0k used, 18563064k free, 6716724k cached
PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
29937 user 20 0 102m 724 564 R 99.7 0.0 0:13.40 dd
在同一篇博文中,作者检查了以下实现的源代码:顶部Linux 和 OpenBSD 的实用程序,我建议你也去看看那里。