精华内容
下载资源
问答
  • 内存分类

    千次阅读 2018-02-12 21:29:34
    为了加快系统的速度,提高系统的整体性能,我们看到,计算机中配置的内存数量越来越大,而内存的种类也越来越多。 内存新技术 计算机指令的存取时间主要取决于内存。对于现今的大多数计算机系统,内存的存取时间都...
    同步SRMA比异步SRAM更快。
    
     内存,或内存储器,又称为主存储器,是关系到计算机运行性能高低的关键部件之一,无疑是非常重要的。为了加快系统的速度,提高系统的整体性能,我们看到,计算机中配置的内存数量越来越大,而内存的种类也越来越多。 

     内存新技术 

     计算机指令的存取时间主要取决于内存。对于现今的大多数计算机系统,内存的存取时间都是一个主要的制约系统性能提高的因素。因此在判断某一系统的性能时,就不能单凭内存数量的大小,还要看一看其所用内存的种类,工作速度。 

     有关内存的名词 
     关于内存的名词众多。为了便于读者查阅,下面集中进行介绍。 
     ROM:只读存储器 
     RAM(Random Access Memory):随机存储器 
     DRAM(Dynamic RAM):动态随机存储器 
     PM RAM(Page Mode RAM):页模式随机存储器(即普通内存) 
     FPM RAM(Fast Page Mode RAM):快速页模式随机存储器 
     EDO RAM(Extended Data Output RAM)扩充数据输出随机存储器 
     BEDO RAM(Burst Extended Data Output RAM):突发扩充数据输出随机存储器 
     SDRAM(Sychronous Dynamic RAM):同步动态随机存储器 
     SRAM(Static RAM):静态随机存储器 
     Async SRAM(Asynchronous Static RAM):异步静态随机存储器 
     Sync Burst SRAM(Synchronous Burst Stacic RAM):同步突发静态随机存储器 
     PB SRAM(Pipelined Burst SRAM):管道(流水线)突发静态随机存储器 
     Cache:高速缓存 
     L2 Cache(Level 2 Cache):二级高速缓存(通常由SRAM组成) 
     VRAM(Video RAM):视频随机存储器 
     CVRAM(Cached Vedio RAM):缓存型视频随机存储器 
     SVRAM(Synchronous VRAM):同步视频随机存储器 
     CDRAM(Cached DRAM):缓存型动态随机存储器 
     EDRAM(Enhanced DRAM):增强型动态随机存储器 

     各种内存及技术特点 
     DRAM 动态随机存储器 
     DRAM主要用作主存储器。长期以来,我们所用的动态随机存储器都是PM RAM,稍晚些的为FPM RAM。为了跟上CPU越来越快的速度,一些新类型的主存储器被研制出来。它们是EDO RAM、BEDO RAM、SDRAM等。 
     DRAM芯片设计得象一个二进制位的矩阵,每一个位有一个行地址一个列地址。内存控制器要给出芯片地址才能从芯片中读出指定位的数据。一个标明为70ns的芯片要用70ns的时间读出一个位的数据。并且还要用额外的时间从CPU得到地址信息设置下一条指令。芯片制作技术的不断进步使这种处理效率越来越高。 

     FPM RAM 快速页模式随机存储器 
     这里的所谓“页”,指的是DRAM芯片中存储阵列上的2048位片断。FPM RAM是最早的随机存储器,在过去一直是主流PC机的标准配置,以前我们在谈论内存速度时所说的“杠7”,“杠6”,指的即是其存取时间为70ns,60ns。60ns的FPM RAM可用于总线速度为66MHz(兆赫兹)的奔腾系统(CPU主频为100,133,166和200MHz)。 
     快速页模式的内存常用于视频卡,通常我们也叫它“DRAM”。其中一种经过特殊设计的内存的存取时间仅为48ns,这时我们就叫它VRAM。这种经过特殊设计的内存具有“双口”,其中一个端口可直接被CPU存取,而另一个端口可独立地被RAM“直接存取通道”存取,这样存储器的“直接存取通道”不必等待CPU完成存取就可同时工作,从而比一般的DRAM要快些。 

     EDO RAM 扩充数据输出随机存储器 
     在DRAM芯片之中,除存储单元之外,还有一些附加逻辑电路,现在,人们已注意到RAM芯片的附加逻辑电路,通过增加少量的额外逻辑电路,可以提高在单位时间内的数据流量,即所谓的增加带宽。EDO正是在这个方面作出的尝试。扩展数据输出(Extended data out??EDO,有时也称为超页模式??hyper-page-mode
    展开全文
  • 虚拟化技术的分类及介绍

    万次阅读 多人点赞 2019-01-03 19:45:06
    虚拟化技术的分类及介绍   摘要 虚拟化是云计算系统中的一种基础技术,可以说当前一个云计算服务必定是构建在虚拟化的基础上的。本文首先介绍了不同抽象层次的虚拟化技术,之后对应用广泛的系统级虚拟化和操作...

    虚拟化技术的分类及介绍

     

    摘要

    虚拟化是云计算系统中的一种基础技术,可以说当前一个云计算服务必定是构建在虚拟化的基础上的。本文首先介绍了不同抽象层次的虚拟化技术,之后对应用广泛的系统级虚拟化和操作系统级虚拟化进行了更详细的分类和描述,最后介绍了各种典型虚拟化方案的具体实现。

     

    目录

    摘要 1

    目录 1

    1 引言 2

    2 虚拟化技术的分类 2

    2.1 不同抽象层次的虚拟化技术 3

    2.1.1 硬件抽象层上的虚拟化 3

    2.1.2 操作系统层上的虚拟化 3

    2.1.3 库函数层上的虚拟化 3

    2.1.4 编程语言层上的虚拟化 4

    2.2 系统级虚拟化 4

    2.2.1 可虚拟化架构和不可虚拟化架构 4

    2.2.2 按照实现方法分类 5

    2.2.3 按照实现结构分类 6

    2.3 操作系统级虚拟化 7

    3 典型虚拟化技术实现及其特点 8

    3.1 系统级虚拟化实现 8

    3.1.1 VMware 8

    3.1.2 Microsoft 9

    3.1.3 Xen 9

    3.1.4 KVM 10

    3.1.5 Oracle VM VirtualBox 10

    3.1.6 Bochs 10

    3.1.7 QEMU 10

    3.2 操作系统级虚拟化实现 10

    3.2.1 chroot 10

    3.2.2 LXC 11

    3.2.3 Docker 11

    3.2.4 Linux VServer 11

    3.2.5 Virtuozzo/OpenVZ 11

    参考文献 11

     

    1 引言

    虚拟化是计算机系统中的一个重要概念,基本上每个计算机系统都提供一个给上层软件的界面,从处理器提供的基本指令集到很多中间件系统提供的巨大的应用程序界面集。虚拟化本质上是扩展或替换一个现存界面来模仿另一个系统的行为,其对计算机系统的重要性主要体现在以下几个方面。

    相比高层软件(比如中间件和应用软件),硬件和底层系统软件变化得比较快,也就是说,我们面对的一种情况是旧有软件的维护跟不上下层平台更新的步伐。通过移植旧有软件的底层接口到新平台,可使得一大类的现有软件可以立刻在新平台上工作。

    在服务器机器上,一个组织为它提供的每个服务都分配一台虚拟机,接着,将虚拟机以最佳方式分配到物理服务器上。与进程不同,虚拟机能很简单地迁移到其他物理机器上,这增加了管理服务器基础设施的灵活性。这个方法能潜在地减少服务器计算机的投资并减少能量消耗,后者是大型服务器中心的关键问题。

    虚拟化技术和云计算的提供极为相关。云计算采用了这样一个模型,即作为一个服务,提供云上创建的存储、计算和高层对象。所提供的服务覆盖从诸如物理体系结构等的底层方面(基础设施即服务IaaS)到诸如软件平台(平台即服务PaaS),再到任意应用层次的服务(软件即服务SaaS)。云服务的提供被虚拟化技术直接驱动,允许为云的用户提供一个或多个虚拟机,供用户自己使用。

    分布式应用的需求也激发虚拟化解决方案的开发者去以很少的开销创建和销毁虚拟机。在可能需要动态地请求资源的应用中,这是必要的。例如对于多人在线游戏或分布式多媒体应用,通过采用合适的资源分配策略满足虚拟机服务质量需求,能提升对这样的应用的支持度。

    另一个好处是,在单台计算机上提供对几个不同操作系统环境的便利访问,虚拟化可用于在一种物理体系结构上提供多种操作系统类型。

    虚拟化技术起始于IBM370体系结构,它的VM操作系统能为运行在同一计算机上的不同程序提供几个完整的虚拟机。最近,人们对虚拟化的兴趣大增,有许多研究项目和商业系统为商用PC、服务器和云基础设施提供虚拟化解决方案。

     

    2 虚拟化技术的分类

    现代计算机系统是一个庞大的整体,整个系统的复杂性是不言而喻的。因而,整个计算机系统被分成了多个自下而上的层次,每一个层次都向上一层次呈现一个抽象,并且每一层只需知道下层抽象的接口,而不需要了解其内部运作机制。这样以层的方式抽象资源的好处是每一层只需要考虑本层设计以及与相邻层间的相互交互,从而大大降低了系统设计的复杂性,提高了软件的移植性。

    本质上,虚拟化就是由位于下层的软件模块,通过向上一层软件模块提供一个与它原先所期待的运行环境完全一致的接口的方法,抽象出一个虚拟的软件或硬件接口,使得上层软件可以直接运行在虚拟的环境上。虚拟化可以发生在现代计算机系统的各个层次上,不同层次的虚拟化会带来不同的虚拟化概念。

    如前文所述,虚拟化技术起源于上世纪70年代的IBM370体系,经过四十余年的发展,当前存在诸多实现在不同层次的虚拟化技术,原理不尽相同,且每一种技术都相当复杂。在本文中,将通过不同的角度对目前存在的较流行的虚拟化技术进行分类,并对其原理进行初步介绍,旨在对纷繁复杂的虚拟化技术有个整体认识及厘清不同虚拟化技术之间的相互关系。

     

    2.1 不同抽象层次的虚拟化技术

    在介绍各种虚拟化概念之前,先介绍虚拟化中的两个重要名词。在虚拟化中,物理资源通常有一个定语称为宿主(Host),而虚拟出来的资源通常有一个定语称为客户(Guest)。

    在计算机系统中,从底层至高层依次可分为:硬件层、操作系统层、函数库层、应用程序层,在对某层实施虚拟化时,该层和上一层之间的接口不发生变化,而只变化该层的实现方式。从使用虚拟资源的Guest的角度来看,虚拟化可发生在上述四层中的任一层。应当注意,在对Guest的某一层进行虚拟化时,并未对Host在哪一层实现它作出要求,这一点是时常引起混淆的地方。

     

    2.1.1 硬件抽象层上的虚拟化

    硬件抽象层上的虚拟化是指通过虚拟硬件抽象层来实现虚拟机,为客户机操作系统呈现和物理硬件相同或相近的硬件抽象层,又称为指令集级虚拟化,实现在此层的虚拟化粒度是最小的。

    实现在此层的虚拟化技术可以对整个计算机系统进行虚拟,即可将一台物理计算机系统虚拟化为一台或多台虚拟计算机系统,故又可称作系统级虚拟化。每个虚拟计算机系统(简称为虚拟机)都拥有自己的虚拟硬件(如CPU、内存和设备等),来提供一个独立的虚拟机执行环境。每个虚拟机中的操作系统可以完全不同,并且它们的执行环境是完全独立的。由于客户机操作系统所能看到的是硬件抽象层,因此,客户机操作系统的行为和在物理平台上没有什么区别。

     

    2.1.2 操作系统层上的虚拟化

    操作系统层上的虚拟化是指操作系统的内核可以提供多个互相隔离的用户态实例。这些用户态实例(经常被称为容器)对于它的用户来说就像是一台真实的计算机,有自己独立的文件系统、网络、系统设置和库函数等。

    由于这是操作系统内核主动提供的虚拟化,因此操作系统层上的虚拟化通常非常高效,它的虚拟化资源和性能开销非常小,也不需要有硬件的特殊支持。但它的灵活性相对较小,每个容器中的操作系统通常必须是同一种操作系统。另外,操作系统层上的虚拟化虽然为用户态实例间提供了比较强的隔离性,但其粒度是比较粗的。

     

    2.1.3 库函数层上的虚拟化

    操作系统通常会通过应用级的库函数提供给应用程序一组服务,例如文件操作服务、时间操作服务等。这些库函数可以隐藏操作系统内部的一些细节,使得应用程序编程更为简单。不同的操作系统库函数有着不同的服务接口,例如Linux的服务接口是不同于Windows的。库函数层上的虚拟化就是通过虚拟化操作系统的应用级库函数的服务接口,使得应用程序不需要修改,就可以在不同的操作系统中无缝运行,从而提高系统间的互操作性。

    例如,Wine就是在Linux上模拟了Windows的库函数接口,使得一个Windows应用程序能够在Linux上正常运行。

     

    2.1.4 编程语言层上的虚拟化

    另一大类编程语言层上的虚拟机称为语言级虚拟机,例如JVM(Java Virtual Machine)和微软的CLR(Common Language Runtime)。这一类虚拟机运行的是进程级的作业,所不同的是这些程序所针对的不是一个硬件上存在的体系结构,而是一个虚拟体系结构。这些程序的代码首先被编译为针对其虚拟体系结构的中间代码,再由虚拟机的运行时支持系统翻译为硬件的机器语言进行执行。

     

    2.2 系统级虚拟化

    系统级虚拟化即硬件抽象层上的虚拟化、指令集级虚拟化,是最早被提出和研究的一种虚拟化技术,当前存在多种此种技术的具体实现方案,在介绍它们之前,有必要先了解实现系统级虚拟化可采取的途径。

    在每台虚拟机中都有属于它的虚拟硬件,通过虚拟化层的模拟,虚拟机中的操作系统认为自己仍然是独占一个系统在运行,这个虚拟化层被称为虚拟机监控器(Virtual Machine Monitor,VMM)。VMM对物理资源的虚拟可以归结为三个主要任务:处理器虚拟化、内存虚拟化和I/O虚拟化。其中,处理器虚拟化是VMM中最核心的部分,因为访问内存或进行I/O本身就是通过一些指令来实现的。

     

    2.2.1 可虚拟化架构和不可虚拟化架构

    在系统级虚拟化中,虚拟计算机系统和物理计算机系统可以是两个完全不同ISA(Instruction Set Architecture,指令集架构)的系统,例如,可以在一个x86的物理计算机上运行一个安腾的虚拟计算机。但是,不同的ISA使得虚拟机的每一条指令都需要在物理机上模拟执行,从而造成性能上的极大下降。

    显然,相同体系结构的系统虚拟化通常会有比较好的性能,并且VMM实现起来也会比较简单。这种情况下虚拟机的大部分指令可以在处理器上直接运行,只有那些与硬件资源关系密切的敏感指令才会由VMM进行处理。此时面前的一个问题是,要能将这些敏感指令很好地筛选出来。但事实上,某些处理器在设计之初并没有充分考虑虚拟化的需求,导致没有办法识别出所有的敏感指令,因而不具备一个完备的可虚拟化结构。

    大多数的现代计算机体系结构都有两个或两个以上的特权级,用来分隔系统软件和应用软件。系统中有一些操作和管理关键系统资源的指令会被定为特权指令,这些指令只有在最高特权级上才能够正确执行。如果在非最高特权级上运行,特权指令会引发一个异常,处理器会陷入到最高特权级,交由系统软件来处理。

    在x86架构中,所有的特权指令都是敏感指令,然而并不是所有的敏感指令都是特权指令。

    为了VMM可以完全控制系统资源,它不允许虚拟机上操作系统直接执行敏感指令。如果一个系统上所有敏感指令都是特权指令,则能够用一个很简单的方法来实现一个虚拟环境:将VMM运行在系统的最高特权级上,而将客户机操作系统运行在非最高特权级上,当客户机操作系统因执行敏感指令而陷入到VMM时,VMM模拟执行引起异常的敏感指令,这种方法被称为“陷入再模拟”。

    总而言之,判断一个架构是否可虚拟化,其核心就在于该结构对敏感指令的支持上。如果一个架构中所有敏感指令都是特权指令,则称其为可虚拟化架构,否则称为不可虚拟化架构。

     

    2.2.2 按照实现方法分类

    系统级虚拟化有许多不同的具体实现方案,按照实现方法的不同,可划分为如下几个类别。

    (1)仿真(Emulation)

    我们已经知道,通过陷入再模拟敏感指令的执行来实现虚拟机的方法是有前提条件的:所有的敏感指令必须都是特权指令。如果一个体系结构上存在敏感指令不属于特权指令,那么其就存在虚拟化漏洞,可以采用一些方法来填补或避免这些漏洞。最简单直接的方法是,所有指令都采用模拟来实现,就是取一条指令,就模拟出这条指令执行的效果。这种方法称作仿真。

    仿真是最复杂的虚拟化实现技术,使用仿真方法,可以在一个x86处理器上运行为PowerPC设计的操作系统,这在其它的虚拟化方案中是无法实现的。甚至可以运行多个虚拟机,每个虚拟机仿真一个不同的处理器。此外,这种方法不需要对宿主操作系统的特殊支持,虚拟机可以完全作为应用层程序运行。

    正如前面提到的,使用仿真方法的主要问题是速度会非常慢。由于每条指令都必须在底层硬件上进行仿真,因此速度减慢100倍的情况也并不稀奇。若要实现高度保真的仿真,包括周期精度、CPU的缓存行为等,实际速度差距甚至可能会达到1000倍之多。

    使用这种方式的典型实现是Bochs。

    (2)完全虚拟化(Full Virtualization)

    在客户操作系统看来,完全虚拟化的虚拟平台和现实平台是一样的,客户机操作系统察觉不到是运行在一个虚拟平台上,这样的虚拟平台可以运行现有的操作系统,无须对操作系统进行任何修改,因此这种方式被称为完全虚拟化。

    进一步说,客户机的行为是通过执行反映出来的,因此VMM需要能够正确处理所有可能的指令。在实现方式上,以x86架构为例,完全虚拟化经历了两个阶段:软件辅助的完全虚拟化和硬件辅助的完全虚拟化。

    ①软件实现的完全虚拟化

    在x86虚拟化技术的早期,没有在硬件层次上对虚拟化提供支持,因此完全虚拟化只能通过软件实现。一个典型的做法是二进制代码翻译(Binary Translation)。

    二进制代码翻译的思想是,通过扫描并修改客户机的二进制代码,将难以虚拟化的指令转化为支持虚拟化的指令。VMM通常会对操作系统的二进制代码进行扫描,一旦发现需要处理的指令,就将其翻译成为支持虚拟化的指令块(Cache Block)。这些指令块可以与VMM合作访问受限的虚拟资源,或者显式地触发异常让VMM进一步处理。

    这种技术虽然能够实现完全虚拟化,但很难在架构上保证其完整性。因此,x86厂商在硬件上加入了对虚拟化的支持,从而在硬件架构上实现了虚拟化。

    ②硬件辅助完全虚拟化

    可以预料,如果硬件本身加入足够的虚拟化功能,可以截获操作系统对敏感指令的执行或者对敏感资源的访问,从而通过异常的方式报告给VMM,这样就解决了虚拟化的问题。硬件虚拟化时一种完备的虚拟化方法,因而内存和外设的访问本身也是由指令来承载,对处理器指令级别的截获就意味着VMM可以模拟一个与真实主机完全一样的环境。

    Intel的VT-x和AMD的AMD-V是这一方向的代表。以VT-x为例,其在处理器上引入了一个新的执行模式用于运行虚拟机,当虚拟机执行在这个特殊模式中时,它仍然面对的是一套完整的处理器寄存器集合和执行环境,只是任何敏感操作都会被处理器截获并报告给VMM。

    在当前的系统级虚拟化解决方案中,全虚拟化应用得非常普遍,典型的有知名的产品有VirtualBox、KVM、VMware Workstation和VMware ESX(它在其4.0版,被改名为VMware vSphere)、Xen(也支持全虚拟化)。

    (3)类虚拟化(Para-Virtualization)

    这样的虚拟平台需要对所运行的客户机操作系统进行或多或少的修改使之适应虚拟环境,因此客户机操作系统知道其运行在虚拟平台上,并且会去主动适应。这种方式被称为类虚拟化,有时也称作半虚拟化。另外,值得指出的是,一个VMM可以既提供完全虚拟化的虚拟平台,又提供类虚拟化的虚拟平台。

    类虚拟化是通过在源代码级别修改指令以回避虚拟化漏洞的方式来使VMM 能够对物理资源实现虚拟化。上面谈到x86 存在一些难以虚拟化的指令,完全虚拟化通过Binary Translation在二进制代码级别上来避免虚拟化漏洞。类虚拟化采取的是另一种思路,即修改操作系统内核的代码,使得操作系统内核完全避免这些难以虚拟化的指令。

    既然内核代码已经需要修改,类虚拟化进一步可以被用于优化I/O。也就是说,类虚拟化不是去模拟真实世界中的设备,因为太多的寄存器模拟会降低性能.相反,类虚拟化可以自定义出高度优化的协议I/O。这种I/O协议完全基于事务,可以达到近似物理机的速度。

    这种虚拟技术以Xen为代表,微软的Hyper-V所采用技术和Xen类似,也可以把Hyper-V归属于半虚拟化。

     

    2.2.3 按照实现结构分类

    在系统级虚拟化的实现中,VMM是一个关键角色,前面已介绍过VMM的组成部分。从Host实现VMM的角度出发,还可以将当前主流的虚拟化技术按照实现结构分为如下三类。

    1. Hypervisor模型

    Hypervisor这个术语是在 20 世纪 70 年代出现的,在早期计算机界,操作系统被称为Supervisor,因而能够在其他操作系统上运行的操作系统被称为 Hypervisor。

    在Hypervisor模型中,VMM首先可以被看做是一个完备的操作系统,不过和传统操作系统不同的是,VMM是为虚拟化而设计的,因此还具备虚拟化功能。从架构上来看,首先,所有的物理资源如处理器、内存和I/O设备等都归VMM所有,因此,VMM承担着管理物理资源的责任;其次,VMM需要向上提供虚拟机用于运行客户机操作系统,因此,VMM还负责虚拟环境的创建和管理。

    由于VMM同时具备物理资源的管理功能和虚拟化功能,因此,物理资源虚拟化的效率会更高一些。在安全方面,虚拟机的安全只依赖于VMM的安全。Hypervisor模型在拥有虚拟化高效率的同时也有其缺点。由于VMM完全拥有物理资源,因此,VMM需要进行物理资源的管理,包括设备的驱动。我们知道,设备驱动开发的工作量是很大的。因此,对于Hypervisor模型来说这是个很大的挑战。事实上,在实际的产品中,基于Hypervisor模型的VMM通常会根据产品定位,有选择地挑选一些I/O设备来支持,而不是支持所有的I/O设备。

    采用这种模型的典型是面向企业级应用的VMware vSphere。

     

    1. 宿主模型

    与Hypervisor模型不同。在宿主模型中,物理资源由宿主机操作系统管理。宿主机操作系统是传统操作系统,如Windows 、Linux等,这些传统操作系统并不是为虚拟化而设计的,因此本身并不具备虚拟化功能,实际的虚拟化功能由VMM来提供。VMM通常是宿主机操作系统独立的内核模块,有些实现中还包括用户态进程,如负责I/O虚拟化的用户态设备模型。 VMM通过调用宿主机操作系统的服务来获得资源, 实现处理器、内存和I/O设备的虚拟化。VMM创建出虚拟机之后,通常将虚拟机作为宿主机操作系统的一个进程参与调度。

    宿主模型的优缺点和Hypervisor模型恰好相反。宿主模型最大的优点是可以充分利用现有操作系统的设备驱动程序,VMM无须为各类I/O设备重新实现驱动程序,可以专注于物理资源的虚拟化。考虑到I/O设备种类繁多,千变万化, 设备驱动程序开发的工作量非常大,因此,这个优点意义重大。此外,宿主模型也可以利用宿主机操作系统的其他功能,例如调度和电源管理等,这些都不需要VMM重新实现就可以直接使用。

    宿主模型当然也有缺点,由于物理资源由宿主机操作系统控制,VMM得要调用宿主机操作系统的服务来获取资源进行虚拟化,而那些系统服务在设计开发之初并没有考虑虚拟化的支持,因此,VMM虚拟化的效率和功能会受到一定影响。此外,在安全方面,由于VMM是宿主机操作系统内核的一部分,因此,如果宿主机操作系统内核是不安全的,那么,VMM也是不安全的,相应地运行在虚拟机之上的客户机操作系统也是不安全的。换言之,虚拟机的安全不仅依赖于VMM的安全,也依赖于宿主机操作系统的安全。

    采用这种模型的典型是KVM、VirtualBox和VMware Workstation。

    1. 混合模型

    混合模型是上述两种模式的汇合体。VMM依然位于最低层,拥有所有的物理资源。与Hypervisor模式不同的是,VMM 会主动让出大部分I/O设备的控制权,将它们交由一个运行在特权虚拟机中的特权操作系统控制。相应地,VMM 虚拟化的职责也被分担.处理器和内存的虚拟化依然由VMM来完成,而I/O的虚拟化则由VMM和特权操作系统共同合作来完成。

    I/O设备虚拟化由VMM和特权操作系统共同完成,因此,设备模型模块位于特权操作系统中,并且通过相应的通信机制与VMM合作。

    混合模型集中了上述两种模型的优点。 VMM可以利用现有操作系统的I/O设备驱动程序,不需要另外开发。VMM直接控制处理器、内存等物理资源,虚拟化的效率也比较高。

    在安全方面,如果对特权操作系统的权限控制得当,虚拟机的安全性只依赖于VMM。当然,混合模型也存在缺点。由于特权操作系统运行在虚拟机上,当需要特权操作系统提供服务时,VMM需要切换到特权操作系统,这里面就产生上下文切换的开销。当切换比较频繁时,上下文切换的开销会造成性能的明显下降。出于性能方面的考虑,很多功能还是必须在VMM 中实现,如调度程序和电源管理等。

    采用这种模型的典型是Xen。

     

    2.3 操作系统级虚拟化

    在操作系统虚拟化技术中,每个节点上只有唯一的系统内核,不虚拟任何硬件设备。通过使用操作系统提供的功能,多个虚拟环境之间可以相互隔离。通常所说的容器(Container)技术,如目前为止最流行的容器系统Docker,即属于操作系统级虚拟化。此外,在不同的场景中,隔离出的虚拟环境也被称作虚拟环境(即VE,Virtual Environment)或虚拟专用服务器(即VPS,Virtual Private Server)。

    以容器技术为例,它有自己独特的优点,它的出现,一方面解决了传统操作系统所忽视和缺乏的应用程序间的独立性问题,另一方面,它避免了相对笨重的系统级虚拟化,是一种轻量级的虚拟化解决方案。

    操作系统领域一直以来面临的一个主要挑战来自于应用程序间存在的相互独立性和资源互操作性之间的矛盾,即每个应用程序都希望能运行在一个相对独立的系统环境下,不受到其他程序的干扰,同时又能以方便快捷的方式与其他程序交换和共享系统资源。当前通用操作系统更强调程序间的互操作性,而缺乏对程序间相对独立性的有效支持,然而对于许多分布式系统如Web服务、数据库、游戏平台等应用领域,提供高效的资源互操作同保持程序间的相对独立性具有同等重要的意义。

    主流虚拟化产品VMware和Xen等均采用Hypervisor模型(Xen采用的混合模型与Hypervisor模型差别不大,可统称为Hypervisor模型)。该模型通过将应用程序运行在多个不同虚拟机内,实现对上层应用程序的隔离。但由于Hypervisor 模型倾向于每个虚拟机都拥有一份相对独立的系统资源,以提供更为完全的独立性,这种策略造成处于不同虚拟机内的应用程序间实现互操作非常困难。例如, 即使是运行在同一台物理机器上,如果处于不同虚拟机内,那么应用程序间仍然只能通过网络进行数据交换,而非共享内存或者文件。而如果使用容器技术,由于各容器共享同一个宿主操作系统,能够在满足基本的独立性需求的同时提供高效的系统资源共享支持。

    容器技术还可以更高效地使用系统资源,由于容器不需要进行硬件虚拟以及运行完整操作系统等额外开销,相比虚拟机技术,一个相同配置的主机,往往可以运行更多数量的应用。此外,容器还具有更快速的启动时间,传统的虚拟机技术启动应用服务往往需要数分钟,而对于容器由于,直接运行于宿主内核,无需启动完整的操作系统,因此可以做到秒级、甚至毫秒级的启动时间,大大的节约了应用开发、测试、部署的时间。

     

    3 典型虚拟化技术实现及其特点

    3.1 系统级虚拟化实现

    3.1.1 VMware

    VMware是x86 虚拟化软件的主流广商之一。VMware的5位创始人中的3位曾在斯坦福大学研究操作系统虚拟化,项目包括SimOS系统模拟器和Disco虚拟机监控器。1998年,他们与另外两位创始人共同创建了VMware 公司,总部位于美国加州Palo Alto。

    VMware提供一系列的虚拟化产品,产品的应用领域从服务器到桌面。下面是VMware主要产品的简介,包括VMware ESX、VMware Server和VMware Workstation。

    VMware ESX Server是VMware的旗舰产品,后续版本改称VMware vSphere。ESX Server基于Hypervisor模型,在性能和安全性方面都得到了优化,是一款面向企业级应用的产品。VMware ESX Server支持完全虚拟化,可以运行Windows 、Linux、Solaris和Novell Netware等客户机操作系统。VMware ESX Server也支持类虚拟化,可以运行Linux 2. 6. 21 以上的客户机操作系统。ESX Server的早期版本采用软件虚拟化的方式,基于Binary Translation技术。自ESX Server 3开始采用硬件虚拟化的技术,支持Intel VT技术和AMD-V技术。

    VMware Server之前叫VMware GSX Server,是VMware面向服务器端的入门级产品。VMware Server采用了宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Server的功能与ESX Server类似,但是在性能和安全性上与ESX Server有所差距。VMware Server也有自己的优点,由于采用了宿主模型,因此VMware Server支持的硬件种类要比ESX Server多。

    VMware Workstation是VMware面向桌面的主打产品。与VMware Server类似,VMware Workstation也是基于宿主模型,宿主机操作系统可以是Windows或者Linux。VMware Workstation也支持完全虚拟化,可以运行Windows、Linux、Solaris、Novell Netware和FreeBSD等客户机操作系统。与VMware Server不同, VMware Workstation专门针对桌面应用做了优化,如为虚拟机分配USB设备,为虚拟机显卡进行3D加速等。

     

    3.1.2 Microsoft

    微软在虚拟化产品方面起步比VMware晚,但是在认识到虚拟化的重要性之后,微软通过外部收购和内部开发,推出了一系列虚拟化产品,目前已经形成了比较完整的虚拟化产品线。微软的虚拟化产品涵盖了服务器虚拟化(Hyper-V)和桌面虚拟化(Virtual PC)。

    Virtual PC是而向桌面的虚拟化产品,最早由Connectix公司开发,后来该产品被微软公司收购。Virtual PC是基于宿主模型的虚拟机产品,宿主机操作系统是Windows。早期版本也采用软件虚拟化方式,基于Binary Translation技术。之后版本已经支持硬件虚拟化技术。

    Windows Server 2008是微软推出的服务器操作系统,其中一项重要的新功能是虚拟化功能。其虚拟化架构采用的是混合模型,重要组件之一Hyper-V作为Hypervisor运行在最底层,Server 2008本身作为特权操作系统运行在Hyper-V之上。Server 2008采用硬件虚拟化技术,必须运行在支持Intel VT技术或者AMD-V 技术的处理器上。

     

    3.1.3 Xen

    Xen是一款基于GPL授权方式的开源虚拟机软件。Xen起源于英国剑桥大学Ian Pratt领导的一个研究项目,之后,Xen独立出来成为一个社区驱动的开源软件项目。Xen社区吸引了许多公司和科研院所的开发者加入,发展非常迅速。之后,Ian成立了XenSource公司进行Xen的商业化应用,并且推出了基于Xen的产品Xen Server。2007年,Ctrix公司收购了XenSource公司,继续推广Xen的商业化应用,Xen开源项目本身则被独立到www.xen.org。

    从技术角度来说,Xen基于混合模型,特权操作系统( 在Xen中称作Domain 0)可以是Linux、Solaris以及NetBSD,理论上,其他操作系统也可以移植作为Xen的特权操作系统。Xen最初的虚拟化思路是类虚拟化,通过修改Linux内核,实现处理器和内存的虚拟化,通过引入I/O的前端驱动/后端驱动(front / backend)架构实现设备的类虚拟化。之后也支持了完全虚拟化和硬件虚拟化技术。

     

    3.1.4 KVM

    KVM(Kernel-based Virtual Machine)也是一款基于GPL授权方式的开源虚拟机软件。KVM 最早由Qumranet公司开发,在2006年出现在Linux内核的邮件列表上,并于2007年被集成到了Linux 2.6.20内核中,成为内核的一部分。

    KVM支持硬件虚拟化方法,并结合QEMU来提供设备虚拟化。KVM的特点在于和Linux内核结合得非常好,而且和Xen一样,作为开源软件,KVM的移植性也很好。

     

    3.1.5 Oracle VM VirtualBox

    VirtualBox是一款开源虚拟机软件,类似于VMware Workstation。VirtualBox 是由德国Innotek公司开发,由Sun Microsystems公司出品的软件,使用Qt编写,在 Sun 被 Oracle 收购后正式更名成 Oracle VM VirtualBox。Innotek 以 GNU General Public License (GPL) 释出 VirtualBox。用户可以在VirtualBox上安装并且执行Solaris、Windows、DOS、Linux、BSD等系统作为客户端操作系统。现在由甲骨文公司进行开发,是甲骨文公司VM虚拟化平台技术的一部分。

     

    3.1.6 Bochs

        Bochs 是一个 x86 计算机仿真器,它在很多平台上(包括 x86、PowerPC、Alpha、SPARC 和 MIPS)都可以移植和运行。使 Bochs 不仅可以对处理器进行仿真,还可以对整个计算机进行仿真,包括计算机的外围设备,比如键盘、鼠标、视频图像硬件、网卡(NIC)等。

    Bochs 可以配置作为一个老式的 Intel® 386 或其后继处理器使用,例如 486、Pentium、Pentium Pro 或 64 位处理器。它甚至还可以对一些可选的图形指令进行仿真,例如 MMX 和 3DNow。

     

    3.1.7 QEMU

        QEMU是一套由Fabrice Bellard所编写的模拟处理器的自由软件。它与Bochs,PearPC近似,但其具有某些后两者所不具备的特性,如高速度及跨平台的特性,qemu可以虚拟出不同架构的虚拟机,如在x86平台上可以虚拟出power机器。kqemu为qemu的加速器,经由kqemu这个开源的加速器,QEMU能模拟至接近真实电脑的速度。

    QEMU本身可以不依赖于KVM,但是如果有 KVM的存在并且硬件(处理器)支持比如Intel VT功能,那么QEMU在对处理器虚拟化这一块可以利用KVM提供的功能来提升性能。换言之,KVM缺乏设备虚拟化以及相应的用户空间管理虚拟机的工具,所以它借用了QEMU的代码并加以精简,连同KVM一起构成了一个完整的虚拟化解决方案,不妨称之为:KVM+QEMU。

     

    3.2 操作系统级虚拟化实现

    3.2.1 chroot

    容器的概念始于 1979 年的 UNIX chroot,它是一个 UNIX 操作系统上的系统调用,用于将一个进程及其子进程的根目录改变到文件系统中的一个新位置,让这些进程只能访问到该目录。这个功能的想法是为每个进程提供独立的磁盘空间。其后在 1982年,它被加入到了 BSD 系统中。

     

    3.2.2 LXC

    LXC 的意思是 LinuX Containers,它是第一个最完善的 Linux 容器管理器的实现方案,是通过 cgroups 和 Linux 名字空间namespace实现的。LXC 存在于 liblxc 库中,提供了各种编程语言的 API 实现,包括 Python3、Python2、Lua、Go、Ruby 和 Haskell 等。与其它容器技术不同的是, LXC 可以工作在普通的 Linux 内核上,而不需要增加补丁。现在 LXC project 是由 Canonical 公司赞助并托管的。

     

    3.2.3 Docker

    Docker 是到现在为止最流行和使用广泛的容器管理系统。它最初是一个叫做 dotCloud 的 PaaS 服务公司的内部项目,后来该公司改名为 Docker。Docker 开始阶段使用的也是 LXC ,之后采用自己开发的 libcontainer 替代了它。不像其它的容器平台,Docker 引入了一整个管理容器的生态系统,这包括高效、分层的容器镜像模型、全局和本地的容器注册库、清晰的 REST API、命令行等等。稍后的阶段, Docker 推动实现了一个叫做 Docker Swarm 的容器集群管理方案。

     

    3.2.4 Linux VServer

        Linux-VServer 也是一个操作系统级虚拟化解决方案。Linux-VServer 对 Linux 内核进行虚拟化,这样多个用户空间环境—又称为 Virtual Private Server(VPS) 就可以单独运行,而不需要互相了解。Linux-VServer 通过修改 Linux 内核实现用户空间的隔离。

    Linux-VServer 也使用了 chroot 来为每个 VPS 隔离 root 目录。虽然 chroot 允许指定新 root 目录,但还是需要其他一些功能(称为 Chroot-Barrier)来限制 VPS 脱离其隔离的 root 目录回到上级目录。给定一个隔离的 root 目录之后,每个 VPS 就可以拥有自己的用户列表和 root 密码。

    2.4 和 2.6 版本的 Linux 内核支持 Linux-VServer,它可以运行于很多平台之上,包括 x86、x86-64、SPARC、MIPS、ARM 和 PowerPC。

     

    3.2.5 Virtuozzo/OpenVZ

    Virtuozzo是SWsoft公司(目前SWsoft已经改名为Parallels)的操作系统虚拟化软件的命名,Virtuozzo是商业解决方案,而OpenVZ是以Virtuozzo为基础的开源项目,它们采用的也是操作系统级虚拟化技术。OpenVZ 类似于 Linux-VServer,它通过对 Linux 内核进行补丁来提供虚拟化、隔离、资源管理和状态检查。每个 OpenVZ 容器都有一套隔离的文件系统、用户及用户组等。

     

    参考文献

    • 1 ] 金海, 廖小飞. 面向计算系统的虚拟化技术J]. 中国基础科学, 2008, 10(6):12-18.
    • 2 ] 英特尔开源软件技术中心. 系统虚拟化M]. 清华大学出版社, 2009.
    • 3 ] GeorgeCoulouris, 库鲁里斯, 金蓓弘,等. 分布式系统:分布式系统概念与设计M]. 机械工业出版社, 2013
    • 4 ] Andrew S. Tanenbaum, Maarten van Steen. 分布式系统原理与范型M]. 清华大学出版社, 2004.
    • 5 ] Barham P, Dragovic B, Fraser K, et al. Virtual machine monitors: Xen and the art of virtualizationJ]. Symposium on Operating System Principles, 2003, 36(August):164--177.
    • 6 ] Qumranet A K, Qumranet Y K, Qumranet D L, et al. kvm: the Linux virtual machine monitorJ]. Proc Linux Symposium, 2007.
    • 7 ]  Adams K, Agesen O. A comparison of software and hardware techniques for x86 virtualizationC]// ACM, 2006:2-13.
    • 8 ] Uhlig R, Neiger G, Rodgers D, et al. Intel virtualization technologyJ]. Computer, 2005, 38(5):48-56.
    • 9 ]  Garfinkel T, Rosenblum M. A Virtual Machine Introspection Based Architecture for Intrusion DetectionJ]. Proceedings of the Network & Distributed Systems Security Symposium, 2003:191--206.
    展开全文
  • 常用内存数据库介绍

    万次阅读 2018-07-09 23:18:55
    1. 内存数据库简介 1.1 概念 一、什么是内存数据库 传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,...

    1. 内存数据库简介

    1.1 概念

    一、什么是内存数据库

    传统的数据库管理系统把所有数据都放在磁盘上进行管理,所以称做磁盘数据库(DRDB:Disk-Resident Database)。磁盘数据库需要频繁地访问磁盘来进行数据的操作,由于对磁盘读写数据的操作一方面要进行磁头的机械移动,另一方面受到系统调用(通常通过CPU中断完成,受到CPU时钟周期的制约)时间的影响,当数据量很大,操作频繁且复杂时,就会暴露出很多问题。

    近年来,内存容量不断提高,价格不断下跌,操作系统已经可以支持更大的地址空间(计算机进入了64位时代),同时对数据库系统实时响应能力要求日益提高,充分利用内存技术提升数据库性能成为一个热点。

    在数据库技术中,目前主要有两种方法来使用大量的内存。一种是在传统的数据库中,增大缓冲池,将一个事务所涉及的数据都放在缓冲池中,组织成相应的数据结构来进行查询和更新处理,也就是常说的共享内存技术,这种方法优化的主要目标是最小化磁盘访问。另一种就是内存数据库(MMDB:Main Memory Database,也叫主存数据库)技术,就是干脆重新设计一种数据库管理系统,对查询处理、并发控制与恢复的算法和数据结构进行重新设计,以更有效地使用CPU周期和内存,这种技术近乎把整个数据库放进内存中,因而会产生一些根本性的变化。两种技术的区别如下表:

    内存数据库系统带来的优越性能不仅仅在于对内存读写比对磁盘读写快上,更重要的是,从根本上抛弃了磁盘数据管理的许多传统方式,基于全部数据都在内存中管理进行了新的体系结构的设计,并且在数据缓存、快速算法、并行操作方面也进行了相应的改进,从而使数据处理速度一般比传统数据库的数据处理速度快很多,一般都在10倍以上,理想情况甚至可以达到1000倍。

      而使用共享内存技术的实时系统和使用内存数据库相比有很多不足,由于优化的目标仍然集中在最小化磁盘访问上,很难满足完整的数据库管理的要求,设计的非标准化和软件的专用性造成可伸缩性、可用性和系统的效率都非常低,对于快速部署和简化维护都是不利的。

    2. 内存数据库历史和发展

    一、雏形期
    从上个世纪60年代末到80年代初。在这个时期中,出现了主存数据库的雏形。1969年IBM公司研制了世界上最早的数据库管理系统——基于层次模型的数据库管理系统IMS,并作为商品化软件投入市场。在设计IMS时,IBM考虑到基于内存的数据管理方法,相应推出了IMS/VS Fast Path。Fast Path是一个支持内存驻留数据的商业化数据库,但它同时也可以很好地支持磁盘驻留数据。在这个产品中体现了主存数据库的主要设计思想,也就是将需要频繁访问,要求高响应速度的数据直接存放在物理内存中访问和管理。在这个阶段中,包括网状数据库、关系数据库等其他各种数据库技术也都逐渐成型。
    二、技术理论成熟期
    1984年,D J DeWitt等人发表了《主存数据库系统的实现技术》一文。第一次提出了Main Memory Database(主存数据库)的概念。预言当时异常昂贵的计算机主存价格一定会下降,用户有可能将大容量的数据库全部保存在主存中,提出了AVL树、哈希算法、主存数据库恢复机制等主存数据库技术的关键理论,为主存数据库的发展指出了明确的方向 。
    1984年,D J DeWitt等人提出使用非易逝内存或预提交和成组提交技术作为主存数据库的提交处理方案,使用指针实现主存数据库的存取访问。
    1985年,IBM推出了IBM 370上运行的OBE主存数据库
    1986年,RB Hagman提出了使用检查点技术实现主存数据库的恢复机制。威斯康星大学提出了按区双向锁定模式解决主存数据库中的并发控制问题。并设计出MM-DBMS主存数据库。贝尔实验室推出了DALI主存数据库模型。
    1987年,ACM SIGMOD会议中提出了以堆文件(HEAP FILE)作为主存数据库的数据存储结构。Southern Methodist大学设计出MARS主存数据库模型。
    1988年普林斯顿大学设计出TPK主存数据库。
    1990年普林斯顿大学又设计出System M主存数据库。
    三、产品发展期和市场成长期
    随着互联网的发展,越来越多的网络应用系统需要能够支持大用户量并发访问、高响应速度的的数据库系统,主存数据库市场成熟
    半导体技术快速发展,半导体内存大规模生产,动态随机存取存储器(DRAM)的容量越来越大,而价格越来越低,这无疑为计算机内存的不断扩大提供了硬件基础,使得主存数据库的技术可行性逐步成熟
    1994年美国OSE公司推出了第一个商业化的,开始实际应用的主存数据库产品Polyhedra
    1998年德国SoftwareAG推出了Tamino Database。
    1999年日本UBIT会社开发出XDB主存数据库产品。韩国Altibase推出Altibase
    2000年奥地利的QuiLogic公司推出了SQL-IMDB
    2001年美国McObject推出eXtremeDB。加拿大Empress公司推出EmpressDB


    四、几种主存技术应用的比较
    第一代:用户定制的主存数据库。通过应用程序来管理内存和数据;不支持SQL语句, 不提供本地存储, 没有数据库恢复技术;性能好但很难维护和在别的应用中不能使用;应用在实时领域比如工厂自动化生产。
    第二代:简单功能的内存数据库。能够快速处理简单的查询;支持部分的 SQL语句和简单的恢复技术;主要目的是能够快速处理大量事务;针对简单事务处理领域,尤其是交换机, 移动通信等。
    第三代:通用的主存数据库。针对传统的商业关系型数据库领域,能够提供更高的性能、通用性以及稳定性;提供不同的接口来处理复杂的SQL语句和满足不同的应用领域;可以应用在计费、电子商务、在线安全领域,几乎包括磁盘数据库的所有应用领域。
    五、目前几种常见的通用内存数据库
    eXtremeDB:eXtremeDB实时数据库是McObject公司的一款特别为实时与嵌入式系统数据管理而设计的数据库,只有50K到130K的开销,速度达到微秒级。eXtremeDB完全驻留在主内存中,不使用文件系统(包括内存盘)。eXtremeDB采用了新的磁盘融合技术,将内存拓展到磁盘,将磁盘当做虚拟内存来用,实时性能保持微秒级的同时,数据管理量在32BIT下能达到20G。
    Oracle TimesTen:Oracle TimesTen是Oracle从TimesTen公司收购的一个内存优化的关系数据库,它为应用程序提供了实时企业和行业(例如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle TimesTen可作为高速缓存或嵌入式数据库被部署在应用程序层中,它利用标准的 SQL 接口对完全位于物理内存中的数据存储区进行操作。
    SolidDB:Solid Information Technology 成立于 1992 年,全球总部位于加州Cupertino,
    Solid数据管理平台将基于内存和磁盘的全事务处理数据库引擎、载体级高可用性及强大的数据复制功能紧密地融为一体。

    ALTIBASE公司从1999年就一直致力于内存数据库软件和其应用的开发,提供高性能和高可用性的软件解决方案。特别适合通信、网上银行、证券交易、实时应用和嵌入式系统领域。目前占据80%以上内存数据库市场,可以说是当今数据库软件技术的领导者。目前Altibase在国内成功案例也比较多,尤其是在电信行业,已经得到了广泛认可.

    4. 常用内存数据库

    4.1 SQLite

    SQLite是一个小型的C程序库,实现了独立的,可嵌入的,零配置的SQL数据库引擎。特性包括:

    • 事务操作是原子,一致,孤立,并且持久的(ACID),即使在系统崩溃和电源故障之后。
    • 零配置——不需要安装和管理。
    • 实现了绝大多数SQL92标准。
    • 整个数据库存储在一个单一的文件中。
    • 数据库文件可以在不同字节序的机器之间自由地共享。
    • 支持最大可达2T的数据库。 (241 字节)
    • 字符串和BLOB类型的大小最大可达 2G 字节(231字节)。
    • 小的代码: 完整配置的少于250KB,忽略一些可选特性的少于150KB。
    • 在大多数常见操作上比流行的客户/服务器数据库引擎更快
    • 简单,易于使用的API
    • 内建TCL绑定 另外提供可用于许多其他语言的绑定。
    • 具有良好注释的源代码,95%经过测试。
    • 独立:没有外部依赖。
    • 源代码位于公共域。 可用于任何用途。

    SQLite发行版包含一个独立的命令行访问程序(sqlite),可用于管理SQLite数据库,并适合作为一个如何使用SQLite库的例子。

    License: SQLite使用Public domain授权(注),对于个人使用和商业使用都是免费的。

    技术上的优点和特性
    SQLite是一个轻量级、跨平台的关系型数据库。


    ◇轻量级

    先说它的第一个特色:轻量级。想必SQLite的作者很看重这个特性,连它的Logo都是用的“羽毛”,来显摆它的轻飘飘。SQLite和C/S模式的数据库软件不同,它是进程内的数据库引擎,因此不存在数据库的客户端和服务器。使用SQLite一般只需要带上它的一个动态库,就可以享受它的全部功能。而且那个动态库的尺寸也挺小,以版本3.6.11为例,Windows下487KB、Linux下347KB。

    ◇ 绿色软件

    SQLite的另外一个特点是绿色:它的核心引擎本身不依赖第三方的软件,使用它也不需要“安装”。所以在部署的时候能够省去不少麻烦。

    ◇单一文件

    所谓的“单一文件”,就是数据库中所有的信息(比如表、视图、触发器、等)都包含在一个文件内。这个文件可以copy到其它目录或其它机器上,也照用不误。

    ★技术上的缺点和不足

    ◇并发访问的锁机制
    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    SQL标准支持不全
    在它的官方网站上,具体列举了不支持哪些SQL92标准。我个人感觉比较不爽的是不支持外键约束。

    ◇网络文件系统(以下简称NFS)
    有时候需要访问其它机器上的SQLite数据库文件,就会把数据库文件放置到网络共享目录上。这时候你就要小心了。当SQLite文件放置于NFS时,在并发读写的情况下可能会出问题(比如数据损坏)。原因据说是由于某些NFS的文件锁实现上有Bug。

    ★编程语言接口
    SQLite支持很多种语言的编程接口。这对于我这种喜欢混用多种编程语言的人来说,是很爽的。下面我大概介绍一下。

    ◇C/C++
    由于SQLite本身是C写的,它自带的API也是C接口的。所以C/C++用起来最直接了。假如你不喜欢面向过程的C API风格,可以另外找个C++的包装库。想重新发明轮子的同学,也可以自己包装一个。
    ◇Java
    如果要用Java访问SQLite,可以通过SQLite的JDBC驱动,或者通过专门的SQLite包装库。我个人建议走JDBC方式,万一将来要换数据库,代码就不用大改。
    ◇Python
    pysqlite是Python操作SQLite的首选。从Python 2.5开始,它已经被整合到Python的标准库中。看来Python社区还是蛮喜欢SQLite嘛。
    ◇.Net
    对于喜欢.Net的同学,可以通过SQLite的ADO.NET驱动来访问。
    ◇Ruby
    Ruby可以通过SQLite-Ruby操作SQLite数据库,不过我没用过。
    ◇Perl
    在CPAN上有DBD::SQLite,不过我也没用过。

    ★一些非技术的参考因素

    需要根据“如何选择开源项目”里面提到的几个参考因素,再评估一下。
    ◇授权协议(License)
    SQLite使用的是Public Domain协议,这是最爽一种,可以放心大胆地用。
    ◇用户的普及程度
    最近这几年,使用SQLite的人越来越多。包括一些大公司也开始把它整合到产品中(比如Google的Gears、Apple的Safari、Adobe的AIR)。
    ◇开发的活跃程度
    如果到SQLite的Change Log上大致了解一下,可以看出最近5年基本上每1-2个月都会有更新。说明开发的活跃度还是非常高的。

    SQLite不同于其他大部分的SQL数据库引擎,因为它的首要设计目标就是简单化:

    • 易于管理
    • 易于使用
    • 易于嵌入其他大型程序
    • 易于维护和配置

    许多人喜欢SQLite因为它的小巧和快速. 但是这些特性只是它的部分优点, 使用者还会发现SQLite是非常稳定的. 出色的稳定性源于它的简单, 越简单就越不容易出错. 除了上述的简单、小巧和稳定性外, 最重要的在于SQLite力争做到简单化.

    简单化在一个数据库引擎中可以说是一个优点, 但也可能是个缺点, 主要决定于你想要做什么. 为了达到简单化, SQLite省略了一些人们认为比较有用的特性, 例如高并发性、 严格的存取控制、丰富的内置功能、 存储过程、复杂的SQL语言特性、 XML以及Java的扩展, 超大的万亿级别的数据测量等等. 如果你需要使用上述的这些特性并且不介意它们的复杂性, 那么SQLite也许就不适合你了. SQLite没有打算作为一个企业级的数据库引擎, 也并不打算和Oracle或者PostgreSQL竞争.

    仅凭经验来说SQLite适用于以下场合: 当你更看中简单的管理、使用和维护数据库, 而不是那些企业级数据库提供的不计其数的复杂功能的时候,使用SQLite是一个比较明智的选择. 事实也证明, 人们在许多情况下已经清楚的认识到简单就是最好的选择.

    4.1.1 SQLite最佳试用场合

    · 网站

    作为数据库引擎SQLite适用于中小规模流量的网站(也就是说, 99.9%的网站). SQLite可以处理多少网站流量在于网站的数据库有多大的压力. 通常来说, 如果一个网站的点击率少于100000次/天的话, SQLite是可以正常运行的. 100000次/天是一个保守的估计, 不是一个准确的上限. 事实证明, 即使是10倍的上述流量的情况下SQLite依然可以正常运行.

    · 嵌入式设备和应用软件

    因为SQLite数据库几乎不需要管理, 因此对于那些无人值守运行或无人工技术支持的设备或服务, SQLite是一个很好的选择. SQLite能很好的适用于手机, PDA, 机顶盒, 以及其他仪器. 作为一个嵌入式数据库它也能够很好的应用于客户端程序.

    · 应用程序文件格式

    SQLite作为桌面应用程序的本地磁盘文件格式取得了巨大成功.例如金融分析工具、CAD 包、档案管理程序等等. 一般的数据库打开操作需要调用sqlite3_open()函数,并且标记一个显式本地事务的起始点(BEGIN TRANSACTION)来保证以独占的方式得到文件的内容. 文件保存将执行一个提交(COMMIT)同时标记另一个显式本地事务起始点. 这种事务处理的作用就是保证对于应用程序数据文件的更新是原子的、持久的、独立的和一致的.

    数据库里可以加入一些临时的触发器,用来把所有的改变记录在一张临时的取消/重做日志表中. 当用户按下取消/重做按钮的时候这些改变将可以被回滚. 应用这项技术实现一个无限级的取消/重做功能只需要编写很少的代码.

    · 替代某些特别的文件格式

    许多程序使用fopen(), fread(), 或 fwrite()函数创建和管理一些自定义的文件用来保存数据. 使用SQLite替代这些自定义的文件格式将是一种很好的选择.

    · 内部的或临时的数据库

    对于那些有大量的数据需要用不同的方式筛选分类的程序, 相对于编写同样功能的代码, 如果你把数据读入一个内存中的SQLite数据库, 然后使用连接查询和ORDER BY子句按一定的顺序和排列提取需要的数据, 通常会更简单和快速. 按照上述的方法使用内嵌的SQLite数据库将会使程序更富有灵活性, 因为添加新的列或索引不用重写任何查询语句.

    · 命令行数据集分析工具

    有经验的SQL用户可以使用SQLite命令行程序去分析各种混杂的数据集. 原是数据可以从CSV(逗号分隔值文件)文件中导入, 然后被切分产生无数的综合数据报告. 可能得用法包括网站日志分析, 运动统计分析, 编辑规划标准, 分析试验结果.

    当然你也可以用企业级的客户端/服务器数据库来做同样的事情. 在这种情况下使用SQLite的好处是: SQLite的部署更为简单并且结果数据库是一个单独的文件, 你可以把它存储在软盘或者优盘或者直接通过email发给同事.

    · 在Demo或测试版的时候作为企业级数据库的替代品

    如果你正在编写一个使用企业级数据库引擎的客户端程序, 使用一个允许你连接不同SQL数据库引擎的通用型数据库后台将是很有意义的. 其更大的意义在于将SQLite数据库引擎静态的连接到客户端程序当中,从而内嵌SQLite作为混合的数据库支持. 这样客户端程序就可以使用SQLite数据库文件做独立的测试或者验证.

    · 数据库教学

    因为SQLite的安装和使用非常的简单(安装过程几乎忽略不计, 只需要拷贝SQLite源代码或sqlite.exe可执行文件到目标主机, 然后直接运行就可以) 所以它非常适合用来讲解SQL语句. 同学们可以非常简单的创建他们喜欢的数据库, 然后通过电子邮件发给老师批注或打分. 对于那些感兴趣怎样实现一个关系型数据库管理系统(RDBMS)的高层次的学生, 按照模块化设计且拥有很好的注释和文档的SQLite源代码, 将为他们打下良好的基础. 这并不是说SQLite就是如何实现其他数据库引擎的精确模型, 但是很适合学生们了解SQLite是如何快速工作的, 从而掌握其他数据库系统的设计实现原则.

    · 试验SQL语言的扩展

    SQLite简单且模块化的设计使得它可以成为一个用来测试数据库语言特性或新想法的优秀的原型平台

    4.1.2 哪些场合适合使用其他的关系型数据库管理系统(RDBMS)

    · 客户端/服务器程序

    如果你有许多的客户端程序要通过网络访问一个共享的数据库, 你应当考虑用一个客户端/服务器数据库来替代SQLite. SQLite可以通过网络文件系统工作, 但是因为和大多数网络文件系统都存在延时, 因此执行效率不会很高. 此外大多数网络文件系统在实现文件逻辑锁的方面都存在着bug(包括Unix 和windows). 如果文件锁没有正常的工作, 就可能出现在同一时间两个或更多的客户端程序更改同一个数据库的同一部分, 从而导致数据库出错. 因为这些问题是文件系统执行的时候本质上存在的bug, 因此SQLite没有办法避免它们.

    好的经验告诉我们, 应该避免在许多计算机需要通过一个网络文件系统同时访问同一个数据库的情况下使用SQLite.

    · 高流量网站

    SQLite通常情况下用作一个网站的后台数据库可以很好的工作. 但是如果你的网站的访问量大到你开始考虑采取分布式的数据库部署, 那么你应当毫不犹豫的考虑用一个企业级的客户端/服务器数据库来替代SQLite.

    · 超大的数据集

    当你在SQLite中开始一个事务处理的时候(事务处理会在任何写操作发生之前产生, 而不是必须要显示的调用BEGIN…COMMIT), 数据库引擎将不得不分配一小块脏页(文件缓冲页面)来帮助它自己管理回滚操作. 每1MB的数据库文件SQLite需要256字节. 对于小型的数据库这些空间不算什么, 但是当数据库增长到数十亿字节的时候, 缓冲页面的尺寸就会相当的大了. 如果你需要存储或修改几十GB的数据, 你应该考虑用其他的数据库引擎.

    · 高并发访问

    SQLite对于整个数据库文件进行读取/写入锁定. 这意味着如果任何进程读取了数据库中的某一部分, 其他所有进程都不能再对该数据库的任何部分进行写入操作. 同样的, 如果任何一个进程在对数据库进行写入操作, 其他所有进程都不能再读取该数据库的任何部分. 对于大多数情况这不算是什么问题. 在这些情况下每个程序使用数据库的时间都很短暂, 并且不会独占, 这样锁定至多会存在十几毫秒. 但是如果有些程序需要高并发, 那么这些程序就需要寻找其他的解决方案了.

    方面

    具体要求

    必要条件

    详细描述

    License

    是否收费

    免费使用

    是否开源

    开源

    是否有技术支持

    主要是社区支持,如果需要专业支持需要购买

    商业目的的分发版本是否仍要收费

    免费

    其他

    性能

    数据容量支持100000条以上记录

    支持

    并发查询处理能力

    SQLite在并发(包括多进程和多线程)读写方面的性能一直不太理想。数据库可能会被写操作独占,从而导致其它读写操作阻塞或出错。

    查询速度

    修改速度

    平台支持

    32/64位

    全部支持

    Linux/window/UNIX/mobile

    支持Linux/Mac OS/Windows

    运行方式支持

    支持嵌入式

    支持

    支持独立运行

    不支持

    连接方式支持

    支持ODBC

    默认不支持,必须通过第三方的ODBC驱动

    支持JDBC

    默认不支持,必须通过第三方的JDBC驱动

    支持内存访问

    通过c接口(专用API)

    支持网络访问

    不支持

    SQL支持

    支持SQL

    支持

    支持Index,Trigger,

    Constrains,Views

    支持,有资料说其不支持外键约束。

    管理界面

    支持管理界面

    支持CLI

    管理界面友好程度

    较差

    4.2 Altibase

    Altibase™内存数据库管理系统(DBMS),内存数据管理系统的最新技术,是一个在事务优先的环境中提供高性能和高可用性的软件解决方案。Altibase提供极限性能、容错能力和事务管理的方便性,特别是在通信、网上银行、证券交易、实时应用和嵌入式系统领域。Altibase能够最大限度的发挥数据库服务系统的潜力,使用Altibase能大大增强您公司的数据服务器的处理能力。

    Altibase™内存DBMS为需要容错服务的系统提供实时数据库复制的功能。采用Altibase数据库复制的系统可以实现高性能、高可用性、数据库一致性、负载平衡和系统可伸缩性。如果您希望您的业务能够实现最大的成功,请在您的事务优先的系统中使用我们的Altibase数据库复制解决方案。

    资料比较少,且需要商业License,没有详细去研究

    4.3 Oracle 内存数据库系列 Berkeley DB 和 TimesTen

    Oracle是最重要的商业数据库产品提供商,它也有内存数据库的产品系列:主要就是Oracle Berkeley DB 和 Times Ten.前者是只支持嵌入式内存数据,后者是独立的内存优化数据库。

    4.3.1 Oracle Berkeley DB

    Oracle Berkeley DB是Oracle 收购了开源数据库厂商后推出的产品,其前身是Berkeley DB。它有开源版本,但且对于开源软件免费。商业版本是要付费。

    Oracle Berkeley DB 系列的可嵌入开源数据库为开发人员提供了无需管理的快速、可靠的本地持久性。Oracle Berkeley DB 系列通常部署为“前沿”数据库,为不需要 SQL 的应用程序用例提供很高的性能、可靠性、可伸缩性以及可用性。

    Oracle Berkeley DB 产品系列

    Berkeley DB — 事务处理式存储引擎,用于基本键/值数据结构中的非类型化数据 — 新增!版本 4.7 现已推出

    — 针对 Java 环境优化的纯 Java 版 Berkeley DB — 新增!版本 3.3

    Berkeley DB XML — 原生 XML 数据库,可基于 XQuery 访问容器中存储的文档,并根据其内容进行索引 — 新增!版本 2.4 现已推出

    4.3.2 Oracle TimesTen

    Oracle 内存数据库 TimesTen 是一个针对内存进行了优化的关系数据库,它为应用程序提供了当今实时企业和行业(如电信、资本市场和国防)所需的即时响应性和非常高的吞吐量。Oracle 内存数据库 TimesTen 作为独立或嵌入式数据库部署在应用层中,利用标准的 SQL 接口对完全位于物理内存中的数据库进行操作。它也可以用作 Oracle 数据库的内存中数据库缓存,以改进用户应用程序的响应时间和吞吐量。

    4.4 eXtremeDB

    eXtremeDB内存式实时数据库是为实时系统及嵌入式系统而特别设计的数据库。与同类产品不同,eXtremeDB不是通过 对企业数据库面向实时嵌入式应用进行剪裁而来;而是总结了30年来McObject公司在编译器、实时编程、数据管理、内核级驱 动软件等领域的经验,面向实时嵌入式应用从头开发的最新实时数据管理技术。

    eXtremeDB满足了您对实时数据库的一切期待:高级数据定义语言、并行访问、基于交易及灵活的索引… …等等。不仅如此,出乎您的意外,eXtremeDB在紧凑的引擎中还提供诸如事件触发、目标历史等等功能。

    eXtremeDB嵌入式数据库满足更多的实时开发的要求。

    · 最快的内存数据库。

    · 极小尺寸和极小的内存消耗

    · 多种索引支持

    · 高可用性-组合选项

    · 非常灵活的数据存储: 内存式,磁盘式或混合式

    · 多种应用接口: 两种 SQL, 两种更快的原始接口

    · 几乎牢不可破 -

    又一个商业内存数据库产品,这个特点是实时数据库,号称最快。

    4.5 H2 Database

    h2是Thomas Mueller提供的一个开源的、纯java实现的关系数据库,官方网站:http://www.h2database.com/html/main.html

    它的主要特性是:

    • 非常速的数据库引擎
    • 开源、免费数据库
    • 支持 JDBC和ODBC API,支持SQL
    • 支持嵌入式,服务器和集群模式。支持内存数据库。
    • 提供基于浏览器的管理控制台
    • 整个应用本身只有1MB左右。

    其他特性还包括

    • 基于磁盘或内存的数据库、表,支持只读数据库、临时表。
    • 两段式事务支持
    • 支持多个连接。表级别的锁。
    • 基于成本的优化,为复杂查询使用遗传算法,零管理。
    • 滚动的、可修改的result set支持。支持大结果集、外部结果排序。
    • 加密数据库(AES或XTEA),SHA-256密码加密。

    性能比较(摘自h2database网站)

    嵌入模式下H2的性能比较

    Test Case

    Unit

    H2

    HSQLDB

    Derby

    Simple: Init

    ms

    610

    657

    3187

    Simple: Query (random)

    ms

    297

    312

    1828

    Simple: Query (sequential)

    ms

    203

    266

    1766

    Simple: Update (random)

    ms

    1078

    1484

    22031

    Simple: Delete (sequential)

    ms

    234

    281

    7407

    Simple: Memory Usage

    MB

    6

    7

    11

    BenchA: Init

    ms

    859

    438

    4047

    BenchA: Transactions

    ms

    5266

    2875

    17500

    BenchA: Memory Usage

    MB

    9

    14

    10

    BenchB: Init

    ms

    4016

    2687

    16875

    BenchB: Transactions

    ms

    2609

    3282

    4250

    BenchB: Memory Usage

    MB

    9

    10

    8

    BenchC: Init

    ms

    891

    594

    5766

    BenchC: Transactions

    ms

    4359

    75438

    11718

    BenchC: Memory Usage

    MB

    9

    18

    9

    Executed statements

    #

    594255

    594255

    594255

    Total time

    ms

    20422

    88314

    96375

    Statements per second

    #

    29098

    6728

    6166

    .Net使用H2
    • 嵌入式应用。有一个项目在为.Net使用H2,使用CLI重新编译H2。还没有深入关注。
    • ODBC。但性能一般。

    4.5 其他内存数据库

    包括Derby, HSQLDB等.

    ——————————————————————————————————————————————————————-

    In-memory database in wikipedia: (http://en.wikipedia.org/wiki/In-memory_database)

    Products

    Product nameLicenseDescription
    Adaptive Server Enterprise (ASE) 15.5Proprietaryenterprise database from Sybase)[4]
    Apache DerbyApache License 2.0Java RDBMS
    AltibaseProprietaryhas in-memory and disk table; HYBRID DBMS
    BlackRayGNU General Public Licence (GPLv2) and BSD License
    CSQLGNU General Public Licence or proprietary
    DatablitzProprietaryDBMS
    EloqueraProprietaryIn-memory, In-memory:persist modes
    eXtremeDBcommercial productDBMS, also check out its open source PERST dbms.
    FleetDBMITNOSQL db with Writing to an append-only log to provide durability.
    H2Mozilla Public License or Eclipse Public Licensehas a memory-only mode
    HSQLDBBSD licensehas a memory-only mode
    IBM TM1Proprietaryin-memory BI and data analysis
    InfoZoomProprietaryin-memory BI and data analysis
    KDBProprietaryDBMS, also supports disk based data
    membaseApache LicenseNoSQL, hybrid
    MicroStrategy in-memory BI for MicroStrategy 9
    MonetDBMonetDB License
    MySQLGNU General Public License or proprietaryhas a cluster server which uses a main-memory storage engine
    Oracle Berkeley DBSleepycat Licensecan be configured to run in memory only
    Panorama for Windows and Macintosh, both single user and server versions
    ParAccelProprietaryin-memory, columnar, relational, ACID-compliant; disk-based mode as well
    Polyhedra IMDBProprietaryrelational, supports High-Availability; acquired in 2001 by ENEA
    QlikView BI-tool developed by QlikTech
    RDM EmbeddedProprietaryincluding hybrid
    RDM ServerProprietaryincluding hybrid
    RedisBSDNoSQL
    solidDB by IBM including hybrid, HSB-based HA, Shared memory, embedded, XA, etc.
    SAP HANA databaseProprietaryDatabase engine of the SAP In-Memory Appliance (SAP HANA) produced by SAP AG
    SQLitePublic domainhybrid, RAM and disk dbs can be used together
    Starcounter in-memory object relational dbms
    TimesTen by Oracle in memory only or as a cache for Oracle Database
    VertipaqProprietaryMicrosoft PowerPivot and Microsoft Analysis Services in-memory BI engine
    VoltDBGNU General Public License v3in-memory
    TREX search engine in the SAP NetWeaver integrated technology platform produced by SAP AG
    Xcelerix by Frontex commercial product

    展开全文
  • 在之前推送的文章《内存是手游的硬伤——腾讯游戏谈Unity游戏Mono内存管理泄漏问题》中,已经对腾讯游戏在Unity游戏开发过程中常见的Mono内存管理问题进行了介绍,收到了很多用户的反馈,希望能够更全面的介绍关于...

    WeTest导读

    本文通过对内存泄漏(what)及其危害性(why)的介绍,引出在Unity环境下定位和修复内存泄漏的方法和工具(how)。最后提出了一些避免泄漏的方法与建议。

    在之前推送的文章《内存是手游的硬伤——腾讯游戏谈Unity游戏Mono内存管理及泄漏问题》中,已经对腾讯游戏在Unity游戏开发过程中常见的Mono内存管理问题进行了介绍,收到了很多用户的反馈,希望能够更全面的介绍关于unity内存管理的问题。本期微信推送腾讯WeTest团队邀请到了公司中资深的测试专家Arthuryu,对Unity内存泄漏进行一个更加系统的介绍。

    内存泄漏及其危害

    相信各位程序猿们或多或少都会听到过内存泄漏这个名词,但是对于一些新手猿来说,或许不是很了解。内存泄漏?是内存漏出来了么?和霸气侧漏一样么?让我们先来看一下wikipedia的定义:


    看了一遍冗长的定义,或许各位猿们心中就是一个大写的“晕”字。让我们打一个通俗的比方来解释下这个定义。

    内存泄漏,可以通俗解释为“借银行钱不还”。在计算机的二进制世界里,操作系统就是银行;每一笔贷款,都是一次内存的申请;而你,就是一个应用程序。即银行贷款 应用程序操作系统申请内存。当然,在计算机世界中,我们需要感谢操作系统,因为他是一个不收利息的银行,你借了多少内存,你就只需要还回多少内存。那么我们可以总结一下,内存泄漏的简单定义,就是申请了内存,却没有在该释放的时候释放

    如果你总是贷款而不还钱,那么银行里的钱就越来越少,最终导致其他人要借钱时,就无钱可借了。现实生活中,银行为了避免无钱可接,就会把总是借钱不还的人拉入黑名单,不再借他钱;而操作系统则更加凶残,他会直接“做了你”,操作系统将会直接kill掉应用程序。由此可以看出,内存泄漏的危害性与严重性,如果持续泄漏,将因内存占用过大而导致应用崩溃。当然泄漏还有其他的危害,例如内存被无用对象占用,导致接下来的内存分配需要更高的时间成本,从而造成游戏的卡顿等等。

    Unity中的内存泄漏

    在对内存泄漏有一个基本印象之后,我们再来看一下在特定环境——Unity下的内存泄漏。大家都知道,游戏程序由代码和资源两部分组成,Unity下的内存泄漏也主要分为代码侧的泄漏和资源侧的泄漏,当然,资源侧的泄漏也是因为在代码中对资源的不合理引用引起的。

    代码中的泄漏 – Mono内存泄漏

    熟悉Unity的猿类们应该都知道,Unity是使用基于Mono的C#(当然还有其他脚本语言,不过使用的人似乎很少,在此不做讨论)作为脚本语言,它是基于Garbage Collection(以下简称GC)机制的内存托管语言。那么既然是内存托管了,为什么还会存在内存泄漏呢?因为GC本身并不是万能的,GC能做的是通过一定的算法找到“垃圾”,并且自动将“垃圾”占用的内存回收。那么什么是垃圾呢?
    我们先来看一下wikipedia上对于GC实现的简介:


    定义还是过于冗长,我们来联想一下生活中,我们一般把没有利用价值的东西,称为垃圾,也就是没有用的东西,就是垃圾。在GC的世界中,也是一样的,没有引用的东西,就是“垃圾”。因为没有引用了,就意味着对于其他任何对象而言,都认为目标对象对我已经没有利用价值了,那它就是“垃圾”了。根据GC的机制,其占用的内存就会被回收。
    基于以上的知识,我们很容易就可以想到为什么在托管内存的环境下,还是会出现内存泄漏了。这就像现实生活中的宅男宅女,吃了泡面总是忘记把盒子扔到门外的垃圾箱里;从计算机的角度来说,则是,在某对象超出其作用域时,我们 “忘记”清除对该无用对象的引用了。
    说到这,有的同学可能会有疑问:我每次在代码中申请的内存都非常小,少则几B,多则几十K,现在设备的内存都比较大(几百M还是有的吧),即使泄漏会产生什么大影响么?
    首先,水滴石穿的典故相信大家都知道,实际代码中,并非只有显示调用new才会分配内存,很多隐式的分配是不容易被发现的,例如产生一个List来存储数据,缓存了服务器下发的一份配置,产生一个字符串等等,这些操作都会产生内存的分配。你分配几十K,他分配几十K,一会儿内存就没了。
    其次,有一点需要说明的是,在Unity环境下,Mono堆内存的占用,是只会增加不会减少的。具体来说,可以将Mono堆,理解为一个内存池,每次Mono内存的申请,都会在池内进行分配;释放的时候,也是归还给池,而不会归还给操作系统。如果某次分配,发现池内内存不够了,则会对池进行扩建——向操作系统申请更多的内存扩大池以满足该次的内存分配。需要注意的是,每次对池的扩建,都是一次较大的内存分配,每次扩建,都会将池扩大6-10M左右(此处无官方数据,是观察所得)。


    上图是某游戏经过Cube测试的结果,可以看到Mono堆内存为39M左右,而建议值一般为 50M。
    我们必须知道,Mono内存泄漏是Unity游戏开发中需要特别重视的部分。

    资源中的泄漏 – Native内存泄漏

    资源泄漏,顾名思义,是指将资源加载之后占有了内存,但是在资源不用之后,没有将资源卸载导致内存的无谓占用。
    同样的,在讨论资源内存泄漏的原因之前,我们先来看一下Unity的资源管理与回收方式。为什么要将资源内存和代码内存分开讨论,也是因为其内存管理方式存在不同的原因。

    上文中说的代码分配的内存,是通过Mono虚拟机,分配在Mono堆内存上的,其内存占用量一般较小,主要目的是程序猿在处理程序逻辑时使用;而Unity的资源,是通过Unity的C++层,分配在Native堆内存上的那部分内存。举个简单的例子,通过UnityEngine命名空间中的接口分配的内存,将会通过Unity分配在Native堆;通过System命名空间中的接口分配的内存,将会通过Mono Runtime分配在Mono堆。


    了解了分配与管理方式的区别,我们再来看看回收的方式。如上文所说,Mono内存是通过GC来回收的,而Unity也提供了一种类似的方式来回收内存。不同的是,Unity的内存回收是需要主动触发的。就好比说,我们把垃圾扔在门口的垃圾桶里,GC是每天来看一次,有垃圾就收走;而Unity则需要你打个电话给它,通知它有垃圾要回收,它才会来。主动调用的接口是Resources.UnloadUnusedAssets()。其实GC也提供了同样的接口GC.Collect()
    用来主动触发垃圾回收,这两个接口都需要很大的计算量,我们不建议在游戏运行时时不时主动调用一番,一般来说,为了避免游戏卡顿,建议在加载环节来处理垃圾回收的操作。有一点需要说明的是,Resources.UnloadUnusedAssets()内部本身就会调用GC.Collect()。Unity还提供了另外一个更加暴力的方式——Resources.UnloadAsset()来卸载资源,但是这个接口无论资源是不是“垃圾”,都会直接删除,是一个很危险的接口,建议确定资源不使用的情况下,再调用该接口。

    基于上述基础知识,我们再来看一下为什么会有资源的泄漏。首先和代码侧的泄漏一样,由于“存在该释放却没有释放的错误引用”,导致回收机制认为目标对象不是“垃圾”,以至于不能被回收,这也是最常见的一种情况。

    针对资源,还有一种典型的泄漏情况。由于资源卸载是主动触发的,那么清除对资源引用的时机就显得尤为重要。现在游戏的逻辑趋于复杂化,同时如果有新成员加入项目组,也未必能够清楚地了解所有资源管理的细节,如果“在触发了资源卸载之后,才清除对资源引用”,同样也会出现内存泄漏了。


    赶上了资源回收

    错过了资源回收

    还有一种资源上的泄漏,是因为Unity的一些接口在调用时会产生一份拷贝(例如Renderer.Material参考https://docs.unity3d.com/ScriptReference/Renderer-material.html),如果在使用上不注意的话,运行时会产生较多的资源拷贝,造成内存的无端浪费。但是此类内存拷贝一般量较少,修复起来也比较简单,这里不做大篇幅的介绍。

    修复内存泄漏

    根据上文描述,我们知道只要在回收到来之前,将引用解开就可以避免内存泄漏了,似乎是个很简单的问题。但是由于实际项目的逻辑复杂度往往超出想象,引用关系也不是简单的一层两层(有时候往往会多达十几层,甚至数十层才连接到最终的引用对象),并且可能存在交叉引用、环状引用等复杂情况,单纯从代码review的角度,是很难正确地解开引用的。如何查找导致泄漏的引用,是修复泄漏的难点和重点,也是本文主要想介绍的部分,下面就针对如何查找引用介绍一些思路和方法。至于时序问题,比较简单,在此不做赘述。

    New Memory Profiler For Unity5

    Unity的Memory Profiler一直就是一个被用户诟病的地方,对于内存的使用量,被谁使用等信息,没有很好的反映。Unity5作为最新一代的Unity产品,对于这个弱点进行了一些补强,推出了新一代的内存分析工具,较好地解决了上述问题。但是没有提供两次(或多次)内存快照的比较功能,这点比较遗憾。
    注:内存快照比较是寻找内存泄漏的常用手段,将两次内存的状态截取出来,进行比较,可以清楚地发现内存的变化,寻找内存的增量与泄漏点。一般会在游戏进关前以及出关后做两次dump,其中新增的内存分配,可以视为泄漏。



    由于是Unity官方的工具,网上有比较详细的使用教程,在此不加赘述,可以参考下列链接或Google:
    Unity-Technologies MemoryProfiler
    memoryprofiler intro
    由于Unity5普及度及稳定性还有待提升,公司内普遍还是4.x的环境,那么上述的新工具就不适用了。有的同学说,升级一个5的工程来做Memory Profile嘛,这个当然也可以,不过Unity5对于4的兼容性不太好,升级过程中需要修改不少东西,维护两个工程也是比较麻烦的事。

    那么,下面就给出两个在Unity4环境下也可以使用的泄漏追踪工具。

    Mono内存的放大镜——Cube

    Cube是 腾讯游戏下的腾讯WeTest平台上针对Unity项目的性能指标收集工具,通过Cube可以较方便地获取到游戏的各项性能指标,为性能优化提供了方向。同时Cube也是游戏性能一个很好的衡量工具。



    这里我们利用“MONO内存对象深度分析”的特点。该功能可以允许用户抓取某一时刻的Mono内存状态,并且提供不同时刻内存状态的比较,快速定位到新增的内存分配。

    鉴于Cube官方已经给出了详细的使用说明,就不再赘述数据的抓取过程。这里简单聊一下如何通过Cube抓取的数据更好地追踪和解决问题。

    如下图所示,假设我们已经抓取了两次数据(snapshot1 & snapshot2),并且进行比较,得到两次内存快照之间新增的分配数据。


    比较之后得到如下图所示的一系列数据,总结来说,就是在某个堆栈,分配了某个类型的对象,占用xx内存。这样的数据会有成千上万条(上文所说,代码中的内存分配,是非常细碎,并且数量极多的,在这里得到了验证),并且其中有很多堆栈是重复的,因为每一次的内存分配(即使是同一处位置产生的分配),都会产生一条记录。无序的数据影响了我们对数据的处理,这里我们对数据做一些分析整理。


    我们举一些简单的例子来说明处理的过程。

    每一条记录,都是经过一系列的函数调用(堆栈),最终分配了一些内存,用图形化的方式表示为:


    让我们多加一些数据:


    通过对图的观察,我们发现可以把上述离散的图整理成一棵树:


    将所有数据都做同样的归类处理之后,可以得到一棵或多棵这样的分配树。这么做的好处是:
    1) 根据函数,可以将内存的分配做一个模块的划分,快速定位到相关的模块。
    2) 可以清晰地看到每一层函数的分配总量(如A函数总共分配4096+20+4096B),可以根据占用内存的多少决定修复的优先级。
    将对比之后的新增项一一清理之后,就可以基本清除Mono内存的多余分配和泄漏了。

    顺藤摸瓜——从Mono中寻找资源引用

    在尝试寻找资源引用,修复资源泄露之前,我们需要先了解一下如何在Unity中定位资源泄漏。
    我们需要使用Unity自带的Memory Profiler(注意不是上文说的Unity5的新Profiler,是老的残疾版Profiler)。举个简单的例子,在Unity编辑器环境下运行游戏工程,经过“大厅”页面,进入到“单局”。此时打开Unity Profiler,切换到Memory并做一次内存采样(具体请参考https://docs.unity3d.com/Manual/ProfilerMemory.html,不赘述)。 在采样的结果中(其中包含采样时刻内存中所有的资源),点开Assets->Texture2D,如果其中可以看到有“大厅”UI使用的贴图(如下图),那么我们可以定义这张UI贴图,属于资源上的泄漏。



    为什么说这种情况就属于资源泄漏呢,因为这张UI贴图,是在“大厅”时申请的,但是在“单局”时,它已经不被需要了,可是它还在内存中。这种在不需要的时候,却还存在的内存占用,就是上文我们定义的内存泄漏。

    那么在平时项目中,我们如何找到这些泄漏的资源呢?
    最直观的方法,当然也是最笨的方法,就是在每次游戏状态切换的时候,做一次内存采样,并且将内存中的资源一一点开查看,判断它是否是当前游戏状态真正需要的。这种方法最大的问题,就是耗时耗力,资源数量太多眼睛容易看花看漏。

    这里介绍两种讨巧的方法:
    1) 通过资源名来识别。即在美术资源(如贴图、材质)命名的时候,就将其所属的游戏状态放在文件名中,如某贴图叫做BG.png,在大厅中使用,则修改为OG_BG.png(OG = OutGame)。这样在一坨IG(IG=InGame)资源里面,混入了一个OG,可以很容易地识别出来,也方便利用程序来识别。这么做还有一个好处,可以强化美术对资源生命周期的认识,在制作资源,特别是规划UI图集时,可以有一个指导意义。
    2) 通过Unity提供的接口Resources.FindObjectsOfTypeAll()进行资源的Dump,可以根据需求Dump贴图、材质、模型或其他资源类型,只需要将Type作为参数传入即可。Dump成功之后我们将结果保存成一份文本文件,这样可以用Beyond Compare对多次Dump之后的结果进行比较,找到新增的资源,那么这些资源就是潜在的泄漏对象,需要重点追查。
    结合上述的方法与思路,应该可以轻松找到泄漏的资源了。

    此时我们再回头看一下Unity Profiler,其实Unity提供了资源索引的查找功能,只不过该功能是以一个树形结构的文本来展示的(如下图)。上文曾提到过,Unity内部的引用关系往往是非常复杂的,可能需要通过十几甚至几十层的引用,才能找到最终的引用者,并且引用关系错综复杂,形成一张庞大的图,此时光靠展开树形结构来查找,几乎是不可能的事了。


    防微杜渐,避免内存泄漏

    介绍完对于Unity内存泄漏的追踪方法,我还想往下多讲一步,只要我们在平时开发的过程多做思考,防微杜渐,内存泄漏是完全可以避免的。相对于等泄漏发生了再回头来追查,平时多花点时间清理“垃圾”反而是更加高效的做法。
    落地到平时的开发流程中,在这里提出几点建议,欢迎各位大牛补充:
    1) 在架构上,多添加析构的abstract接口,提醒团队成员,要注意清理自己产生的“垃圾”。
    2) 严格控制static的使用,非必要的地方禁止使用static。
    3) 强化生命周期的概念,无论是代码对象还是资源,都有它存在的生命周期,在生命周期结束后就要被释放。如果可能,需要在功能设计文档中对生命周期加以描述。
    相信大家出门旅游,都有看过下图类似的标语,作为一名合格的程序猿,也应该能够处理好代码中的“垃圾”,不要让我们的游戏成为一个“垃圾场”。

    为了避免以上手游性能方面对游戏的负面影响,腾讯WeTest平台下的Cube工具可以帮助开发者发现游戏内分类资源的一个占用情况,帮助在游戏开发过程中不断改善玩家的体验。目前功能还在免费开放中。点击http://wetest.qq.com/cube/立即体验!

    展开全文
  • 内存的工作原理和时序介绍

    千次阅读 2017-08-05 12:37:13
    内存的工作原理及时序介绍 内存是PC配件中结构最简单的,但在BIOS中却是最难调的,很多玩家超频都卡在内存上。并且,内存的原理、结构与时序多年不会改变,无论将来内存技术如何进步,相信这篇文章的存在...
  • 文本分类(二) | (1) 项目介绍

    千次阅读 2020-01-28 11:54:48
    文本分类(二)专栏主要是对Github优秀文本分类项目的解析,该文本分类项目,主要基于深度学习模型,包括TextCNN、TextRNN、FastText、TextRCNN、BiLSTM_Attention、DPCNN、Transformer,使用PyTorch实现。 目录 1. ...
  • 内存的工作原理及时序介绍

    千次阅读 2013-02-06 14:52:03
    内存的工作原理及时序介绍 内存是PC配件中结构最简单的,但在BIOS中却是最难调的,很多玩家超频都卡在内存上。并且,内存的原理、结构与时序多年不会改变,无论将来内存技术如何进步,相信这篇文章的存在...
  • 内存(DRAM)的工作原理及时序介绍

    万次阅读 多人点赞 2015-09-20 23:05:29
    最近在学习高速电路的存储器设计,找到这篇对于存储器的DRAM介绍的比较通俗易懂的好文。
  • FLASH 闪存的分类介绍

    千次阅读 2017-08-10 19:40:41
    而所谓的内存是挥发性存储器,分为DRAM和SRAM两大类,其中常说的内存主要指DRAM,也就是我们熟悉的DDR、DDR2、SDR、EDO等等。闪存也有不同类型,其中主要分为NOR型和NAND型两大类。  闪存有很多类型,但目前最为...
  • 这篇文章将介绍Windows PE病毒, 包括PE病毒原理、分类及感染方式详解,并通过案例进行介绍。这些基础性知识不仅和系统安全相关,同样与我们身边的APP、常用软件操作系统紧密联系,希望这些知识对您有所帮助,更...
  • 这是作者网络安全自学教程系列,主要是关于安全工具和实践操作的在线笔记,特分享出来与...这篇文章将介绍Windows PE病毒, 包括PE病毒原理、分类及感染方式详解,并通过案例进行介绍。基础性文章,希望对您有所帮助~
  • BERT简介中文分类

    万次阅读 多人点赞 2018-12-21 16:58:42
    文章目录BERT是什么BERT调优句子(对)分类任务分类器预测中文分类实践下载中文预训练模型修改run_classifier.py训练预测 介绍来自bert的github资料翻译,水平有限 BERT是什么 BERT是一种预训练语言表示的方法,这...
  • Linux内存子系统基础常用调优参数

    千次阅读 2015-11-02 21:20:09
    包括存储器管理中内存分配策略,基于分页/分段存储管理方式,请求分页/分段存储管理方式,页面置换算法,系统调用,中断机制,进程切换等,本文整合梳理了网络资料书本知识,对上述问题进行简单介绍 程序的局部性...
  • 内存管理

    万次阅读 2015-03-12 17:09:40
    内存管理是C++最令人切齿痛恨的问题,也是C++最有争议的问题,C++高手从中获得了更好的性能,更大的自由,C++菜鸟的收获则是一遍一遍的检查代码和对C++的痛恨,但内存管理在C++中无处不在,内存泄漏几乎在每个C++...
  • ppt文件 主要介绍内存条电路组成原理,内存常见故障分析与维修;显卡的分类、原理、电路组成、显卡常见故障分析与维修。可以掌握内存与显卡的原理以及常见故障维修方法,用于老师让演示文件
  • 使用BERT进行情感分类预测代码实例

    万次阅读 多人点赞 2019-05-17 01:46:31
    因为这次是分类问题, 所以我们需要修改run_classify.py 2.1 加入新的任务类 因为我们是做一个分类的任务, 但是 2.2 任务类注册 3. 运行代码 运行代码需要提供参数, 这里我建议直接在pycharm编译器里加...
  • Android性能优化系列之内存优化

    万次阅读 2017-01-21 21:00:45
    内存的释放是由垃圾收集器(Garbage Collection,GC)完成的,程序员不需要通过调用函数来释放内存,但也随之带来了内存泄漏的可能,上篇博客,我介绍了 Android性能优化系列之布局优化,本篇博客,我将介绍内存优化...
  • 内存泄漏与内存溢出总结

    千次阅读 2017-04-08 12:14:00
    导读:本篇文章是最近几天关于内存优化的个人学习总结,从基础到日常常见的内存泄漏的顺序慢慢介绍…本编全文本,可能有些单调,不过认真看下来,肯定收益良多!如果急着解决,直接看 “常见的内存溢出处理”,”常见的内存...
  • 内存知识大全

    千次阅读 2018-06-08 22:48:22
    thx-bj 专注于.Net技术 【转帖】内存知识大全 内存是主板上重要的部件之一,它是存储CPU与外围设备沟通的数据与 程序的部件。在主机中,内存所存储的数据...现将内存重要的分类介绍如下: 内存的品牌 内存有许...
  • 数据结构:八大数据结构分类

    万次阅读 多人点赞 2018-09-05 18:23:28
    数据结构分类 数据结构是指相互之间存在着一种或多种关系的数据元素的集合和该集合中数据元素之间的关系组成 。 常用的数据结构有:数组,栈,链表,队列,树,图,堆,散列表等,如图所示: 每一种数据结构都...
  • 计算机存储器介绍

    万次阅读 多人点赞 2018-04-24 10:17:29
    (一)存储器 存储器(Memory)是现代信息...在系统中,具有实物形式的存储设备也叫存储器,如内存条、TF卡等。计算机中全部信息,包括输入的原始数据、计算机程序、中间运行结果和最终运行结果都保存在存储器中。...
  • [转]libsvm介绍及使用

    千次阅读 2015-03-10 21:16:13
    所谓最优分类,就是要求分类线不但能够将两类无错误的分开,而且两类之间的分类间隔最大,前者是保证经验风险最小(为0),而通过后面的讨论我们看到,使分类间隔最大实际上就是使得推广性中的置信范围最小。...
  • c++内存机制

    千次阅读 2017-09-13 21:23:22
    内存管理是C++最令人切齿痛恨的问题,也是C++最有争议的问题,C++高手从中获得了更好的性能,更大的自由,C++菜鸟的收获则是一遍一遍的检查代码和对C++的痛恨,但内存管理在C++中无处不在,内存泄漏几乎在每个C++...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 75,692
精华内容 30,276
关键字:

内存条分类及介绍