假设EC=2，VP=8，EC利用率为200%，VP利用率为50%。在测试报告中描述CPU利用率为50%（按照CPU为8核计算，其中EC为2C，其他CPU为借用）。
2、最佳实践 交易类测试通常在CPU利用率在70%左右，出具系统能够支撑的最大吞吐量的性能指标。
不宜在CPU过高的情况给出性能数据，生产环境CPU 70%会产生CPU报警。并且，CPU过满的情况下，各类性能数据会产生变形。
不宜在CPU过低的情况给出性能数据，CPU过低的情况下，操作系统和系统软件本身对CPU的消耗占比比较大，若此时统计均摊到每笔业务上的CPU消耗，不太准确。
对于交易类应用，CPU利用率与业务压力（吞吐量）应成近似线性的比例关系。若CPU利用率不能随着吞吐量的增加而增加（如：CPU利用率不能达到70%，最多只能达到30%），需从应用、系统软件、虚拟化配置等方面进行调优。 例如： 1）应用并发线程数量是否过少 2）消息中间件的队列管理器数量过少、传输通道过少、本地队列过少 3）虚拟化参数配置中若VP与EC的比值越大，Hypervisor层面的系统调度开销越大，操作系统获得的CPU时间片越少，CPU利用率无法随着吞吐量的增长而增长，响应时间也会延长。
3、CPU利用率观察取值方法举例 在压力测试过程中随时通过topas命令可以查看CPU的利用率，若没有达到预期的利用率，说明这次测试的压力（吞吐量）没有达到预期，需要马上分析原因，必要时停止测试，以避免无谓的时间浪费。
同时也可以观察Physical CPU是否已经超过EC。若超过了，说明当前分配的EC值过低，此时可考虑联系系统管理员分配更大的EC，以保证能够出具可靠的性能数据（借用资源池的CPU，没有EC保障下的CPU性能好）。
Entc指的是Physical CPU除以EC的比值。如上图，Entc=199.7%，即此时获得的Physical CPU是EC的约2倍。而此时Physical CPU的值为Physc=1.00，因此可以直接推测EC=0.5。
Topas中的user%和kern%与“Nmon CPU_ALL Sheet“中的user%、sys%类似，它们的和不会超过100%。因此读数时要注意实际获得了多少Physical CPU。
User%（用户态CPU利用率）
1、获取来源
Nmon CPU_ALL Sheet：user% 命令行topas：user%
2、最佳实践 对于应用软件在压力测试状态下通常用户态的CPU占比比较高，而系统态占比比较低。用户态可以保护底层硬件资源不直接被程序访问，减少系统crash，所以一般的应用程序跑在用户态的CPU占比大。 Sys%（系统态CPU利用率）
1、获取来源 Nmon CPU_ALL Sheet：sys% 命令行topas：kern%
2、最佳实践 如果系统态占比比较大，一般有以下几类原因： （1）为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见 （2）系统有IO问题 （3）应用设计问题
3、举例 通常情况，压力测试下，用户态（蓝色）和系统态（红色）的CPU图形如下：
系统态偏高如下
这种情况下，如何查看是什么进程、什么库文件、什么函数占用的系统态CPU，后续章节专题介绍。
Wait%
Wait%在不同的场景下含义不同。在CPU的4个细分类型中，Wait%是指CPU等待IO的时间占总时间的百分比。如果在CPU sys态（或kernel态）中的wait%则与此处的wait%含义不同。
1、获取来源
获取来源与Usr%类似
2、最佳实践 Wait%虽然不会统计进CPU总利用率，但仍然是系统CPU性能指标中偶尔关注的指标。
之所以wait%不会统计进CPU总利用率，因为wait%和idle%比较类似，都是CPU闲置状态，只不过一个是等IO，一个是等新的任务。
但如果wait%过大，说明CPU等IO的时间长，系统的处理效率可能比较差。但有时wait%偏高也不构成性能问题，例如，当系统任务较少时，CPU处理一个任务，处理过程中需要等IO，此时就体现在wait%上面；当继续增加压力，CPU接收到新的任务，CPU就不会干等下去，而是去忙着处理别的任务，此时wait%就被压缩了。
Idle% CPU闲置状态即为idle%。
有人把Idle理解为CPU没有任务时的一个占位进程把CPU占满，这个理解是错误的。在这个进程里出现的CPU占用数值并不是真正的占用而是指CPU的空闲率
Idle%越大CPU的耗电越少，BTW，一台计算机的功耗不是恒定的，影响功耗的因素较多，但最主要的因素是CPU闲置还是运行，但尽管如此，Power服务器CPU闲置时仅比跑满状态省电10%左右，后续可以开个章节专门介绍如何测试功耗。
1、获取来源 获取来源与Usr%类似
假设EC=2，VP=8，EC利用率为200%，VP利用率为50%。在测试报告中描述CPU利用率为50%（按照CPU为8核计算，其中EC为2C，其他CPU为借用）。
2、最佳实践 交易类测试通常在CPU利用率在70%左右，出具系统能够支撑的最大吞吐量的性能指标。
不宜在CPU过高的情况给出性能数据，生产环境CPU 70%会产生CPU报警。并且，CPU过满的情况下，各类性能数据会产生变形。
不宜在CPU过低的情况给出性能数据，CPU过低的情况下，操作系统和系统软件本身对CPU的消耗占比比较大，若此时统计均摊到每笔业务上的CPU消耗，不太准确。
对于交易类应用，CPU利用率与业务压力（吞吐量）应成近似线性的比例关系。若CPU利用率不能随着吞吐量的增加而增加（如：CPU利用率不能达到70%，最多只能达到30%），需从应用、系统软件、虚拟化配置等方面进行调优。 例如： 1）应用并发线程数量是否过少 2）消息中间件的队列管理器数量过少、传输通道过少、本地队列过少 3）虚拟化参数配置中若VP与EC的比值越大，Hypervisor层面的系统调度开销越大，操作系统获得的CPU时间片越少，CPU利用率无法随着吞吐量的增长而增长，响应时间也会延长。
3、CPU利用率观察取值方法举例 在压力测试过程中随时通过topas命令可以查看CPU的利用率，若没有达到预期的利用率，说明这次测试的压力（吞吐量）没有达到预期，需要马上分析原因，必要时停止测试，以避免无谓的时间浪费。
同时也可以观察Physical CPU是否已经超过EC。若超过了，说明当前分配的EC值过低，此时可考虑联系系统管理员分配更大的EC，以保证能够出具可靠的性能数据（借用资源池的CPU，没有EC保障下的CPU性能好）。
Entc指的是Physical CPU除以EC的比值。如上图，Entc=199.7%，即此时获得的Physical CPU是EC的约2倍。而此时Physical CPU的值为Physc=1.00，因此可以直接推测EC=0.5。
Topas中的user%和kern%与“Nmon CPU_ALL Sheet“中的user%、sys%类似，它们的和不会超过100%。因此读数时要注意实际获得了多少Physical CPU。
User%（用户态CPU利用率）
1、获取来源
Nmon CPU_ALL Sheet：user% 命令行topas：user%
2、最佳实践 对于应用软件在压力测试状态下通常用户态的CPU占比比较高，而系统态占比比较低。用户态可以保护底层硬件资源不直接被程序访问，减少系统crash，所以一般的应用程序跑在用户态的CPU占比大。 Sys%（系统态CPU利用率）
1、获取来源 Nmon CPU_ALL Sheet：sys% 命令行topas：kern%
2、最佳实践 如果系统态占比比较大，一般有以下几类原因： （1）为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见 （2）系统有IO问题 （3）应用设计问题
3、举例 通常情况，压力测试下，用户态（蓝色）和系统态（红色）的CPU图形如下：
系统态偏高如下
这种情况下，如何查看是什么进程、什么库文件、什么函数占用的系统态CPU，后续章节专题介绍。
Wait%
Wait%在不同的场景下含义不同。在CPU的4个细分类型中，Wait%是指CPU等待IO的时间占总时间的百分比。如果在CPU sys态（或kernel态）中的wait%则与此处的wait%含义不同。
1、获取来源
获取来源与Usr%类似
2、最佳实践 Wait%虽然不会统计进CPU总利用率，但仍然是系统CPU性能指标中偶尔关注的指标。
之所以wait%不会统计进CPU总利用率，因为wait%和idle%比较类似，都是CPU闲置状态，只不过一个是等IO，一个是等新的任务。
但如果wait%过大，说明CPU等IO的时间长，系统的处理效率可能比较差。但有时wait%偏高也不构成性能问题，例如，当系统任务较少时，CPU处理一个任务，处理过程中需要等IO，此时就体现在wait%上面；当继续增加压力，CPU接收到新的任务，CPU就不会干等下去，而是去忙着处理别的任务，此时wait%就被压缩了。
Idle% CPU闲置状态即为idle%。
有人把Idle理解为CPU没有任务时的一个占位进程把CPU占满，这个理解是错误的。在这个进程里出现的CPU占用数值并不是真正的占用而是指CPU的空闲率
Idle%越大CPU的耗电越少，BTW，一台计算机的功耗不是恒定的，影响功耗的因素较多，但最主要的因素是CPU闲置还是运行，但尽管如此，Power服务器CPU闲置时仅比跑满状态省电10%左右，后续可以开个章节专门介绍如何测试功耗。
1、获取来源 获取来源与Usr%类似
2、最佳实践 交易类测试通常在CPU利用率在70%左右，出具系统能够支撑的最大吞吐量的性能指标。
不宜在CPU过高的情况给出性能数据，生产环境CPU 70%会产生CPU报警。并且，CPU过满的情况下，各类性能数据会产生变形。
不宜在CPU过低的情况给出性能数据，CPU过低的情况下，操作系统和系统软件本身对CPU的消耗占比比较大，若此时统计均摊到每笔业务上的CPU消耗，不太准确。
对于交易类应用，CPU利用率与业务压力（吞吐量）应成近似线性的比例关系。若CPU利用率不能随着吞吐量的增加而增加（如：CPU利用率不能达到70%，最多只能达到30%），需从应用、系统软件、虚拟化配置等方面进行调优。 例如： 1）应用并发线程数量是否过少 2）消息中间件的队列管理器数量过少、传输通道过少、本地队列过少 3）虚拟化参数配置中若VP与EC的比值越大，Hypervisor层面的系统调度开销越大，操作系统获得的CPU时间片越少，CPU利用率无法随着吞吐量的增长而增长，响应时间也会延长。
3、CPU利用率观察取值方法举例 在压力测试过程中随时通过topas命令可以查看CPU的利用率，若没有达到预期的利用率，说明这次测试的压力（吞吐量）没有达到预期，需要马上分析原因，必要时停止测试，以避免无谓的时间浪费。
同时也可以观察Physical CPU是否已经超过EC。若超过了，说明当前分配的EC值过低，此时可考虑联系系统管理员分配更大的EC，以保证能够出具可靠的性能数据（借用资源池的CPU，没有EC保障下的CPU性能好）。
Entc指的是Physical CPU除以EC的比值。如上图，Entc=199.7%，即此时获得的Physical CPU是EC的约2倍。而此时Physical CPU的值为Physc=1.00，因此可以直接推测EC=0.5。
Topas中的user%和kern%与“Nmon CPU_ALL Sheet“中的user%、sys%类似，它们的和不会超过100%。因此读数时要注意实际获得了多少Physical CPU。
User%（用户态CPU利用率）
1、获取来源
Nmon CPU_ALL Sheet：user% 命令行topas：user%
2、最佳实践 对于应用软件在压力测试状态下通常用户态的CPU占比比较高，而系统态占比比较低。用户态可以保护底层硬件资源不直接被程序访问，减少系统crash，所以一般的应用程序跑在用户态的CPU占比大。 Sys%（系统态CPU利用率）
1、获取来源 Nmon CPU_ALL Sheet：sys% 命令行topas：kern%
2、最佳实践 如果系统态占比比较大，一般有以下几类原因： （1）为了追求效率，减少用户态到系统态的转换，把用户态的function改到系统态，例如：一些驱动程序，以显卡驱动最为常见 （2）系统有IO问题 （3）应用设计问题
3、举例 通常情况，压力测试下，用户态（蓝色）和系统态（红色）的CPU图形如下：
系统态偏高如下
这种情况下，如何查看是什么进程、什么库文件、什么函数占用的系统态CPU，后续章节专题介绍。
Wait%
Wait%在不同的场景下含义不同。在CPU的4个细分类型中，Wait%是指CPU等待IO的时间占总时间的百分比。如果在CPU sys态（或kernel态）中的wait%则与此处的wait%含义不同。
1、获取来源
获取来源与Usr%类似
2、最佳实践 Wait%虽然不会统计进CPU总利用率，但仍然是系统CPU性能指标中偶尔关注的指标。
之所以wait%不会统计进CPU总利用率，因为wait%和idle%比较类似，都是CPU闲置状态，只不过一个是等IO，一个是等新的任务。
但如果wait%过大，说明CPU等IO的时间长，系统的处理效率可能比较差。但有时wait%偏高也不构成性能问题，例如，当系统任务较少时，CPU处理一个任务，处理过程中需要等IO，此时就体现在wait%上面；当继续增加压力，CPU接收到新的任务，CPU就不会干等下去，而是去忙着处理别的任务，此时wait%就被压缩了。
Idle% CPU闲置状态即为idle%。
有人把Idle理解为CPU没有任务时的一个占位进程把CPU占满，这个理解是错误的。在这个进程里出现的CPU占用数值并不是真正的占用而是指CPU的空闲率
Idle%越大CPU的耗电越少，BTW，一台计算机的功耗不是恒定的，影响功耗的因素较多，但最主要的因素是CPU闲置还是运行，但尽管如此，Power服务器CPU闲置时仅比跑满状态省电10%左右，后续可以开个章节专门介绍如何测试功耗。
1、获取来源 获取来源与Usr%类似
扫一扫
6687
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
