AIX下查看系统中逻辑和物理cpu的方法
系统中有很多命令可以查看cpu的个数，但是哪个命令输出的是逻辑cpu个数，哪个又是物理cpu个数呢？下面做一个简单的介绍。
从AIX5.3起，对于power5的机器，系统引入了SMT（Simultaneous multi-threading）的功能，其允许两个处理线程在同一颗处理器上运行，对操作系统而言，一颗物理处理器逻辑上会成为两个处理单元（逻辑处理器）。也就是说，在SMT功能启用的情况下，逻辑cpu个数是物理cpu个数的两倍，而在SMT功能禁用的情况下，逻辑cpu个数与物理cpu个数相等。从Power6以后，开始支持四个处理线程在同一颗处理器上运行。
在操作系统中，查看SMT是否开启，可以使用smtctl或者lsattr -El命令查看，如下所示：
接下来分别对Power物理机和虚拟机如何查看CPU做一个详细的介绍：
(一)物理机中查看CPU的方法
1. bindprocessor
# bindprocessor -q
The available processors are: 0 1 2 3 4 5 6 7
可以看到可用逻辑cpu个数是8个（0-7）。
2. prtconf
# prtconf
System Model: IBM,9131-52A
Machine Serial Number: 0677A5G
Processor Type: PowerPC_POWER5
Number Of Processors: 4 ==>物理cpu有4个（如果使用的
是share模式，显示的则是虚拟cpu数量）
Processor Clock Speed: 1648 MHz
CPU Type: 64-bit
Kernel Type: 64-bit
LPAR Info: 1 06-77A5G
3.lsdev
# lsdev -Cc processor
proc0 Available 00-00 Processor
proc2 Available 00-02 Processor
proc4 Available 00-04 Processor
proc6 Available 00-06 Processor
可以看到系统中有4个物理cpu。
4.vmstat
# vmstat
System configuration: lcpu=8 mem=7936MB
kthr memory page faults cpu
----- ----------- ------------------------ ------------ -----------
r b avm fre re pi po fr sr cy in sy cs us sy id wa
1 1 428238 41599 0 0 0 13 25 0 40 1639 182 0 0 99
可以看到系统中有8个逻辑cpu。
5.lparstat
可以看到系统中有32个逻辑CPU，SMT是4。
(二)Power虚拟机中查看CPU的方法
Power虚拟化的时候采用了微分区的技术，这里需要理解下微分区概要文件的设置规则。
2.1分区概要文件 (profile) 设置规则
在创建分区的时候，选择创建Shared CPU 分区，如下图：
在接下来的页面中，需要设置虚拟 CPU 和物理 CPU 的数量：
关于上图几个数值，这里需要详细说明。
在概要文件的设置中，我们既不能将虚拟处理器设置的太多，这样会造成过多的 CPU 上下文切换；也不能将其设置的过低，那样微分区将不能调度或者获取足够的物理 CPU。
物理 CPU 的“最小处理单元数(Minimum processing units)”、“期望处理单元数(Desired processing units)”、“最大处理单元数(Maximum processing units)”的含义与普通 LPAR 没有区别，分别代表“激活分区所需的最少物理 CPU 资源”、“激活分区时期望获取的物理 CPU 资源”、“分区可以获得最多物理 CPU 资源”。
就普通 LPAR 而言，一个分区激活以后，其自动获取的 CPU 资源处于大于等于“最小处理单元数”、小于等于“期望处理单元数”的闭区间内。“最大处理单元数”的设置数值，是手工对分区做 DLPAR 操作时，LPAR 可以增加到的最多 CPU 数量。
虚拟 CPU 的“最小虚拟处理器数”、“期望虚拟处理器数”、“最大虚拟处理器数”的含义分别为：“激活分区所需的最少虚拟 CPU 数量”、“激活分区时期望获取的虚拟 CPU 数量”、“分区可以获得最多虚拟 CPU 数量”。从概念的描述上看，虚拟 CPU 的数值含义似乎无太大的差别，只是多了“虚拟”两个字，实际上区别很大。实际上，虚拟 CPU 的数量我们可以设置的很大，因为这个较大数值不会给客户带来成本，而事实上，虚拟 CPU 实际上也不存在不够用的情况，除非我们将其设置得过小，而共享 CPU 池中的空闲物理 CPU 很多。
另外上图中的Uncapped值如果勾选的话，表示允许CPU超过对应的授权，当微分区的处理能力不足并且所属的Shared processor pool中有剩余的CPU资源时，微分区可以从Shared processor pool自动获取处理器资源来提升处理能力，微分区内的虚拟CPU资源可以自动超过entitled capacity的值（此值为分区启动后分区获得的CPU资源，大于最小值，小于等于期望值）。在我们实际的生产中，topas的时候经常会看到“Entc%”的值超过了100%，就是因为设置了Uncapped。如下例所示, Entc%的值达到189.50%，其entitled capacity为4C，期望虚拟处理器数设置为8C，此分区从共享池中获取了处理器资源来提升处理能力，这里达到了7.58C，因此Entc%=7.58/4=189.50%，超过了100%。
如果Uncapped值未勾选，表示不允许CPU超过对应的授权，即使微分区的处理能力不够，微分区也不会自动的向Shared processor pool获取资源，微分区内的虚拟CPU资源不会自动超过entitled capacity的值。
Uncapped分区的优先级使用权重值(Weight项)来衡量，当多个Uncapped模式的微分区同时争夺Shared processor pool中的CPU资源，并且Shared processor pool中的CPU资源不足以为每个Uncapped模式的微分区分配足够的CPU资源时，Power服务器的Hypervisor通过权重值机制来调配每个分区获得的CPU资源。Weight的范围是0-255,权重值越大，获得CPU资源越多。比如在新一代Power小机中对于VIOS 配置为255，对于AS分区配置为128，对于数据库分区配置为192。
微分区的意义在于降低 CPU 的空闲率，从而降低客户的 IT 成本。因此，在这种情况下，我们通常将对等的虚拟 CPU 的数量设置的比物理 CPU 的数量要高，否则就失去了微分区意义。
Power小型机是有HMC进行管理的，分区的概要文件也是通过HMC的界面去进行配置的，但实际运维过程中，系统管理员访问HMC不是很方便，我们可以使用lparstat –i命令去查看实际的分区概要文件的配置情况，如下所示：
2.2 虚拟机查看CPU的方法
和物理机查看的方法一样，可以使用bindprocessor –q、lsdev -Cc processor、vmstat等命令查看，需要注意的是prtconf查看到的Number Of Processors是对应的虚拟CPU的数量。
使用lparstat命令可以查看到实际使用的物理CPU的数量，如下例中的ent的值为8，表示本台虚拟机使用的实际物理CPU是8C。
其他几项重要的项描述含义如下所示：
- psize 池中在线物理处理器的数量。
- ent 处理器单元中授权处理容量。此信息只在分区类型为共享时显示。
- physc 显示消耗的物理处理器的数量。
- app 显示共享池中可用的物理处理器。
来自社区专栏“平台人生”（http://www.talkwithtrend.com/Column/detail/id/11）
--------------------
了解更多：
CPU不忙，应用程序缓慢，如何能够充分使用CPU？
由于平台基础运维人员不是具体应用开发者，很多时候发现系统CPU利用率不高，应用体验不好，那么我们从哪些方面去定位应用为什么没有充分利用CPU资源，如何才能充分的使用CPU呢？
运维人员如何配合开发诊断问题提供cpu利用率？
杨建旭 中国人民银行清算总中心
说几个原因
1）并发线程数太少。
并发数应该开多少呢？ 假如 你的应用线程是全力干活的线程，没有什么sleep、等IO之类的事情，也就是说，一个线程可以把一个物理CPUthread吃的满满的。那么你的最大并发线程，可以设为略小于服务器的逻辑CPU数量。也就是CPU core* SMT。如果你是虚拟化powervm环境，逻辑CPU=VP*SMT，但虚拟化环境，需要额外注意，如果你要保持高性能，那么建议略小于EC*SMT即可。
2）虚拟化平台的参数配置有问题
比如，某个LPAR，EC=0.5，VP=5，那么很可能，压力来了之后，CPU利用率也上不去，报文严重堆积。因为大部分实际，多花在hypervisor的调度上，以及CPU的cache命中失败，去内存找数据取了。
3）其他各类参数限制导致应用能力被约束，尤其以数据库为甚。
比如应用连接Oracle数据库服务器的JDBC连接数太少，数据库的process太少等等，导致应用在等待数据库。如果单讲数据库的话，以Oracle为例，可以看看awr的top等待事件。
比如logswitch等待时间长，就调整redo日志组数和日志大小。
比如索引等待时间长，可以调整为索引分区。
比如rego日志sync等待时间长，调整存储的能力。
4）应用逻辑设计问题
逻辑设计复杂，流转过程长，导致不能很好的并发利用资源。
可以类比CPU流水原理，CPU设计为什么设置多级流水，而不是一级流水把一个指令执行完？
运维人员可以提供nmon、数据库的监控数据（awr、db2pd等），甚至在授权的情况下开tprof、trace，帮助开发人员分析。
mac2008 科大讯飞
应用体验较差，cpu 利用率不高，个人认为应该检查一下方便：
1、应用程序本身环境变量参数配置，如采用weblogic 要检查java参数配置。
2、检查客户端到服务段网络环境情况，带宽大小。
3、检查服务器端内存使用情况。
guangshi007 广州成翔
这种情况更多的应该考虑应用的问题，而不是CPU的问题。。。。
查应用日志，确定系统处理的瓶颈
ancheng 建设银行北京数据中心
建议深入分析应用每次操作流程中各个阶段的时间消耗分布，找到无用功部分和空闲等待部分，消除这部分无效的等待，保持做有用功才是关键，不要仅仅让cpu白忙
长按二维码关注公众号