软件性能测试(连载8)

简介: 软件性能测试(连载8)
10)上下文切换

CPU依次处理上述任务的调度方法是切换。切换分为“进程切换”“线程切换”和“中断切换”。中断切换即在本节“软中断与硬中断”中提及的,当系统中有非常重要的请求来临,CPU停止手头工作,触发硬中断。“进程切换”和“线程切换”,在切换前都要调取上次保存的信息,在切换后都要保存当前的信息。“进程切换”和“线程切换”合在一起叫做上下文切换(context switches)。图3-21为当前仅有2个任务等待CPU处理下的进程下文切换。

image.png

3-21  进程上下文切换

由此可见上下文切换的优点在于,每个进(线)程具有同等的CPU处理权利,缺点是进(线)程的保存和载入消耗资源。由于线程信息比进程信息要少,所以线程上下文切换优于进程上下文切换。等待的进(线)程,位于CPU的最外层Ring3,而当前正在处理的进(线)程位于CPU内核,即Ring0,如图3-22所示。

image.png

3-22  等待CPU处理的进程和正在CPU处理的进程所处CPU位置


可以通过命令vmstat interval count来查看CPU的中断数和进线程上下文切换数。在这里interval为多长描述输出一次,count为总共输出的次数。比如:“vmstat5 3”表示每5s输出一次,总共输出3次。

#vmstat 1 1

procs -----------memory---------- ---swap-- -----io-----system-- ------cpu-----

r  b  swpd   free     buff cache   si   so   bi    bo   in  cs  us  sy id wa st

0  0  0      7005360  91564 818900 0    0     0    0    25   33  0    0  1000  0


这里的输出含义见表3-6所示。


3-6 vmstat命令输出详解

总标识

标识

意义

process

r

展示了正在执行和等待CPU资源的任务个数。当这个值超过了CPU个数,就会出现CPU瓶颈

b

每秒VMM等待队列的核心线程平均数

system

in

在某一段时间间隔中观察到的每秒设备中断数

cs

在某一段时间间隔中观察到的每秒上下文切换数

CPU

us

用户方式下花费的百分比

sy

系统方式下执行一个进程花费的百分比

id

没有使用本地磁盘I/OCPU空闲或等待时间百分比

wa

等待I/O CPU时间百分比


Systemcs就表述在某一段时间间隔内每秒上下文切换的个数。上下文切换又分为自愿上下文切换(voluntary context switches)和非自愿上下文切换(non voluntary context switches)两种。自愿上下文切换是指到了切换时间点,进(线)程由于所需的资源不足,比如没有获得进(线)程处理所需的数据而资源CPU让出去,去处理其他进(线)程而非自愿上下文切换是指指到了切换时间点,没有数据资源不足的情形发生,此进(线)程不得不把CPU资源让出来去处理其他正在等待的进(线)程。所以当自愿上下文切换比较多,说明I/O或者内存存在瓶颈;而非自愿上下文切换比较多,说明目前有很多进(线)程需要CPU处理。可以通过命令pidstat(需要安装sysstat插件)查看自愿上下文切换和非自愿上下文切换。


#每隔 5 秒输出 1 组数据
#pidstat -w 5
Linux 4.15.0 (ubuntu)  09/23/18 _x86_64_  (2 CPU)
08:18:26     UID       PID   cswch/snvcswch/s  Command
08:18:31       0         1    0.20    0.00        systemd
08:18:31       0         8    5.40    0.00        rcu_sched
...


这里的cswch/snvcswch/s就表示每秒自愿上下文切换和非自愿上下文切换个数。


11perf topperf record命令

perf top命令可以显示占用 CPU 时钟最多的函数或者指令,因此可以用来查找热点函数。如图3-23所示。

image.png

3-23  perf top


perf top 虽然实时展示了系统的性能信息,但它的缺点是并不保存数据,也就无法用于离线或者后续进行分析。

perf record 则提供了保存数据的功能,保存后的数据,需要用 perf report 解析展示。

注意:并不是所有的函数或指令都可以用perf topperf record获得的。


12)短时进程

对于一些仅存在几毫秒的进程,当数量很大的时候也会给CPU带来很大的负载,而这些进程基本上用topps命令很难被获取到,这个时候就需要使用execsnoop命令了。这个命令工具可以通过https://github.com/brendangregg/perf-tools/blob/master/execsnoo获得。


13)显示10个消耗CPU最多的进程

可以通过ps aux|sort -rnk +3|head -10查看10个消耗CPU最多的进程。

#ps aux|sort -rnk +3|head -10
USER       PID  %CPU %MEM    VSZ  RSS   TTY      STAT START   TIME COMMAND
root        99   0.0  0.0     0    0?     S        08:18         0:00 [scsi_eh_20]
root        98   0.0  0.0    0     0?     S         08:18         0:00 [scsi_eh_19]
root        97    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_18]
root        96    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_17]
root        95    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_16]
root        94    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_15]
root        93    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_14]
root        92    0.0 0.0     0    0?     S         08:18         0:00 [scsi_eh_13]
root        91    0.0  0.0   0     0?     S         08:18         0:00 [scsi_eh_12]


14)在多CPU的系统里,查看所有CPU的信息

可以使用mpstat查看多CPU的系统里中的信息。

#mpstat
Linux 4.15.0-46-generic(ubuntu) 10/30/2019 _x86_64_(4 CPU)
02:59:04 AM CPU  %usr %nice   %sys   %iowait %irq   %soft  %steal %guest  %gnice   %idle
02:59:04 AM  all 15.29 4.91   17.24  2.76     0.00   1.08     0.00  0.00    0.00     58.71


15)小结

本节所涉及的概念有CPU负载、CPU使用率、不可中断的睡眠态进程、僵尸进程、CPU状态转换、软中断与硬中断、CPU节拍率和上下文切换。涉及到的命令有uptime/proc/cpuinfotopdstatpstree/proc/softirqsps aux | grep softirqwatchsar -n DEV 1grep 'CONFIG_HZ=' /boot/config-$(uname -r)vmstatpidstatperf topperf recordexecsnoopps aux|sort -rnk +3|head -10 mpstat

相关实践学习
通过性能测试PTS对云服务器ECS进行规格选择与性能压测
本文为您介绍如何利用性能测试PTS对云服务器ECS进行规格选择与性能压测。
目录
相关文章
|
4天前
|
XML 数据管理 测试技术
深入探索软件自动化测试框架的设计与实现
【4月更文挑战第26天】 随着软件开发周期不断缩短,传统的手动测试方法已难以满足快速迭代的需求。本文聚焦于自动化测试框架的构建与优化,旨在提供一种高效、可维护且可扩展的软件测试解决方案。文章从自动化测试的必要性出发,详细阐述了自动化测试框架设计的核心要素,包括模块化设计、数据驱动测试以及关键词驱动测试等概念。同时,结合实例分析了如何利用流行的测试工具进行框架搭建,并提出了针对常见问题的创新解决方法。最后,通过案例研究展示了该框架在实际项目中的应用效果和潜在改进空间。
|
4天前
|
设计模式 测试技术 持续交付
深入白盒测试:提升软件质量与性能的关键策略
【4月更文挑战第20天】 在软件开发的复杂世界中,确保产品的质量和性能始终是至关重要的任务。白盒测试,作为软件测试领域的重要分支,提供了对程序内部结构和逻辑的深入分析手段。本文将探讨如何通过有效的白盒测试策略来优化软件性能,减少缺陷,并最终提高用户满意度。通过剖析代码检查、单元测试、集成测试等白盒测试技术,我们将了解这些方法如何揭示潜在的问题点,并为改进提供方向。
|
3天前
|
设计模式 前端开发 测试技术
软件质量的守门人——接口测试
接口作为API,是后端预定义的函数,用于系统间通信和数据交换。接口测试验证不同组件间的交互,确保其准确、可靠。常见应用场景包括集成测试、版本迭代测试、性能测试、安全测试和错误场景测试。随着服务端复杂性的增加,传统测试方法面临挑战,因此引入分层测试(如马丁福勒的测试金字塔模型)和自动化测试,以降低成本并提高效率。接口测试成为确保后端服务质量的关键,学习接口测试可从理解其价值、协议、工具使用及Mock测试等方面逐步进阶。
4 1
|
4天前
|
机器学习/深度学习 人工智能 自然语言处理
深入探索软件自动化测试的未来趋势
【5月更文挑战第12天】 随着软件开发周期的不断缩短和市场需求的快速变化,传统的手动测试方法已经难以满足现代软件质量保证的需求。自动化测试作为一种高效、可靠的解决方案,正逐渐成为行业标配。本文将深入探讨自动化测试的最新发展,分析其在持续集成/持续部署(CI/CD)环境中的作用,以及人工智能(AI)如何重塑测试实践。同时,我们还将展望自动化测试工具和技术的未来演进路径。
|
4天前
|
机器人 测试技术 语音技术
LabVIEW使用软件定义进行汽车电子测试
LabVIEW使用软件定义进行汽车电子测试
12 0
|
4天前
|
程序员 测试技术
程序员难以一次性写好代码并持续修复Bug,主要源于软件的高复杂性、需求不确定性、测试局限性和技术能力限制。
【5月更文挑战第11天】程序员难以一次性写好代码并持续修复Bug,主要源于软件的高复杂性、需求不确定性、测试局限性和技术能力限制。复杂的系统易产生意外问题,需求变化导致初始设计难完备,测试无法覆盖所有情况,而技术更新和个体能力差异也会引入错误。因此,持续调试和优化是保证软件质量的关键步骤。
16 0
|
4天前
|
人工智能 大数据 测试技术
深入探索软件自动化测试的未来
【5月更文挑战第8天】随着科技的不断发展,软件测试领域正经历着前所未有的变革。本文将深入探讨软件自动化测试的现状与未来,从人工智能、大数据和云计算等方面分析其对软件测试的影响,以及如何利用这些技术提高测试效率和质量。
|
4天前
|
机器学习/深度学习 人工智能 算法
深入探索软件自动化测试的优化策略
【5月更文挑战第4天】 随着软件开发周期的不断缩短和发布频率的增加,传统的手动测试方法已无法满足快速迭代的需求。因此,本文聚焦于自动化测试流程的优化,旨在提高测试效率和质量。文章首先回顾了自动化测试的基本概念与实施条件,随后分析了当前自动化测试面临的主要挑战,包括维护成本高、测试用例设计复杂等问题。在此基础上,提出了一系列优化策略:持续集成环境下的自动化测试、数据驱动测试、关键字驱动测试、以及基于人工智能的测试用例生成和维护等。通过案例分析和性能评估,验证了这些策略在提升测试覆盖率和减少人工干预方面的有效性。
|
4天前
|
机器学习/深度学习 敏捷开发 人工智能
探索软件自动化测试的未来趋势
【5月更文挑战第4天】 在快速发展的信息时代,软件已成为支撑现代社会运行的核心力量。随之而来的是软件测试领域面临的挑战和机遇,特别是自动化测试技术。本文将深入探讨自动化测试的最新发展,分析其对提高软件开发效率、降低维护成本的重要性,同时预测未来可能的技术趋势。通过实际案例分析和最新研究动态的梳理,旨在为读者呈现一个清晰的自动化测试技术蓝图。
|
4天前
|
测试技术 持续交付 数据安全/隐私保护
深入理解软件自动化测试中的数据驱动策略
【5月更文挑战第1天】 在软件测试领域,自动化测试已经成为提高测试效率和质量的重要手段。其中,数据驱动测试(DDT)作为一种高效实施自动化测试的策略,允许测试用例与测试数据分离,增强了测试脚本的可维护性和灵活性。本文将详细探讨数据驱动测试的核心概念、实现方式以及在实际中的应用案例,帮助读者更深入地理解如何利用数据驱动策略优化自动化测试流程。

热门文章

最新文章