你的虚拟服务器需要几核CPU，这个问题看似简单，实则复杂，要综合考虑很多因素。一般在虚拟环境中CPU使用率通常偏低，而内存大小和速度通常会比CPU产生更大影响，加上虚拟服务器通常是I/O密集型的。
 
事实上，服务器并不需要单颗CPU具有太多的核心数量，因此表面上，CPU内核数量越少越好。但是问题在于服务器设计的其他因素，这些因素都会对成本造成影响，因此最终都会成为影响配置的决定性因素。
 

 
内存
 
DRAM(动态内存)价格非常昂贵，而最新、密度更高的DIMM(双列直插式存储模块)相比于主流的DIMM更加昂贵，因此廉价但是供应量充足的普通DIMM也许是一种更好的选择。但是现在Optane或者NAND的NVDIMM已经成为TB级别内存扩展的最佳方式。
 
使用NVDIMM或者更加廉价的DRAM需要增加DIMM插槽数量，这样做能够将系统内存带宽扩大一倍并且带来其他性方面的性能提升，管理员就能够在服务器上加载更多的实例了。
 
向服务器添加快速的NVMe SSD能够显著提升实例的I/O性能。过去这是一种非常昂贵的解决方案，但是现在NVMe已经进入消费级市场，价格大幅降低。
 
NVMe大幅度降低了操作系统在I/O方面的开销，能够节省大量的CPU和内存时间周期。类似地，RDMA(远程直接数据存取)被广泛应用在HCI(超融合基础架构)中，将会在未来几年成为一种标准的以太网特性，能够减少虚拟服务器集群之间的系统开销和延迟。
 
总而言之，内存和I/O方面的性能提升允许管理员运行更多的虚拟服务器实例，从而导致CPU数量不足。因此需要增加单颗CPU的核心数量，才能够保证服务器的正常运行。
 
实例配置
 
在这篇文章，有必要谈论一下究竟什么是实例。当然，我们不能为实例设置固定大小。实例可能包含多种配置以适用于多种应用程序。可以是一个虚拟核心对应一个物理核心，或者多个虚拟核心对应一个物理核心，甚至是一个虚拟核心对应整个CPU。内存和I/O分配同样是相互独立的变量。
 
实例的发展趋势是更大的DRAM和更多的I/O以及更低的虚拟核心比——也就是每个实例中更多的CPU。如果管理员希望未来五年之内使用这种等级的实例，那么具有更多CPU核心的服务器引擎将会起到很大帮助作用。
 
容器和微服务
 
这种相对全新的虚拟化方式是为了替代基于hypervisor的实例。通常由于共享内存段，运行容器的服务器相比运行hypervisor的服务器所需的DRAM更少，因此容器的数量通常会是实例数量的三到五倍。但是实例数量的增加意味着需要更多的CPU核心。
 
如果我们向微服务软件架构迁移，存储和网络服务功能都被转变为很小的容器化模型，应用程序被分隔为微服务元素，那么单台服务器能够运行的容器数量还会继续提升，而且是大幅度地。微服务意味着需要CPU进行更加频繁的状态切换。需要更好的性能表现和并发能力，因此单个CPU需要更多的核心才能够满足要求。
 
服务器架构创新
 
所有这些都忽略了服务器架构方面的领先技术。关于HMC( Hybrid Memory Cube)方面的讨论已经持续了三年，其能够将CPU和DRAM段形成更加紧耦合的模型。这种方式能够大幅度提升DRAM速度，比如适用于许多并行通道的电接口和架构调用以及DRAM。
 
现在很多主流厂商都在推广类似于HMC的平台，其早期版本限制DRAM大小不能超过32GB。这足够在三层和DRAM之间形成一个足够大的中间层缓存，有效提升内存性能表现以支持更多的CPU核心。由此得出的结论是多CPU核心是有意义的。
 
增加核心的成本方面考虑
 
通常数量更少、更加强大的服务器相比于多台小型服务器在成本方面更加具有优势。它们的运行成本更低，能够支持25Gb以太网和50Gb RDMA连接。底层基础架构的电力成本得到平摊，而运营费用——供电、制冷和维护等——也都更加便宜。
 
所有这些讨论包含一些如何选择组件的不错建议。比如，每颗核心的成本会随着数量的增加而下降，但是最好的三到四颗CPU很有可能是全新的，需要50%到100%的额外费用。同样的情况也适用于内存和SSD。
 
如果没有使用前沿技术，那么看起来更多的CPU核心和配置更高的服务器相比于小型服务器更加具有吸引力，但是爆米花大小的web服务器除外。
 
展望未来
 
未来的服务器架构发展路线相比于之间更加模糊，是否转向以内存为中心的架构——比如Gen-Z——依旧在争论之中。即便如此，我们依然能够在2018年看到32核心的CPU，并且如果将HMC内存体积扩展到TB级别，那么CPU核心数量还会继续增加。一些厂商暗示可能会在架构中同时使用DRAM和NAND。
 
通过使用多核虚拟服务器和HCI架构，特定负载所需要的服务器存储将会大幅度减少。
 
声明：本网站发布的内容(图片、视频和文字)以用户投稿、用户转载内容为主，如果涉及侵权请尽快告知，我们将会在第一时间删除。文章观点不代表本网站立场，如需处理请联系客服。电话：028-62778877-8261；邮箱：jenny@west.cn。本站原创内容未经允许不得转载，或转载时需注明出处：：西部数码资讯门户 » 你的虚拟服务器需要几核CPU？影响配置的因素有哪些

 
作为集成电路的中央处理器(CPU)，对计算机起到了控制的作用，在计算机运行的过程中，快速的将计算机的指令以及软件中的数据进行解释。不同种类计算机的中央处理器是不一样的，而中央处理器性能的好坏对计算机的运行起到了很大的影响作用，主要表现在影响计算机的性能上面。
 
(一)CPU性能好坏对计算机的影响表现
 
计算机的性能强弱主要是受到中央处理器性能的影响，而中央处理器的性能好坏主要体现在它本身运行的速度上。CPU的运行速度越快，计算机的性能也就越好，反之就更差。
 
(二)影响中央处理器性能的主要因素
 
一般情况下，能够影响中央处理器运行速度的主要有：中央处理器本身的工作效率、CACHE的容量、逻辑结构以及指令系统等主要的参数。
 

 
(三)影响中央处理器性能的主要因素的具体分析
 
1 主频相当于是中央处理器的工作效率，也可是指CPU的时钟效率。通常情况下，在一定的时间里面完成的指令的数目是固定不变的。这就意味着中央处理器的主频越高的话，中央处理器本身的运行速度也会加快。
 
2 作为中央处理器基本频率的外频，对主板的运行速度起到很大的影响作用。如果外频发生了改变的话，电脑容易出现异步运行，有可能会导致服务器系统的紊乱。
 
3 倍频一般指的是中央处理器外频和主频之间的倍数关系，它本身对中央处理器的影响并不大，但是一味的追求高频的情况下，中央处理器容易出现瓶颈的现象，也就是说中央处理器获得数据的速度不能够很好的契合处理器本身的运行速度。出现这种情况的话，中央处理器的性能也会受到很大的影响。
 
4 缓存的大小也是反应中央处理器性能的重要指标之一。而影响中央处理器性能的主要是缓存的大小和结构。在计算机工作的时候，可能要对相同的数据进行反复的调取，如果缓存的容量足够大的话，可以大大的提高中央处理器的运行速度，通常表现为读取数据的速度、准确度得到了提高。
 
中央处理器的性能受到很多方面因素的影响，但是随着技术的不断改进，如今很多的中央处理器集成度越来越高了。而反映在微机上的中央处理器的性能，与过去的处理器相比有了很大的进步。大大的方便了人们的生活和工作。

CPU VS GPU
 
关于绘图和动画有两种处理的方式：CPU（中央处理器）和GPU（图形处理器）。在现代iOS设备中，都有可以运行不同软件的可编程芯片，但是由于历史原因，我们可以说CPU所做的工作都在软件层面，而GPU在硬件层面。
 
总的来说，我们可以用软件（使用CPU）做任何事情，但是对于图像处理，通常用硬件会更快，因为GPU使用图像对高度并行浮点运算做了优化。由于某些原因，我们想尽可能把屏幕渲染的工作交给硬件去处理。问题在于GPU并没有无限制处理性能，而且一旦资源用完的话，性能就会开始下降了（即使CPU并没有完全占用）
 
大多数动画性能优化都是关于智能利用GPU和CPU，使得它们都不会超出负荷。于是我们首先需要知道Core Animation是如何在这两个处理器之间分配工作的。
 
动画的舞台
 
Core Animation处在iOS的核心地位：应用内和应用间都会用到它。一个简单的动画可能同步显示多个app的内容，例如当在iPad上多个程序之间使用手势切换，会使得多个程序同时显示在屏幕上。在一个特定的应用中用代码实现它是没有意义的，因为在iOS中不可能实现这种效果（App都是被沙箱管理，不能访问别的视图）。
 
动画和屏幕上组合的图层实际上被一个单独的进程管理，而不是你的应用程序。这个进程就是所谓的渲染服务。在iOS5和之前的版本是SpringBoard进程（同时管理着iOS的主屏）。在iOS6之后的版本中叫做BackBoard。
 
当运行一段动画时候，这个过程会被四个分离的阶段被打破：
 
 
布局 - 这是准备你的视图/图层的层级关系，以及设置图层属性（位置，背景色，边框等等）的阶段。
 
 
显示 - 这是图层的寄宿图片被绘制的阶段。绘制有可能涉及你的-drawRect:和-drawLayer:inContext:方法的调用路径。
 
 
准备 - 这是Core Animation准备发送动画数据到渲染服务的阶段。这同时也是Core Animation将要执行一些别的事务例如解码动画过程中将要显示的图片的时间点。
 
 
提交 - 这是最后的阶段，Core Animation打包所有图层和动画属性，然后通过IPC（内部处理通信）发送到渲染服务进行显示。
 
但是这些仅仅阶段仅仅发生在你的应用程序之内，在动画在屏幕上显示之前仍然有更多的工作。一旦打包的图层和动画到达渲染服务进程，他们会被反序列化来形成另一个叫做渲染树的图层树（在第一章“图层树”中提到过）。使用这个树状结构，渲染服务对动画的每一帧做出如下工作：
 
 
对所有的图层属性计算中间值，设置OpenGL几何形状（纹理化的三角形）来执行渲染
 
 
在屏幕上渲染可见的三角形
 
所以一共有六个阶段；最后两个阶段在动画过程中不停地重复。前五个阶段都在软件层面处理（通过CPU），只有最后一个被GPU执行。而且，你真正只能控制前两个阶段：布局和显示。Core Animation框架在内部处理剩下的事务，你也控制不了它。
 
这并不是个问题，因为在布局和显示阶段，你可以决定哪些由CPU执行，哪些交给GPU去做。那么改如何判断呢？
 
GPU相关的操作
 
GPU为一个具体的任务做了优化：它用来采集图片和形状（三角形），运行变换，应用纹理和混合然后把它们输送到屏幕上。现代iOS设备上可编程的GPU在这些操作的执行上又很大的灵活性，但是Core Animation并没有暴露出直接的接口。除非你想绕开Core Animation并编写你自己的OpenGL着色器，从根本上解决硬件加速的问题，那么剩下的所有都还是需要在CPU的软件层面上完成。
 
宽泛的说，大多数CALayer的属性都是用GPU来绘制。比如如果你设置图层背景或者边框的颜色，那么这些可以通过着色的三角板实时绘制出来。如果对一个contents属性设置一张图片，然后裁剪它 - 它就会被纹理的三角形绘制出来，而不需要软件层面做任何绘制。
 
但是有一些事情会降低（基于GPU）图层绘制，比如：
 
 
太多的几何结构 - 这发生在需要太多的三角板来做变换，以应对处理器的栅格化的时候。现代iOS设备的图形芯片可以处理几百万个三角板，所以在Core Animation中几何结构并不是GPU的瓶颈所在。但由于图层在显示之前通过IPC发送到渲染服务器的时候（图层实际上是由很多小物体组成的特别重量级的对象），太多的图层就会引起CPU的瓶颈。这就限制了一次展示的图层个数。
 
 
重绘 - 主要由重叠的半透明图层引起。GPU的填充比率（用颜色填充像素的比率）是有限的，所以需要避免重绘（每一帧用相同的像素填充多次）的发生。在现代iOS设备上，GPU都会应对重绘；即使是iPhone 3GS都可以处理高达2.5的重绘比率，并任然保持60帧率的渲染（这意味着你可以绘制一个半的整屏的冗余信息，而不影响性能），并且新设备可以处理更多。
 
 
离屏绘制 - 这发生在当不能直接在屏幕上绘制，并且必须绘制到离屏图片的上下文中的时候。离屏绘制发生在基于CPU或者是GPU的渲染，或者是为离屏图片分配额外内存，以及切换绘制上下文，这些都会降低GPU性能。对于特定图层效果的使用，比如圆角，图层遮罩，阴影或者是图层光栅化都会强制Core Animation提前渲染图层的离屏绘制。但这不意味着你需要避免使用这些效果，只是要明白这会带来性能的负面影响。
 
 
过大的图片 - 如果视图绘制超出GPU支持的2048x2048或者4096x4096尺寸的纹理，就必须要用CPU在图层每次显示之前对图片预处理，同样也会降低性能。
 
CPU相关的操作
 
大多数工作在Core Animation的CPU都发生在动画开始之前。这意味着它不会影响到帧率，所以很好，但是他会延迟动画开始的时间，让你的界面看起来会比较迟钝。
 
以下CPU的操作都会延迟动画的开始时间：
 
 
布局计算 - 如果你的视图层级过于复杂，当视图呈现或者修改的时候，计算图层帧率就会消耗一部分时间。特别是使用iOS6的自动布局机制尤为明显，它应该是比老版的自动调整逻辑加强了CPU的工作。
 
 
视图懒加载 - iOS只会当视图控制器的视图显示到屏幕上时才会加载它。这对内存使用和程序启动时间很有好处，但是当呈现到屏幕上之前，按下按钮导致的许多工作都会不能被及时响应。比如控制器从数据库中获取数据，或者视图从一个nib文件中加载，或者涉及IO的图片显示，都会比CPU正常操作慢得多。
 
 
Core Graphics绘制 - 如果对视图实现了-drawRect:方法，或者CALayerDelegate的-drawLayer:inContext:方法，那么在绘制任何东西之前都会产生一个巨大的性能开销。为了支持对图层内容的任意绘制，Core Animation必须创建一个内存中等大小的寄宿图片。然后一旦绘制结束之后，必须把图片数据通过IPC传到渲染服务器。在此基础上，Core Graphics绘制就会变得十分缓慢，所以在一个对性能十分挑剔的场景下这样做十分不好。
 
 
解压图片 - PNG或者JPEG压缩之后的图片文件会比同质量的位图小得多。但是在图片绘制到屏幕上之前，必须把它扩展成完整的未解压的尺寸（通常等同于图片宽 x 长 x 4个字节）。为了节省内存，iOS通常直到真正绘制的时候才去解码图片。根据你加载图片的方式，第一次对图层内容赋值的时候（直接或者间接使用UIImageView）或者把它绘制到Core Graphics中，都需要对它解压，这样的话，对于一个较大的图片，都会占用一定的时间。
 
当图层被成功打包，发送到渲染服务器之后，CPU仍然要做如下工作：为了显示屏幕上的图层，Core Animation必须对渲染树种的每个可见图层通过OpenGL循环转换成纹理三角板。由于GPU并不知晓Core Animation图层的任何结构，所以必须要由CPU做这些事情。这里CPU涉及的工作和图层个数成正比，所以如果在你的层级关系中有太多的图层，就会导致CPU没一帧的渲染，即使这些事情不是你的应用程序可控的。
 
IO相关操作
 
还有一项没涉及的就是IO相关工作。上下文中的IO（输入/输出）指的是例如磁盘或者网络接口的硬件访问。一些动画可能需要从磁盘（甚至是远程URL）来加载。一个典型的例子就是两个视图控制器之间的过渡效果，这就需要从一个nib文件或者是它的内容中懒加载，或者一个旋转的图片，可能在内存中尺寸太大，需要动态滚动来加载。
 
IO比内存访问更慢，所以如果动画涉及到IO，就是一个大问题。总的来说，这就需要使用多线程，缓存和预加载（提前加载当前不需要的资源，但是之后可能需要用到）。
 
测量，而不是猜测
 
于是现在你知道有哪些点可能会影响动画性能，那该如何修复呢？好吧，其实不需要。有很多种诡计来优化动画，但如果盲目使用的话，可能会造成更多性能上的问题，而不是修复。
 
如何正确的测量而不是猜测这点很重要。根据性能相关的知识写出代码不同于仓促的优化。前者很好，后者实际上就是在浪费时间。
 
那该如何测量呢？第一步就是确保在真实环境下测试你的程序。
 
真机测试，而不是模拟器
 
当你开始做一些性能方面的工作时，一定要在真机上测试，而不是模拟器。模拟器虽然是加快开发效率的一把利器，但它不能提供准确的真机性能参数。
 
模拟器运行在你的Mac上，然而Mac上的CPU往往比iOS设备要快。相反，Mac上的GPU和iOS设备的完全不一样，模拟器不得已要在软件层面（CPU）模拟设备的GPU，这意味着GPU相关的操作在模拟器上运行的更慢，尤其是使用CAEAGLLayer来写一些OpenGL的代码时候。
 
这就是说在模拟器上的测试出的性能会高度失真。如果动画在模拟器上运行流畅，可能在真机上十分糟糕。如果在模拟器上运行的很卡，也可能在真机上很平滑。你无法确定。
 
另一件重要的事情就是性能测试一定要用发布配置，而不是调试模式。因为当用发布环境打包的时候，编译器会引入一系列提高性能的优化，例如去掉调试符号或者移除并重新组织代码。你也可以自己做到这些，例如在发布环境禁用NSLog语句。你只关心发布性能，那才是你需要测试的点。
 
最后，最好在你支持的设备中性能最差的设备上测试：如果基于iOS6开发，这意味着最好在iPhone 3GS或者iPad2上测试。如果可能的话，测试不同的设备和iOS版本，因为苹果在不同的iOS版本和设备中做了一些改变，这也可能影响到一些性能。例如iPad3明显要在动画渲染上比iPad2慢很多，因为渲染4倍多的像素点（为了支持视网膜显示）。
 
保持一致的帧率
 
为了做到动画的平滑，你需要以60FPS（帧每秒）的速度运行，以同步屏幕刷新速率。通过基于NSTimer或者CADisplayLink的动画你可以降低到30FPS，而且效果还不错，但是没办法通过Core Animation做到这点。如果不保持60FPS的速率，就可能随机丢帧，影响到体验。
 
你可以在使用的过程中明显感到有没有丢帧，但没办法通过肉眼来得到具体的数据，也没法知道你的做法有没有真的提高性能。你需要的是一系列精确的数据。
 
你可以在程序中用CADisplayLink来测量帧率，然后在屏幕上显示出来，但应用内的FPS显示并不能够完全真实测量出Core Animation性能，因为它仅仅测出应用内的帧率。我们知道很多动画都在应用之外发生（在渲染服务器进程中处理），但同时应用内FPS计数的确可以对某些性能问题提供参考，一旦找出一个问题的地方，你就需要得到更多精确详细的数据来定位到问题所在。苹果提供了一个强大的Instruments工具集来帮我们做到这些。
 
系列文章： https://www.jianshu.com/p/d7d56b6dff81

 主频和架构对CPU性能的影响同样重要，不能够割裂这两个因素来评估CPU的性能。
 主频很容易理解，类似于速度，对于同一种架构的CPU，当然是主频越高CPU的速度就越快。
 但是，如果CPU的架构不一样，只看主频，基本上无法判断CPU 性能的优劣。那么架构是什么？对于大多数用户比较陌生，是个比较晦涩的技术术语，即使听说过，也可能被懂行的技术人员用更多晦涩的技术术语解释得更像“云里雾里”。
 架构一词源于英文“architecture”的翻译，它的原意是建筑，建筑学，设计及构造的方式和方法。这个词应用于处理器(CPU)是指处理器内部各个运算部件的有序安排和构造，达到设计的和谐统一，使之在运行时协调一致达到高效率。在计算机教科书上比较多的翻译成“体系结构”，“体系架构”或者“系统结构”。
 先进的架构可以使CPU在单位是时间内执行更多的指令，也就是完成更多的任务。因此，不同架构的CPU如果只看主频，是无法知道性能的高低的。一般来说，越先进的CPU架构，在单位时间内可以执行的指令数和处理数据的数量就越多。
 我在之前的一篇博客“为什么微处理器要从单核转向多核？”使用了如下的公式：
 处理器(CPU)性能 = 主频 x IPC
 IPC就是每个时钟周期内可以执行的指令数(IPC: Instruction Per Clock)，CPU架构的更新换代直接影响和提高的是IPC值，当然制造工艺和架构对主频的影响也是关联的。另外，并行计算也是直接提高IPC的途径，这也是现在为什么主流CPU从单核转向双核，将来转向四核，和更多核。
 英特尔在2006年第 4 季度双核产品就已经超过了单核产品
 
 双核处理器已经是英特尔量产的主流处理器
 如果把主频和架构综合起来考虑，为了让大家更容易理解，我以百米运动员赛跑为例。主频相当于百米选手的步频，架构类比于步幅。所以大家可以看到：
 1． 步幅一样大(架构相同)，步频快的选手跑的快。
 2． 步频一样快，步幅大(架构先进)的选手跑的快。
 3． 步频也快，步幅也大，选手成为世界百米飞人也就不是天方夜谭了。
 因此，大家在选择CPU关注性能问题时，要同时考虑架构的先进性和主频。最后，先进的芯片制造工艺是保证先进架构实现和达成高主频的基础。