精华内容
下载资源
问答
  • 2021-03-05 10:17:43
    • 多容器任务运行时,很难计算CPU的使用率

    命令中的–cpu-shares选项值不能保证可以获得1个vcpu或者多少GHz的CPU资源,仅仅只是一个弹性的加权值。

    [root@10 ~]# docker run --name=con1 -itd --cpu-shares 1024 centos:stress /bin/bash
    f66fe17649f5b08401348fea37f4b1b4454dc581341f451697172d09716cbc6a
    [root@10 ~]# docker run --name=con2 -itd --cpu-shares 1024 centos:stress /bin/bash
    a2150bc7a7f2e2491abb1679ffad744badb07652bd38803824e2ded8410e5ba2
    [root@10 ~]# docker run --name=con3 -itd --cpu-shares 2048 centos:stress /bin/bash
    ae249a8f18d01d0fa61e638e26c86271c961b7c203b10eb6f3dee45be571d0e3
    

    如果有一个容器D需要更多CPU资源,则可以将其–cpu-shares的值设置为4096,那么ABCD的CPU资源比例变为1:1:2:4。

    	默认情况下,每个docker容器的CPU份额都是1024。单独一个容器的份额是没有意义的。只有在同时运行多个容器时,容器的CPU加权的效果才能体现出来。
    例如,两个容器A、B的CPU份额分别为1000和500,在CPU进行时间片分配的时候,容器A比容器B多一倍的机会获得CPU的时间片。
    但分配的结果取决于当时主机和其他容器的运行状态,实际上也无法保证容器A一定能获得CPU时间片。
    比如容器A的进程一直是空闲的那么容器B是可以获取比容器A更多的CPU时间片的。
    极端情况下,比如说主机只运行了一个容器,即使它的CPU份额只有50,它也可以独占整个主机的CPU资源
    
    	Cgroups只在容器分配ID额资源紧缺时,也就是说在需要对容器使用的资源进行限制时才会生效。
    因此无法单纯根据某个容器的CPU份额来确定有多少CPU资源分配给它,资源分配结果取决于同时运行的其他cpu shares可以设置容器使用CPU的优先级
    

    启动了两个容器及运行查看CPU使用百分比。

    [root@10 ~]# docker run -tid --name cpu512 --cpu-shares 512 centos:stress stress -c 10
    [root@10 ~]# docker run -tid --name cpu1024 --cpu-shares 1024 centos:stress stress -c 10
    [root@10 ~]# docker ps -a
    CONTAINER ID        IMAGE               COMMAND             CREATED             STATUS              PORTS               NAMES
    09730b873e46        centos:stress       "stress -c 10"      6 minutes ago       Up 6 minutes                            cpu1024
    3ab12e09a79f        centos:stress       "stress -c 10"      6 minutes ago       Up 6 minutes                            cpu512
    
    docker run -tid --name cpu512 --cpu-shares 512 centos:stress stress -c 10
    docker run -tid --name cpu1024 --cpu-shares 1024 centos:stress stress -c 10
    docker exec -it cpu512 /bin/bash
    

    在这里插入图片描述

    docker exec -it cpu1024 /bin/bash
    

    在这里插入图片描述

    开启了10个stress进程,目的是充分让系统资源变得紧张。只有这样竞争资源,设定的资源比例才可以显现出来。
    如果只运行一个进程,会自动分配到空闲的CPU,这样比例就无法看出来。由于案例的环境不一样,
    可能导致三个面两张图中占用CPU百分比会不同,但是从cpu share来看两个容器总比例一定会是1:2。
    
    更多相关内容
  • 仪表监控和微打监控程序共享CPU.pdf
  • CPU系统共享串行EEPROM.pdf
  • 共享上网主机CPU占用率高的问题.pdf
  • 基于RAM共享的嵌入式多CPU系统研究.pdf
  • CPU散热器改良技巧两则方法共享.pdf
  • 串行E^2PROM的多CPU系统共享.pdf
  • 基于CPU-MEM的负载共享调度机制研究.pdf
  • CPU共享RAM技术及其在数控系统中的应用.pdf
  • 多台计算机共享内存 共享内存多处理器 (Shared Memory Multiprocessor) There are three types of shared memory multiprocessor: 共有三种类型的共享内存多处理器: UMA (Uniform Memory Access) UMA(统一内存...

    多台计算机共享内存

    共享内存多处理器 (Shared Memory Multiprocessor)

    There are three types of shared memory multiprocessor:

    共有三种类型的共享内存多处理器:

    1. UMA (Uniform Memory Access)

      UMA(统一内存访问)

    2. NUMA (Non- uniform Memory Access)

      NUMA(非统一内存访问)

    3. COMA (Cache Only Memory)

      COMA(仅缓存内存)

    1)UMA(统一内存访问) (1) UMA (Uniform Memory Access))

    In this type of multiprocessor, all the processors share a unique centralized memory so, that each CPU has the same memory access time.

    在这种类型的多处理器中,所有处理器共享唯一的集中式内存,以便每个CPU具有相同的内存访问时间。

    UMA

    2)NUMA(非统一内存访问) (2) NUMA (Non- uniform Memory Access))

    In the NUMA multiprocessor model, the access time varies with the location of the memory word. Here the shared memory is physically distributed among all the processors called local memories.

    NUMA多处理器模型中 ,访问时间随存储字的位置而变化。 在这里,共享内存在物理上分布在所有称为本地内存的处理器之间。

    So, we can call this as a distributed shared memory processor.

    因此,我们可以称其为分布式共享内存处理器。

    NUMA

    3)COMA(仅缓存内存) (3) COMA (Cache Only Memory))

    The COMA model is a special case of a non-uniform memory access model; here all the distributed local memories are converted into cache memories. Data can migrate and can be replicated in various memories but cannot be permanently or temporarily stored.

    COMA模型是非均匀内存访问模型的特例; 在这里,所有分布式本地内存都转换为高速缓存。 数据可以迁移并可以在各种内存中复制,但是不能永久或临时存储。

    COMA

    We have discussed different types of shared-memory multiprocessors. Now we are moving forward to take a short overview of instruction execution.

    我们讨论了不同类型的共享内存多处理器 。 现在,我们将对指令执行进行简要概述。

    指令执行 (Instruction Execution)

    Now, first of all, what is an instruction, any command that we pass to a computer or system to perform is known as an instruction. A typical instruction consists of a sequence of operations that are fetched, decode, operand fetches, execute and write back. These phases are ideal for overlap execution on a pipeline.

    现在,首先,什么是指令,我们传递给计算机或系统要执行的任何命令都称为指令。 典型的指令由一系列的操作组成,这些操作被提取,解码,取操作数,执行和回写。 这些阶段非常适合在管道上执行重叠。

    Shared memory

    There are two ways of executing an instruction in a pipeline system and a non-pipeline system.

    在管道系统和非管道系统中有两种执行指令的方式。

    In a non-pipeline system single hardware component which can take only one task at a time from its input and produce the result at the output.

    在非管道系统中,单个硬件组件一次只能从其输入执行一项任务,并在输出端产生结果。

    On the other hand in case of a pipeline system single hardware component we can split the hardware resources into small components or segments.

    另一方面,在流水线系统中,只有一个硬件组件,我们可以将硬件资源拆分为较小的组件或段。

    Disadvantages of non-pipeline

    非管道的缺点

    • We process only one input at a single time.

      我们一次只能处理一个输入。

    • Production of partial or segmented output is not possible in the case of the non-pipeline system.

      在非管道系统中,无法产生部分或分段输出。

    When you will read in deep about pipeline system you will discover pipeline are linear and non-linear also and further linear pipelines are also classified into synchronous and asynchronous.

    当您深入了解管道系统时,您会发现管道也是线性和非线性的,进一步的线性管道也分为同步和异步。

    As this article was only about the introduction of instruction execution so, we will get further inside the pipeline system.

    由于本文仅是关于指令执行的介绍,因此,我们将深入了解流水线系统。

    Conclusion:

    结论:

    In the above article we have discussed the shared memory multiprocessor and introduction instruction execution, I hope you all have gathered the concepts strongly. For further queries, you shoot your questions in the comment section below.

    在以上文章中,我们讨论了共享内存多处理器和入门指令的执行 ,希望大家都认真收集了这些概念。 如有其他疑问,请在下面的评论部分中提出问题。

    翻译自: https://www.includehelp.com/basics/shared-memory-multiprocessor-and-instruction-execution-computer-architecture.aspx

    多台计算机共享内存

    展开全文
  • 调度机制对CPU-MEM负载共享系统的性能影响.pdf
  • PAGE1 / NUMPAGES1 CPU-GPGPU共享最后一级缓存架构中的数据共享优化研究 随着CPU和GPGPU在各种环境下得到应用,人们逐渐发现这两个处理器各自的独特优势为了实现优势互补并支持更广泛的场景,由CPU和GPGPU组成的异构多...
  • 缓存行、cpu共享和缓存行填充

    千次阅读 2017-07-07 23:23:35
    CPU 为了更快的执行代码。于是当从内存中读取数据时,并不是只读自己想要的部分。而是读取足够的字节来填入高速缓存行。根据不同的 CPU ,高速缓存行大小不同。如 X86 是 32BYTES ,而 ALPHA 是 64BYTES 。并且始终...

    由于在看disruptor时了解到缓存行,以及缓存行填充的问题,所以各处了解记在这里

    一、缓存行

    CPU 为了更快的执行代码。于是当从内存中读取数据时,并不是只读自己想要的部分。而是读取足够的字节来填入高速缓存行。根据不同的 CPU ,高速缓存行大小不同。如 X86 是 32BYTES ,而 ALPHA 是 64BYTES 。并且始终在第 32 个字节或第 64 个字节处对齐。这样,当 CPU 访问相邻的数据时,就不必每次都从内存中读取,提高了速度。 因为访问内存要比访问高速缓存用的时间多得多。
    这个缓存是CPU内部自己的缓存,内部的缓存单位是行,叫做缓存行。在多核环境下会出现CPU之间的内存同步问题(比如一个核加载了一份缓存,另外一个核也要用到同一份数据),如果每个核每次需要时都往内存中存取(一个在读缓存,一个在写缓存时,造成数据不一致),这会带来比较大的性能损耗,这个问题一般是通过MESI协议来解决的。
    这里写图片描述

    图1说明了伪共享的问题。在核心1上运行的线程想更新变量X,同时核心2上的线程想要更新变量Y。不幸的是,这两个变量在同一个缓存行中。每个线程都要去竞争缓存行的所有权来更新变量。如果核心1获得了所有权,缓存子系统将会使核心2中对应的缓存行失效。当核心2获得了所有权然后执行更新操作,核心1就要使自己对应的缓存行失效。这会来来回回的经过L3缓存,大大影响了性能。如果互相竞争的核心位于不同的插槽,就要额外横跨插槽连接,问题可能更加严重。

    1.Cache的写策略:

    1)Write through(写通)
         每次CPU修改了cache中的内容,Cache立即更新内存的内容
    2) Write back(写回)
        内核修改cache的内容后,cache并不会立即更新内存中的内容,而是等到这个cache line因为某种原因需要从cache中移除时,cache才会更新内存中的内容。
    

    Write through(写通)由于有大量的访问内存的操作,效率太低,大多数处理器都使用Writeback(写回)策略。
    这里写图片描述
    Cache如何知道这行有没有被修改?需要一个标志-dirty标志。Dirty标志为1,表示cache的内容被修改,和内存的内容不一致,当该cache line被移除时,数据需要被更新到内存,dirty标志位0(称为clean),表示cache的内容和内存的内容一致。

    2.Cache一致性

    1)一致性问题的产生-信息不对称导致的问题
    在多核处理器中,内存中有一个数据x,值为3,被缓存到core0和core1中,如果core0将x修改为5,而core1
    不知道x被修改,还在使用旧数据,就会导致程序出错,这就是cache的不一致。
    2)Cache一致性的底层操作
    为了保证cache的一致性,处理器提供了两个保证cache一致性的底层操作:Writeinvalidate和Write update。
    这里写图片描述

    Write invalidate(置无效):当一个内核修改了一份数据,其他内核上如果有这份数据的复制,就置成无效。

    这里写图片描述

    Write update(写更新):当一个内核修改了一份数据,其他地方如果有这份数据的复制,就都更新到最新值。

    Write invalidate是一种简单的方式,不需要更新数据,如果core1和core2以后不再使用变量x,这时候采用write invalidate就非常有效,不过由于一个valid标志对应一个Cache line,将valid标志置成invalid后,这个cache line中其他的有效的数据也不能使用了。Write upodate策略会产生大量的数据更新操作,不过只用更新修改的数据,如果core1和core2会使用变量x,那么writeupdate就比较有效。由于Writeinvalidate简单,大多数处理器都是用Writeinvalidate策略。

    MESI协议中包含M、E、S、I四个状态,分别的意思是:

    • M(Modified)位。M 位为1 时表示当前Cache 行中包含的数据与存储器中的数据不一致,而且它仅在本CPU的Cache 中有效,不在其他CPU的Cache
      中存在拷贝,在这个Cache行的数据是当前处理器系统中最新的数据拷贝。当CPU对这个Cache行进行替换操作时,必然会引发系统总线的写周期,将Cache行中数据与内存中的数据同步。
    • E(Exclusive 独占)位。E 位为1 时表示当前Cache行中包含的数据有效,而且该数据仅在当前CPU的Cache中有效,而不在其他CPU的Cache中存在拷贝。在该Cache行中的数据是当前处理器系统中最新的数据拷贝,而且与存储器中的数据一致。
    • S(Shared 共享)位。S 位为1 表示Cache行中包含的数据有效,而且在当前CPU和至少在其他一个CPU中具有副本。在该Cache行中的数据是当前处理器系统中最新的数据拷贝,而且与存储器中的数据一致。
    • I(Invalid 无效)位。I 位为1 表示当前Cache 行中没有有效数据或者该Cache行没有使能。MESI协议在进行Cache行替换时,将优先使用I位为1的Cache行。
      这里写图片描述
      这里写图片描述
      这里写图片描述

    MESI协议状态迁移图:
    这里写图片描述

    Local Read表示本内核读本Cache的值,Local Write表示本内核写Cache中的值,Remote Read表示其他内核
    Remote Read读其他Cache中的值,Remote write 表示其他内核写其他Cache的值,箭头表示本Cache line状态的迁移

    二、CPU伪共享

    cpu在对缓存行进行了不同的操作后,在cpu缓存行中会记录缓存的不同状态。当一个核要对共享的数据进行写操作时,需要给其他核发送RFO(REQUEST FOR OWNER)消息并把其他核的数据改成I态。这是一种比较消耗性能的操作。
    cpu的伪共享问题本质是:几个在逻辑上并不包含在同一个内存单元内的数据,由于被cpu加载在同一个缓存行当中,当在多线程环境下,被不同的cpu执行,导致缓存行失效而引起的大量的缓存命中率降低。
    例如:当两个线程分别对一个数组中的两份数据进行写操作,每个线程操作不同index上的数据,看上去,两份数据之间是不存在同步问题的,但是,由于他们可能在同一个cpu缓存行当中,这就会使这一份缓存行出现大量的缓存失效,如前所述当一份线程更新时要给另一份线程发送RFO消息并把它的缓存失效掉。

    三、CacheLine补齐(缓存行填充)

    解决伪共享问题的一个办法是让每一份数据占据一个缓存行:因为缓存行的大小是64个字节,那我们只要让数组中每份数据的大小大于64个字节,就可以保证他们在不同的缓存行当中,就能避免这样的伪共享问题。
    比如一个类当中原本只有一个long类型的属性。这样这个类型的对象只占了16个字节(java对象头有8字节),如果这个类型被定义成一个长度为4的数组,这个数组的所有数据都可能在一个缓存行当中,就可能出现伪共享问题,那么这个时候,就可以采用补齐(padding)的办法,在这个类型中加上public long a,b,c,d,e,f,g;这六个无用的属性定义,使得这个类型的一个实例占用内存达到64字节,这样这个类型的伪共享问题就得到了解决,在多线程当中对这个类型的数组进行写操作就能避免伪共享问题。

    在Java 8中,可以采用@Contended在类级别上的注释,来进行缓存行填充。这样,多线程情况下的伪共享冲突问题。 感兴趣的同学可以查看该文。
    其实,@Contended注释还可以应用于字段级别(Field-Level),当应用于字段级别时,被注释的字段将和其他字段隔离开来,会被加载在独立的缓存行上。在字段级别上,@Contended还支持一个“contention group”属性(Class-Level不支持),同一个group的字段们在内存上将是连续,但和其他字段隔离开来。
    执行时,必须加上虚拟机参数-XX:-RestrictContended,@Contended注释才会生效。

    disruptor就采用了 缓存行填充来提高程序性能

    展开全文
  • 本文章整合了一下网络看到比较好的2篇博文(vSphere&FusionSphere):1.虚拟化CPU与VCPU关系 2.虚拟化的内存分配 1、vSphere 物理CPU与VCPU的关系 ... pCPU = 物理CPU  vRAM = 虚拟机的内存,也称之为Guest OS

    本文章整合了一下(vSphere&FusionSphere)内存的相关知识:
    1.虚拟化CPU与VCPU关系
    2.虚拟化的内存分配

    1、vSphere 物理CPU与VCPU的关系
    为方便识别虚拟的资源和物理(或叫真实的)资源,本人文章中以小写字母v前缀标识虚拟资源,小写字母p前缀标识物理资源。例如:

    vCPU = 虚拟CPU
      pCPU = 物理CPU
      vRAM = 虚拟机的内存,也称之为Guest OS配置内存(Configured Size),或者说GOS的物理内存
      pRAM = 物理内存,也称机器内存(Machine Memory),或主机物理内存(Host Physical Memory)
      =========================================================================================================
      
      VM的内存资源分配,有3个可以配置的项:Limit,Reservation和Shares,如下:
     【Memory Limit】

    Memory Limit,顾名思义,内存上限,就是Host可以分配给此VM的pRAM数的上限。

    默认情况下是选中unlimited复选框的,也就是不设上限。不设上限不意味着没有上限,隐含的上限值是分配给VM的内存值。

    Q: 什么情况下要设置Memory Limit呢?(或者说Memory Limt有什么好处?)

    A: 一般情况下不用设置Memory Limt。

    Limit通常用来管理用户预期。开始的时候,Host上的VM数量比较少,没有资源争用,因此VM的性能完全可以保证;随后,当一台又一台VM创建出来,对于资源的争用渐渐变的频繁起来。于是VM的性能下降了,用户便会产生抱怨。因此,设置limit可以从一开始就限定VM的性能,也就是让用户一开始就觉得他的VM就应该是这样的性能,当VM数量增加的时候,也不会感觉到性能的下降。当然,Memory Limit设置在什么数值比较合理应该具体情况具体分析。

    那为啥不把VM的内存(Configured Size)设小呢?这也是考虑用户心理。有用户会觉得自己的应用就是需要4GB内存,虽然我们经过分析得出的结论是只需要1GB内存就够了,但是为了考虑用户的感受,就给他设置VM的内存为4GB,于是用户看见自己的OS显示有4GB内存,就很满意,但是他不知道的是我们给他的VM设置了1GB 的Memory Limt,这样,既保证了Host的资源可以更合理的利用,又让用户感到满意。

    当用户的应用越来越频繁,其对内存的需求增加的时候,这时再来调整Memory limt,以满足其对性能的要求。调整Memory Limt无需停机,而如果开始时虚拟机的内存设的小了,此时调整内存数量就要停机了。设置Memory limt的好处就在于减少了不必要的downtime。

    调整memory limit的动作,其实就是通知Hypervisor将某一VM可用的pRAM放大,而无需通知GOS,所以无需GOS重启。(简单的说,就是改Hypervisor,而和GOS无关)

    专用名词解释 Configured Size

    Configured Size可以翻译成配置内存,就是用户在创建一个VM的时候设定的内存值,也是Guest OS认为自己拥有的内存值。Configured Size在VM看来就是自己可用内存的总量,有的时候我们也称之为Guest Physical Memory。

    【Memory Reservation】

    Memory Reservation就是给一台VM保留的内存。这些pRAM将被占用,只能用于此VM,而不会被重新分配。VM默认的Memory Reservation是0,也就是不保留内存。如果给1台VM配置了1GB内存,但是Memory Reservation是默认的0MB,也就是说没有给这台VM分配任何专属的pRAM,那么这台VM的内存从哪里获得呢?答案是Swap(可以翻译为交换文件),也叫VMKernel swap,这是一个存放在硬盘资源上的交换文件(扩展名为vswp),这个swap文件大小在默认情况下等同于VM设定内存的大小。

    所以,即使1台VM没有获得任何pRAM,它还是可以运行的,因为从VM Guest OS看来,自己还是有RAM的,这个RAM就是硬盘上的swap文件。

    但是,我们知道,硬盘的访问是一种机械运动(注:非SSD硬盘情况下),速度要远远比物理内存慢。慢到什么程度呢?RAM速度大概是纳秒级的,而硬盘的速度是毫秒级的,2者相差近100万倍。所以使用swap越多,速度就越慢。对Windows Paging技术熟悉的同学们一定知道,缺少内存的电脑速度非常之慢,主要就是因为经常访问存放在硬盘上的pagefile,这种问题的解决方案就一定是添加物理内存。对于VM也是如此,如果大量使用swap,VM一定会显得非常之慢。

    那么当ESX/ESXi还有可用内存的情况下,VM是不是还一定要用swap当内存呢?

    答案是不用。Memory Reservation为0的VM没有专属的pRAM,但并不意味着这台VM没有物理内存可以用,只是没有独占某些物理内存而已,在共享物理内存池中的内存还是可以使用的。VMware ESX/ESXi在物理内存资源充足的情况下,总是会给VM分配足额的pRAM,因此VM无需使用Swap,这保证了VM的运行速度。比如1台可用物理内存是3GB(忽略COS和Hypervisor所占用的内存开销)的ESX/ESXi主机上,运行了2台VM,每台VM各配置了1GB的内存,此时,共享内存池中有3GB的内存,而实际需求只有2GB,因此2台VM都能获得1GB的pRAM。

    当你给这2台VM各自的Memory Reservation都设置成512MB的时候,这2台VM将各自获得512MB的专属内存,也就是说,无论这2台VM是否实际用到了这512MB内存,这些内存都将保留给它们。此时,共享内存池中可用的内存就只有2GB了。

    当获得了512MB专属内存之后,VM就不需要1GB那么大的swap了,而只需要512MB的swap就足够保证Guest OS不会没有内存可用。所以此时的swap大小就只有512MB。如果继续增大Memory Reservation到1GB,此时swap就为0。

    所以VM内存1GB可能有:

    • 0MB的Memroy Reservation和1024MB的swap,或者
    • 512MB的Memory Reservation和512MB的swap,或者
    • 1024MB的Memory Reservation和0MB的swap。

    因此我们总结出以下公式:

    VM的配置内存 (MB) = Swap文件大小 (MB) + Memory Reservation (MB)

    (注:原文可参《vSphere resource mgmt guide》 p31:“You must reserve swap space for any unreserved virtual machine memory (the difference between the reservation and the configured memory size) on per-virtual machine swap files.”)

    Q: 为什么要配置Memory Reservation?
      A: 因为硬盘内存的速度太慢,而保留一些物理内存给VM可以保证该VM能至少拥有一部分高速的pRAM资源。

    Q: 那么,是不是要给一台VM配置等于其内存大小的Memory Reservation呢?
      A: No,这是为什么呢?

    这是因为Memory Reservation设的越大,可共享的内存池中的内存也就越少,可配置的VM数量就越少。

    还是拿上面的例子来说,如果每台VM的Memory Reservation都是512MB的情况下,3GB的ESX/ESXi的主机最多只能配置6台VM(这是不考虑memory overhead的假想情况下,实践情况可能不到6台),如果Memory Reservation继续增加到每台VM 1GB,那就最多只能配置3台VM了。但是每台VM实际在用内存数可能都没那么多,假设每台VM在用内存的平均数只有256MB,这台主机应该可以运行12台VM,在做了Memory Reservation之后,就只能开启3台或者6台的VM了。

    Q:Memory Reservation的那部分内存是不是其他VM就无法使用?
      A:不是绝对不能用。但是因为Memory Reservation部分的内存不能被reclaim,所以当1台VM开机的时候,如果当时使用的内存不到Memory reservation的大小,那多余的部分还是可以被其他VM用的;但是当此VM占用的内存达到过Memory Reservation的大小以后,这部分内存就不会交还到可以共享的内存pool中了,就不能再被其他VM用了。

    【关于Swap的Q&A】

    Q: Swap何时产生?何时消亡?
      A: swap文件在一台VM开机的时候生成,关机的时候被删除。

    Q: VM开机时,存放位置没有足够的空间来放置Swap,会发生什么?
      A: VM无法开机。

    Q: Swap的大小?
      A: Swap = VM Configured Memory Size – Memory Reservation

    swap的大小是固定的,是静态的,是预先分配好空间的,既不会变大也不会缩小。即使VM从来不去用它,也牢牢霸占着磁盘空间。大多数情况下,swap的利用率很低。(swap利用率高了就意味着VM缺少pRAM,就要想办法调整内存设置,或者增加Host的物理内存,或者调整配置以满足VM需求)

    Q: Swap的默认位置?
      A: 和VM的文件 e.g. VMX, VMDK等在同一目录下

    Q: Swap的位置可以改变么?为什么?
      A: 可以改,但不建议改。

    Swap的存放位置可以改到共享存储的另外的位置,或者Host本地存储的某个位置(Host-local方式)。但是Host-local有个缺点,就是会影响到VMotion的效率,因为在Host本地存储的Swap文件必须在VMotion的时候迁移到另外的主机上;而swap如果是在共享存储上的话,就不需要移动。

    Q: Host-local Swap如何设置?如果修改默认swap位置到Host-local?
      A: 见vSphere Resouce Management Guide p31

    关于host-local swap的更多精妙解释,强烈推荐您读以下Frank的这篇文章:http://frankdenneman.nl/2010/02/impact-of-host-local-vm-swap-on-ha-and-drs/

    【Memory Shares】

    Memory shares简单的说就是份额。当内存资源不足时,VM之间就会产生内存资源的争用。Share就是用来设定VM在争用时能够获得多少份额的内存。

    还是拿前面的例子举例。3GB pRAM的ESX/ESXi主机上配置了2台VM,没有配置Reservation,当它们都只有1GB内存的时候,这1GB都可以使用pRAM,现在让我们把这2台VM的内存增加到2GB。现在内存需求的总量是4GB了,VMware将如何分配内存?

    首先要明确的是,内存资源只有在争用的情况下才会用到share。上面2台VM虽然都分配了2GB vRAM,但是如果其应用还是都只用到1GB的话,此时没有争用发生,share也就没有发生作用。

    当这2台VM都请求2GB内存的时候,就发生了争用。假设他们的share都是1000,那么也就是说,我们把可用内存3GB分成2000份,每台VM可以分到1000份。因此此时每台VM可以获得3GB*1000/2000=1.5GB的内存。

    假设VM1用于开发,VM2用于生产,所以我们想把VM2的优先级别设高,便调整VM2的share为2000。此时VM1将获得3GB1000/(1000+2000)=1GB内存。而VM2将获得3GB2000/(1000+2000)=2GB的物理内存。

    当我们调整VM1的share为500,VM2的share为2000. 此时,根据计算,VM2争用获得的内存是3GB2000/(500+2000)=2.4GB,而VM1将获得3GB500/(500+2000)=0.6GB。对吗?且慢,还记得内存limit隐含的上限是VM的配置内存吗?VM2只配置了2GB内存,因此最多只用到2GB内存。所以VM2还是只用2GB内存,剩下的1GB内存VM1可以占用。
      ==================================================================================================================================================================================================================
    2、FusionSphere 物理CPU与VCPU的关系梳理总结
    http://forum.huawei.com/enterprise/zh/forum.php?mod=viewthread&tid=322397

    背景说明:
    在项目和培训中多次被问题FusionSphere物理CPU和vCPU的对应或分配关系,一个物理CPU能虚拟出多少个vCPU,一个vCPU的主频是多少等问题。设置了CPU预留、份额与限制之后又是什么情况。
    看过之前的一些讨论,也没有定论,本着实践是检验整理的唯一标准,本文通过实验,并对照相关文档来梳理这些问题,希望能让大家有更清楚的理解。

    1. 系统可用的VCPU总数计算

    服务器CPU信息:
    1台R2288H V3,2个CPU, 10 核,超线程为2。总共2x10x2= 40个thread,每个Thread 2.3GHz。
    Haswell EP CPU 02311CDJ BC1M12CPU X86 series,2300**z,1.8V,64bit,105000mW,Haswell EP Xeon E5-2650 v3,10Core,with heatsink 2 2
    服务器BMC管理界面上查看 CPU信息
    在这里插入图片描述
    http://ark.intel.com/products/81705/Intel-Xeon-Processor-E5-2650-v3-25M-Cache-2_30-GHz
    在主机上部署FusionCompute R5C00, 登录CNA主机运行xentop命令查看CPU信息
    CPUs:40 @ 2294 z,主频总容量为40 x 2.294 GHz = 91.76 GHz。
    Domain 0默认配置2个VCPU,占用2 x 2.294 = 4.588 GHz
    用户可用的主频总容量 = 91.76 - 4.588 = 87.172 GHz
    在这里插入图片描述
    结论1: 系统可用的vCPU总数(逻辑处理器) = Socket数(CPU个数)x Core数(内核)x Thread数(超线程)
    1个VCPU = 1个超线程Thread。如下图:
    在这里插入图片描述
    CPU QoS
    如图所示,CPU预留容量为4.59GHz,可用容量为82.58GHz,说明除了VRM01的2个VCPU预留容量4588
    z之外的VCPU主频均是可用的,尽管该环境已创建了7台4 VCPU的VM,还可以创建更多VM,这些VM的VCPU总数可以远远超过当前系统显示可用的38个VCPU。

    在不对VRM01的VCPU进行限制的情况下,将VCPU份额自定义为128000,显示可使用的CPU数为38,说明如果需要的话VRM01可以占用该主机上的除了Domain 0之外的所有VCPU(Domain 0占用了2个VCPU)。
    在这里插入图片描述
    2. 虚拟机VCPU的分配与调度
    对虚拟机来说,不直接感知物理CPU,虚拟机的计算单元通过vCPU对象来呈现。虚拟机只看到VMM呈现给它的vCPU。在VMM中,每个vCPU对应一个VMCS(Virtual-Machine Control Structure)结构,当VCPU被从物理CPU上切换下来的时候,其运行上下文会被保存在其对应的VMCS结构中;当VCPU被切换到PCPU上运行时,其运行上下文会从对应的VMCS结构中导入到物理CPU上。通过这种方式,实现各vCPU之间的独立运行。

    从虚拟机系统的结构与功能划分可以看出,客户操作系统与虚拟机监视器共同构成了虚拟机系统的两级调度框架,如图所示是一个多核环境下虚拟机系统的两级调度框架。客户操作系统负责第2 级调度,即线程或进程在vCPU 上的调度(将核心线程映射到相应的VCPU上)。虚拟机监视器负责第1 级调度, 即vCPU在物理处理单元上的调度。两级调度的调度策略和机制不存在依赖关系。vCPU调度器负责物理处理器资源在各个虚拟机之间的分配与调度,本质上即把各个虚拟机中的vCPU按照一定的策略和机制调度在物理处理单元上可以采用任意的策略来分配物理资源, 满足虚拟机的不同需求。vCPU可以调度在一个或多个物理处理单元执行(分时复用或空间复用物理处理单元), 也可以与物理处理单元建立一对一固定的映射关系(限制访问指定的物理处理单元)。

    在这里插入图片描述
    3. CPU QoS说明
    Hypervisor层根据分时复用的原理实现对VCPU的调度,CPU QoS的原理是定期给各VCPU分配运行时间片,并对各VCPU运行的时间进行记账,对于消耗完时间片的虚拟CPU将被限制运行,直到获得时间片。以此控制虚拟机获得物理计算资源的比例。以上分配时间片和记账的时间周期很短,对虚拟机用户来说会感觉一直在运行。
    CPU预留定义了分配给该VM的最少CPU资源。
    CPU限制定义了分配虚拟机占用CPU资源的上限。
    CPU份额定义多个虚拟机在竞争CPU资源的时候按比例分配。
    CPU份额只在各虚拟机竞争计算资源时发挥作用,如果没有竞争,有需求的虚拟机可以独占主机的物理CPU资源。
    如果虚拟机根据份额值计算出来的计算能力小于虚拟机预留值,调度算法会优先按照虚拟机预留值分配给虚拟机,对于预留值超出按份额分配的计算资源的部分,调度算法会从主机上其他虚拟机的CPU上按各自的份额比例扣除。
    如果虚拟机根据份额值计算出来的计算能力大于虚拟机预留值,那么虚拟机的计算能力会以份额值计算为准。
    以一台主频为2800**z的单核物理机为例,如果满负载运行3台单VCPU的虚拟机A、B、C,分配情况如下。
    在这里插入图片描述
    结论2:由于采用分时复用的方式,在不做VCPU预留的条件下,系统可分配给VM的VCPU总数远远大于实际可提供的VCPU数目(具体能创建多少额外的VCPU依赖于物理CPU的性能和VCPU的使用情率),在出现资源争用的时根据CPU QoS中的预留和份额来分配资源。

    ============================================================================================================================================

    FusionCloud云计算vCPU资源计算公式(MHz)
    http://forum.huawei.com/enterprise/zh/forum.php?mod=viewthread&tid=301167

    vCPU 资源 = 物理CPU个数 * 物理CPU核数 * 单核线程数 * CPU频率

    举例:1个CPU,双核,每核2个线程,3.0GHz,那么vCPU资源 = 1 * 2 * 2 * 3.0GHz = 12GHz = 12000MHz。

    FusionCompute发放虚拟机流程中可对CPU资源进行限制,有2个重要参数:
    份额预留:分配的vCPU资源最小值
    份额限制:分配的vCPU资源最大值

    份额预留<=份额限制

    只有将份额预留选最大值时,vCPU独占1个物理CPU线程

    举例:创建1台2U2G的虚拟机,份额预留最大值为 2 * 3000MHz = 6000MHz。

    虚拟化场景,重载,许多情况下1台虚拟机每vCPU独占1个物理CPU线程。因此,为了云计算工程师快速方便估算物理服务器可承载的虚拟机数量,可认为1个物理CPU线程 = 1个vCPU。

    举例1:虚拟化场景,10台服务器,每台服务器2路8核2.8GHz的CPU,提供的vCPU个数 = 10 * 2 * 8 * 2 = 320个vCPU,可承载2U2G的虚拟机160个。

    举例2:虚拟化场景,10台服务器,每台服务器2路8核2.8GHz的CPU,提供的vCPU资源 = 10 * 2 * 8 * 2 * 2.8GHz = 896GHz,可承载2个vCPU 2.8GHz的虚拟机160个。

    桌面云场景,重载,许多情况下每个物理CPU核可承载5台虚拟机,因此,为了云计算工程师快速方便估算物理服务器的虚拟机密度,可认为 1个物理核 = 5个虚拟机。

    举例:桌面云场景,10台服务器,每台服务器2路8核2.8GHz的CPU,虚拟机密度 = 10 * 2 * 8 * 5 = 800 个虚拟机。

    总结:
    虚拟化场景:1个物理CPU线程 = 1个vCPU
    桌面云场景:1个物理核 = 5个虚拟机

    说明:上述场景的计算方法仅供快速估算,准确vCPU个数、虚拟机密度与CPU型号、频率、domain0规格、虚拟机规格强相关,需要进行详细分析和计算。

    展开全文
  • 多核cpu对于共享数据的操作

    千次阅读 2021-01-25 08:57:49
    CPU内部,多个核心之间有一条环形总线,当有某一个核心需要锁住cache的时候,这个总线会通知所有的核心,所以只要有某个核心使用了cmpxchg,那么其它的核肯定都会停下来,不会出现并发的情况。 重要的是这个缓存...
  • 计算机CPU处理,吞吐量

    千次阅读 2017-06-26 12:31:11
    它取决于信息能够多快地输入内存,CPU能够多快地取指令,数据能够多快地从内存取出或存入,以及所得结果能够多快地从内存送给一台外围设备.这些步骤中的每一步都关系到主存,因此,系统吞吐量主要取决于主存的存取周期. ...
  • cpu架构知识

    千次阅读 2022-01-17 10:06:20
    Part1架构概述从系统架构来看,目前的商用服务器大体...共享存储型多处理机有两种模型均匀存储器存取(Uniform-Memory-Access,简称UMA)模型非均匀存储器存取(Nonuniform-Memory-Access,简称NUMA)模型多核系统的存
  • iphone的cpu对于处理视频来说能力是非常有限的,所以在ios开发中,如果要进行视频处理,比如滤镜、美颜等,都会用到设备的GPU能力,也就是会用到opengl es的api,而CPU和GPU之间的数据传递效率十分低下,尤其是从GPU...
  • 线程共享的环境包括:进程代码段、进程的共有数据(利用这些共享的数据,线程很容易的实现相互之间的通讯)、进程打开的文件描述符、信号的处理器、进程的当前目录和进程用户ID与进程组ID。进程拥有这些共性的同时,...
  • 多核,多CPU之间的资源共享

    千次阅读 2016-05-31 15:36:19
    如果我们选择多个单核CPU,那么每一个CPU都需要有较为独立的电路支持,有自己的Cache,而他们之间通过板上的总线进行通信。假如在这样的架构上,我们要跑一个多线程的程序(常见典型情况),不考虑超线程,那么...
  • 目前统信uos系统能适配的打印机越来越多,但是能顺利连接上打印机还需要更多的经验和技巧,今天我就和大家分享一些我用uos系统连接windows共享打印机的经验方法。 一、首先你要弄清楚自己uos电脑的配置(架构、芯片...
  • 腾讯云标准型S2实例和阿里云共享型服务器区别在哪?如何选择?国内两大云产品商家的翘楚:腾讯云和阿里云。当这两家遭遇的时候你会选择谁呢?首先得知道这两款机型配置的不同之处,然后才能选择其中一款跟适合自己的...
  • 本文是zynq 7000 AMP模式 双裸核CPU同时运行的继续。本文主要是上文的基础上增加通过共享内存的方式,演示2个裸核的交互。 共享内存前先看看内存地址分布,这个图取自 ug585 4.1 节 address map 的表4-1 本文...
  • 原理介绍: 废话不多说,看图,看懂的给赞! 内核没有提供指定SPIs中断到特定cpu的接口。那代码我们就胡乱的看一下吧 static int gic_set_... unsigned int cpu = cpumask_any_and(mask_val, cpu_online_mask);
  • Intel CPU 微架构的演进与发展

    千次阅读 2021-11-21 22:11:25
    title: Intel CPU 微架构的演进与发展 date: 2021-11-21 22:10 ...本作品采用知识共享署名-非商业性使用-相同方式共享 4.0 国际许可协议进行许可, 转载请注明出处, 谢谢合作 因本人技术水平和知识面有限, 内容如有.
  • 往小了说,golang建议使用channel来共享信息而不是使用共享内存,这是一种优雅的方式,避免了数据同步带来的繁琐和低效。 往大了说,本质上还是让资源去调度请求,而不是让请求去调度资源。 资源就那么多,所有请求...
  • 一个平板电脑PCB文件共享下载,盈方微IMAP800 CPU PADS9.3 格式文件。需要的赶紧下载。 我都舍不得共享的。还是为了下载积分。豁出去了。
  • Java 中的伪共享详解及解决方案

    千次阅读 2020-01-09 22:05:44
    1. 什么是伪共享 CPU 缓存系统中是以缓存行(cache line)为单位存储的。目前主流的 CPU Cache 的 Cache Line 大小都是 64 Bytes...由于共享变量在 CPU 缓存中的存储是以缓存行为单位,一个缓存行可以存储多个变量...
  • CPU与线程

    千次阅读 2021-12-01 10:34:50
    CPU: 算术逻辑单元ALU(arithmetic and logic unit):实现多组算数运算和逻辑运算的组合逻辑电路 寄存器Registers:存储二进制代码,由具有存储功能的触发器构成。一个触发器可以存储1位二进制代码,故存放n位二进制...
  • CPU缓存和伪共享

    千次阅读 2019-04-15 14:36:35
    内存比CPU慢很多,现在获取内存中的一条数据大概需要200多个CPU周期(CPU cycles),而CPU寄存器一般情况下1个CPU周期就够了。 网页浏览器为了加快速度,会在本机存缓存以前浏览过的数据;传统数据库或NoSQL数据库为了...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 508,294
精华内容 203,317
关键字:

共享cpu

友情链接: barke.rar