什么电力pmu

PMU是power management unit的缩写，中文名称为电源管理单元，是一种高度集成的、针对便携式应用的电源管理方案，即将传统分立的若干类电源管理器件整合在单个的封装之内，这样可实现更高的电源转换效率和更低功耗，及更少的组件数以适应缩小的板级空间。

扩展资料：

一、测试单元：

电力系统同步相量测量装置 Phasor Measurement Unit (PMU)用于进行同步相量的测量和输出以及进行动态记录的装置。

PMU的核心特征包括基于标准时钟信号的同步相量测量、失去标准时钟信号的守时能力、PMU与主站之间能够实时通信并遵循有关通信协议。

现有PMU大多依靠美国的GPS系统进行授时，部分设备已经开始采用GPS和北斗系统双对时。

二、驱动模式和测量模式

在ATE中，术语“驱动（Force）”描述了测试机应用于被测器件的一定数值的电流或电压，它的替代词是Apply，在半导体测试专业术语中，Apply和Force都表述同样的意思。

在对PMU进行编程时，驱动功能可选择为电压或电流：如果选择了电流，则测量模式自动被设置成电压；反之，如果选择了电压，则测量模式自动被设置成电流。一旦选择了驱动功能，则相应的数值必须同时被设置。

参考资料来源：百度百科－PMU

在NUMA架构出现前，CPU欢快的朝着频率越来越高的方向发展。受到物理极限的挑战，又转为核数越来越多的方向发展。如果每个core的工作性质都是 share-nothing （类似于map-reduce的node节点的作业属性），那么也许就不会有NUMA。

早期SMP由于所有CPU Core都是通过共享一个北桥来读取内存，随着核数如何的发展，北桥在响应时间上的性能瓶颈越来越明显 。先到了把内存控制器（IMC） （原本北桥中读取内存的部分） 也做个拆分，平分到了每个CPU上，于是NUMA就出现了！

NUMA中，虽然内存直接attach在CPU上，但是由于内存被平均分配在了各个CPU上 。只有当CPU访问自身直接attach内存对应的物理地址时，才会有较短的响应时间（后称Local Access）。而如果需要访问其他CPU attach的内存的数据时，就需要通过inter-connect（Hyper-Transfer）通道访问，响应时间就相比之前变慢了（后称Remote Access）。所以NUMA（Non-Uniform Memory Access）就此得名。

从网上盗图了一张NUMA架构的涉及关系： 图源网址

几乎所有NUMA + MySQL关键字的搜索结果都会指向：Jeremy Cole大神的两篇文章

大神解释的非常详尽，有兴趣的读者可以直接看原文。

从网上盗图了一张NUMA架构的涉及关系：[图源网址]

Jeremy Cole大神推荐的三个方案如下，如果想详细了解可以阅读 原文

这三个方案也被业界普遍认可可行，同时在 Twitter 的5.5patch 和 Percona 5.5 Improved NUMA Support 中作为功能被支持。

不过这种三合一的解决方案只是减少了NUMA内存分配不均，导致的MySQL SWAP问题出现的可能性。如果当系统上其他进程，或者MySQL本身需要大量内存时，Innodb Buffer Pool的那些Page同样还是会被Swap到存储上。于是又在这基础上出现了另外几个进阶方案

如果能对于这把这部分内存集中到这些内存线程 所在的core上的时候，就能减少大量Remote Access，潜在的提升例如Page Flush，Purge等功能的吞吐量，甚至可以提高MySQL Crash后Recovery的速度（由于recovery是单线程）。

那是否能在Interleave模式下，把那些明显应该聚集在一个CPU上的内存集中在一起呢？

很可惜，Dynamic Memory Location这种技术目前只停留在理论和实验阶段。我们来看下难点：要做到按照线程的行为动态的调整page在memory的分布，就势必需要做线程 和内存的实时监控（profile）。对于Memory Access这种非常异常频繁的底层 *** 作来说增加profile入口的性能损耗是极大的。在 关于CPU Cache程序应该知道的那些事 的评论中我也提到过，这个道理和为什么Linux没有全局监控CPU L1/L2 Cache命中率工具的原因是一样的。当然优化不会就此停步。上文提到的 Carrefour算法 和Linux社区的Auto NUMA patch都是积极的尝试。什么时候内存profile出现硬件级别，类似于CPU中 PMU 的功能时，动态内存规划就会展现很大的价值，甚至会作为Linux Kernel的一个内部功能来实现。到那时我们再回过头来审视这个方案的实际价值。

再来看一下这些情况：一些动态加载的库，把他们放在任何一个线程所在的CPU都会导致其他CPU上线程的执行效率下降。而这些共享数据往往读写比非常高， 如果能把这些数据的副本在每个Memory Zone内都放置一份，理论上会带来较大的性能提升，同时也减少在inter-connect上出现的瓶颈。实时上，仍然是上文提到的 Carrefour 也 做了这样的尝试。

由于缺乏硬件级别（如MESI协议的硬件支持）和 *** 作系统原生级别的支持，Page Replication在数据一致性上维护的成本显得比他带来的提升更多。因此这种尝试也仅仅停留在理论阶段。当然，如果能得到底层的大力支持，相信这个 方案还是有极大的实际价值的。

---