经验啦

  1. 首页 > 科技 > >

CPU|龙蜥利器：系统运维工具 SysAK的云上应用性能诊断( 二 )

cpu


系统定时中断
系统定时器过多 ， 也可能会对业务的唤醒造成延迟 ， 通常可以分析业务进程是否有大量的使用高精度定时器 。
软中断
可能是网络流量是否有突发增加等 。
内核线程
其他高优先级应用
2.2、瓶颈
系统内核资源种类繁多 ， 应用模型不同 ， 对内核资源的依赖也不同 ， 所有瓶颈点无法完全覆盖 ， 但至少需要包含几大类常见的内核资源的统计数据：
运行队列长度
这个可以表明是否业务进程/线程并发过多 ， 或者是否绑核不合理等
fs/block 层时延
对于不同的文件系统或设备、IO 调度算法 ， 可能会有不同的瓶颈点 ， 通常需要进行分段统计时延来确定
内存分配延时
受内存水位、碎片的影响 ， 内存分配的时延有时可能会很大
pagefault 时长与频率
内存缺页导致的内存请求、重映射、tlb flush 等对的开销是非常大的 ， 如果频繁的进入到 pagefault 流程中 ， 可以考虑从应用策略上进行优化 ， 比如预分配内存池、使用大页等 。
关键路径 kernel 锁的竞争
锁是不可避免的机制 ， kernel 态锁竞争通常会导致 sys 态的 cpu 升高 ， 需要结合上下文进行具体分析 。
2.3、策略
上述提到内核资源无法完全覆盖 ， 但可以有另外一种方法去能观测一些数据 ， 因为不同的内核策略可能有比较大的性能差异 ， 所以可以尝试通过不同系统间的对比 ， 找出配置的差异点 。 通常的系统配置采集如下：
内核启动参数
内核配置接口 sysctl/procfs/sysfs
内核模块差异
cgroup配置
3、虚拟化
当上述找不到瓶颈点时 ， 或者我们想继续挖掘性能的剩余价值 ， 通常就会到硬件这一侧 ， 而目前业务部署在云上居多 ， 所以在深入硬件层前 ， 虚拟化层或者说主机侧也是绕不开的必要因素 。 对主机侧的性能分析 ， 针对系统内核资源制约可以复用上述的方法 ， 但对业务画像可以少做不少事 ， 相对于应用业务 ， 虚拟化这层的逻辑不会无限变化 ， 我们可以从各个渠道了解到云厂商提供的虚拟化方案 ， 目前主流的是 Linux kvm 方案 。 因此可以针对性的对 kvm 这个方案所所及到的技术点做特别分析 。 此处应该包含的统计包括：
qemu 线程的被抢占频率及时间、guest陷出频率及事件、qemu线程在host上运行的时间
通过这些来综合判断是否是由于虚拟化层带来的性能损失或者是否有改善的可能性 。
4、硬件性能
最后 ， 真正到了硬件层 ， 到这里通常都是由于单纯从应用层或者系统层无法找到更多的优化空间了 。 其实又有两种思路 ， 一种是看看硬件利用率的点 ， 看能否反向调整应用 ， 对硬件使用的热点减少依赖或者分散利用；另一种就是应用无法调整了 ， 评估硬件的性能是否真正已到瓶颈 。 对于前者 ， 又可以延伸出一套方法论来 ， 比如 Ahmed Yasin 的TMAM ， 在 sysAK 中不做过多延伸 ， 但仍然有必要的工作要做 ， 除 cache、tlb miss、cpi 这些数据采集外 ， 更关键的是怎么将这些数据结合应用进程的运行情况进行分析 ， 比如同一 cpu 上的 cache 或带宽竞争多 ， 是由于当前业务自身的程序设计 ， 还是有其他进程存在争抢导致 ， 对于争抢导致的可以通过绑核、rdt 等技术进行配合优化 。
5、交互的应用环境
还没完 ， 这里还少了一个拼图 ， 现在绝大多数应用都不是单机的 ， 交互的应用之间也会产生性能影响 ， 因此在应用画像中 ， 我们曾提到过网络连接的拓扑 ， 就是用于此 。 我们可以将上述所有的性能诊断方法在和当前应用进行交互的对象上复制一遍 。

相关经验推荐


上一篇：VR|疫情当下，足不出户，家用VR多用机，健身减肥娱乐学习一机多用！

下一篇：电子商务|春节期间发挥大作用，ColorOS 12这些实用功能，你用过几个？