CN103558992A - 堆外直接内存数据存储器,创建和/或管理堆外直接内存数据存储器的方法,和/或包括堆外直接内存数据存储器的系统 - Google Patents
堆外直接内存数据存储器,创建和/或管理堆外直接内存数据存储器的方法,和/或包括堆外直接内存数据存储器的系统 Download PDFInfo
- Publication number
- CN103558992A CN103558992A CN201210046529.8A CN201210046529A CN103558992A CN 103558992 A CN103558992 A CN 103558992A CN 201210046529 A CN201210046529 A CN 201210046529A CN 103558992 A CN103558992 A CN 103558992A
- Authority
- CN
- China
- Prior art keywords
- data
- pile
- memory
- page
- computer
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/0604—Improving or facilitating administration, e.g. storage management
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0253—Garbage collection, i.e. reclamation of unreferenced memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0629—Configuration or reconfiguration of storage systems
- G06F3/0631—Configuration or reconfiguration of storage systems by allocating resources to storage systems
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0673—Single storage device
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/44—Arrangements for executing specific programs
- G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
- G06F9/45504—Abstract machines for programme code execution, e.g. Java virtual machine [JVM], interpreters, emulators
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2212/00—Indexing scheme relating to accessing, addressing or allocation within memory systems or architectures
- G06F2212/70—Details relating to dynamic memory management
- G06F2212/702—Conservative garbage collection
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Software Systems (AREA)
- Human Computer Interaction (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Abstract
特定示例实施方式涉及高并发的,可预测的、快速的、自我管理的、进程内的用于存储数据的进程内的空间,其被隐藏于无用单元收集器和它的相关中断。更特别地,示例实施方式涉及用于计算机系统的影响大规模可扩展的和高效率的堆外直接内存数据存储器的改进的内存管理技术。提供与基于Java环境相关的堆外存储器,且完全地或几乎完全地避免了堆外存储器的无用单元收集。根据特定的示例实施方式的方案,所述存储器可能被并入层叠的存储器。
Description
相关文件的交叉引用
本申请要求以2011年2月24号提交的申请号为61/446,442的美国申请为优先权基础,在此以引用的方式整体并入本文中。
技术领域
此处描述的特定的示例实施方式涉及用于计算机系统的改进的内存管理技术。更特别地,此处描述的特定的示例实施方式涉及用于计算机系统的影响(leverage)大规模可扩展的和高效率的堆外(off-heap)直接内存数据存储器的改进的内存管理技术。在特定的示例实施方式中,提供与基于Java环境相关的堆外(off-heap)存储器,且完全地或几乎完全地避免了堆外(off-heap)存储器的无用单元收集。
背景技术
数据需求被估计正在以60%的年率增长并且该趋势通过云计算平台,公司合并,巨大应用平台(如脸谱网Facebook)等被进一步推动。今年够买的服务类机器具有最小8千兆兆字节(GB)的RAM且很可能有32GB的RAM。举一个例子来说,思科正在售卖具有超过380GB的RAM的主流统一计算系统(UCS)盒。举另一个例子,用户可以在EC2上以$2/小时租借68.4GB的机器。
以通常的方法,许多操作系统尝试通过在本地机器上缓存数据使操作加速,例如,与机器的堆有关。“移动”数据更接近在其上执行的应用可以引起效率增加。这种传统的思维时常得出高速缓存存储器cache应当尽可能大的结论。然而,在无用单元收集运行时间执行的应用面临正在增加的在现代电脑系统上处理数量日益增长的数据和平衡数量快速增长的RAM的挑战。众所周知,无用单元收集是比如,通过Java执行的自动内存管理的一部分。无用单元收集包括确定哪些对象不能再被应用引用,且然后回收“死的”对象(垃圾)使用的内存。但是在确定什么时候,多久,和多久一次,发生无用单元收集活动出现复杂性,并且这个工作直接影响运行的应用的性能和决定性。
此外,为无用单元收集运行时间增加高速缓存存储器cache的大小的不好的副作用是大 的高速缓存存储器cache需要大的堆,基于Java的环境以负指数速率大幅降低速度,如果不是全部,其降低速度可直接归因于Java的无用单元收集。2-4千兆位(GB)的堆大小通常是可管理的,并且如果进行了专门的修改,可以认为一些进一步的数字是可用的。但是通常的修改可能耗时并且在技术上具有挑战。因此通常对Java堆有实际的(且通常建议)6GB的限制,虽然在达到这个最大值之前,逐渐较好地出现减速。减速能使一切停止或者实质上使所有正在执行的程序停止。对于大的堆,观察到什么都没发生的10秒延迟不是罕见的,虽然长达分钟的延迟不是没听说过。这些种类的延迟可能对于网络服务、关密钥任务应用和/或类似的相当成问题。
挑战起因于以运行时间堆变得越来越大的形式出现的增加无用单元收集中断或延迟。这些延迟在长度和发生上可能不可预测。这样,当数据/内存爆炸正在发生,无用单元收集的堆的数量运行时间过程可以有效地使用已经保持基本不变。换句话说,虽然可用的空间的数量正在增长,但以有效的和成本效率的方式使用它通常是具有挑战的。
这些问题以多种方式出现,且可能以多种常见的情况引起。第一个问题涉及应用运行太慢。比如,应用可能不能跟上用户(比如,在数据库中具有数据的GB的10s,应用服务用户的需要可能超载和/太慢),其可能由查询的复杂性质、这些查询的大小,和/或类似的引起。缓冲可能有助于移动数据“更接近”应用,但如果高速缓冲存储器增长太大(例如,在假想系统中接近于16GB的RAM),可能引起太多Java无用单元收集中断。
另一个常见的问题涉及可能影响应用的不可预测的延迟。应用可能通常足够快,但许多偏离均值的中断可能对于我的用户是不可接受的。由于我的堆的大小,结合Java无用单元收集中断可能不满足服务等级协议(SLA)。
还有另一个常见的问题涉及复杂的软件/硬件部署。它可能例如,通过用许多具有1-2千兆的堆大小的Java虚拟机(JVM)运行来“解决”Java无用单元收集问题。可以划分数据和/或可以执行负载平衡以达到要求的性能和可用性。然而,管理设置可能是复杂的因为需要这么多的JVM,且必须执行检查以确保正确的数据在正确的位置。这样,虽然可能满足64GB的RAM,但是可能太难管理并且太脆弱以至于不能可靠地执行。
当前,当处理Java应用时,用户被迫选择三个选择中的一个。基本例子包括在大机器上的小的堆JVM。意识到无用单元收集中断是个问题,通过例如,在32GB的机器上执行4GBJVM减少无用单元收集。形成和操作复杂性较低,但性能可能变差。第二个选择包括在32GB机器中执行比如,高达31GB的大堆。虽然目的是移动数据更接近于应用,但无用单元收集延迟可能非常高且管理非常复杂。形成和操作复杂性也可能非常高。
第三个选择包括堆叠小的JVM堆。比如,可以执行8个4GB JVM。这个方法通常与多个 分区、负载平衡和分类归并技术结合使用。然而,可惜的是,管理这种环境是非常复杂的。如果所有的或大多数节点垃圾在同一时间收集,也可能遇到可用性问题。
这样,将注意到在本领域中需要减轻面临的无用单元收集运行时间的问题。也将注意到在本领域中需要能够在计算机系统中以使用增长数量的存储器(RAM或磁盘)的方式处理增加数量的数据的系统。
上述这些示例问题出现在第一个Java释放并且从那时起没有完全被寻址。这样,将注意到在本领域中已经有解决这些和/或其它相关问题的长期的(long-felt)需要。
相信部分长期(long-felt)需要的理由是为解决这些和相关的问题,先前尝试的解决方法已经试图依靠操作系统(OS)途径,或编程语言(PL)途径。但是,本申请的发明人已经意识到需要的是混合两个技术领域的元素的更全面的途径。这样,比如以下更加详细的描述,在此描述的示例实施方式属于既不是OS相关的也不是PL相关的技术领域但可以看作高于OS和PL(或管理的运行时间)层的某物。
更特别地,将注意到提供不影响无用单元收集在存储器中能够保存大的数据集(例如,从GB的10s至100s)的独一无二的缓存方案是可取的。缓存的数据越多,应用必须转到(goto)外部数据源或磁盘越少且,从而,应用将运行的更快。以同样的方式,提供符合SLA的快速执行,且也随时间保持快速将是可行的。这可能通过当数据随时间改变时,减少存储残片的数量和避免或至少减少减速完成。提供并发的途径,比如,它测量CPU数量和功率,和进程,话题的数量,然而也避免或减少锁竞争。这个方案较优地将是可预测的。提供设计为与编程语言和/或操作系统环境一起工作(例如,提供100%Java方案在JVM内工作)的途径也将是较优的。这可能帮助不引入大量复杂性的嵌入式管理单元(snap-in)功能。提供可重新开始的解决方案也是可取的,因为反而可能花很长时间构建大的缓冲。
大多数人不正确地认为收集死的对象花费时间,但活的对象的数目实质上对无用单元收集性能具有最大的作用。当Java堆被数目增加的活的对象占据时,充分收集(fullcollection)更经常地发生且每一个将需要更多时间完成。结果是对于增加的时间长度,在应用中全部停止(stop-world)中断的数目增加。总的来说,堆越大,且其越被占用,应用中的延迟越大。特定的示例实施方式帮助避免大的数据高速缓存的大的,占用的堆,同时也降低无用单元收集相关的中断。
发明内容
特定的示例实施方式的一方面涉及高并发的,可预测的、快速的、自我管理的、进程内 的用于存储数据的空间,其被隐藏于(hidden away from)无用单元收集器和它的相关中断。在特定的示例中,空间可能是自调节的(self-tuning),并且可能以要求对用户的应用代码没有或者实质上没有改变的方式与框架连接。就这一点而言,在特定的示例实施方式中,空间可能“位于”标准的界面比如,Map、HttpSessions、Ehcache和/或类似的“之后(sitbehind)”。
特定的示例实施方式的另一个方面涉及增加纵向扩展(scale-up)特征(例如,通过增长单个的机器提高性能的能力)和比如,在为应用提供高可用性横向扩展(scale-out)(例如,促使多个相连的机器针对一个问题的能力)的分类归并技术的情况下对服务器和应用的可预测性的技术。
特定的示例实施方式的优点涉及不用必须改变用户代码集成这些功能的能力,和相反通过增加分配行和,可能地,提供的用于访问堆外(off-heap)存储器的代码模块。转而,这可能为无用单元收集运行时间层压layer in在可预测的、快速的、高并发的堆外(off-heap)存储器内,不用大量的所需的调节。根据特定的示例实施方式,通过加进堆外数据存储器,所述运行时间的无用单元收集器可以集中于操作所需的小的堆上(其是运行时间非常好的事物),然而可能使其余的数据结构通过堆外存储器有效地和完全地(或实质上完全地)管理。
特定的示例实施方式的另外一方面涉及收缩堆的大小和增大高速缓存器的能力。
特定的示例实施方式还有的另外一方面涉及提供磁盘快速交换和快速再启动性的可能性。
在Java中,堆外内存通过操作系统(OS)经由java.nio.buffer.ByteBuffer级(class)提供。创建和毁坏“直接”比特缓存器通常将OS内存分段并且使堆外内存分配变慢并且对帮助避免这种情况不可预测,当特定的示例实施方式第一次开始执行时(例如,在创建时),创建的直接BB占用了整个堆外内存空间。然后特定的示例实施方式使用它们自己的内存管理器管理比特缓存器(ByteBuffer)。因为所述比特缓存器(ByteBuffer)从未被毁坏过(至少直到Java用它们完全完毕),所述OS内存管理器从未被调用(invoked)。结果,堆外内存分别更快并且更可预测。
特定的示例实施方式包括能够快速并可预测的分配的内存管理器。比如,在可变大小的组块中执行分配。所需数量的内存被请求来自尽可能大的组块中的OS,并且组块大小的界限是指定构建的。从而分配以上限进行开始。分配失败,降低界限大小,并且分配以新的更低的值继续,可能直到达到或超过更低的阈值。
所述特定的示例实施方式的内存管理器可能从直接ByteBuffer以将内存分配为页,每一页来自单一ByteBuffer。如果合适的空间不可用,则使用中的页可能被“偷取”并且用于请 求的分配。每一个页分配请求可以包括参数,比如,小偷、牺牲者和拥有者。所述小偷参数可以指示使用中的页是否应该被偷取(如果需要)以符合分配要求。牺牲者(victim)参数可以指示该页(被分配后的)是否应该被被偷取(如果需要)以符合分配要求。拥有者(owner)参数可以指示该页的拥有者以便如果页后来被偷取可以通告所述拥有者。所述小偷和牺牲者(victim)参数可以是指示不同实施方式中的相对优先顺序的布尔值(真/假、是/否等)或者数字值。
在特定的示例实施方式中,计算机系统包括至少一个提供的处理器,一个有形(tangibly)存储数据的非瞬变计算机可读存储介质。软件应用可通过至少一个处理器执行并且被程序化以使用数据。堆外内存被动态地部署并且被内存管理器直接管理,以使堆外内存可被软件应用感知成为本地应用层内存的一部分并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和运行计算机系统的操作系统的任何内存管理器。所述堆外内存可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外内存中的数据显然地可以微秒提供给来自堆外内存的软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。
在特定的示例实施方式中,提供一种管理计算机系统的内存的方法,该计算机系统包括至少一个处理器,一个有形(tangibly)存储数据的非瞬变计算机可读存储介质,和通过至少一个处理器可执行的并且被程序化以使用数据的软件应用。堆外内存被动态地部署并且使用内存管理器直接管理,以使堆外内存数据存储区域可被软件应用感知成为本地应用层内存的一部分并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和运行计算机系统的操作系统的任何内存管理器。所述堆外直接内存数据存储区域可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外直接内存数据存储区域中的数据显然地可以微秒提供给来自堆外内存的软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。
这个方法可以与基于Java的环境相关操作,并且可以进一步包括:(a)试图分配在预分配的最大大小的组块中的Java比特缓存块响应以预设的最大大小的堆外直接内存数据存储器;(b)重复所述分配比特缓存块的尝试直到堆外直接内存数据存储区域以预定的大小被创建,或者直到尝试失败,不论哪个先出现;(c)当分配比特缓存块的尝试失败,降低预分配的最大大小并且重复(a)-(b);(d)接收堆外直接内存数据存储区域的范围请求,该范围具有相关的大小;(e)通过页源(page source),寻找堆外直接内存数据存储区域的不用的组片。(f)返回表明不用的组片的页,该页成为封包(wrapped)比特缓存块,其包含对存储数据的组片的访问和对创建组片的分配器对象的访问。(g)继续返回页直到堆外直接内存数据存储区域被 耗尽。(h)管理从堆外直接内存数据存储区域返回的页作为单一的相干的(coherent)存储数据密钥(key)和值的逻辑地址空间,在存储具有连接数据密钥和值的元数据信息的散列表的堆外直接内存数据存储区域内具有单一的页。并且可选择地(i)通过再散列进入一个新的页,分别响应入口进一步被加入和被移出而扩展和收缩所述散列表。
在特定的示例实施方式中,提供一种计算机系统。提供多个计算机节点,和可以穿过Java虚拟机(JVM)环境中的多个计算机节点执行的应用。每个计算机节点包含至少一个处理器;内存管理软件;和一个动态分配的并且由相关的计算机节点的内存管理软件直接管理的堆外直接内存数据存储区域,所述堆外直接内存数据存储区域可根据从相关计算机节点的内存管理软件到调节的兆兆位字节值的数据的方向扩展以便从那儿可提供存储在堆外直接内存数据存储区域的所述数据,而不用必须重复地访问来自非瞬态计算机可读存储介质或网络存储单元的所述数据。
在特定的示例实施方式中,提供一种系统。应用可在至少一个计算机上执行。也提供独立可扩展的调节的内存管理器的服务器阵列和相关的数据存储节点。每一所述的数据存储节点包括通过应用可用的有形存储数据的非瞬变计算机可读存储介质。每一所述内存管理器包括:至少一个处理器,动态分配并且由内存管理器直接管理的堆外内存。所述堆外内存可根据从内存管理器到调节的兆兆位字节值的数据的方向扩展以便从堆外内存可提供存储在堆外内存的所述数据,而不用必须重复地访问来自节点非瞬态计算机可读存储介质的所述数据。当请求的数据没有出现在至少一个计算机上的高速缓存器内,请求未被应用认识到时,所述至少一个计算机包括分配为自动开始来自服务器阵列的数据请求的编程逻辑。
所述至少一个计算机可以包括多个计算机和可能通过多个计算机可执行的应用。
根据特定的示例实施方式,每一所述计算机可以具有它自身的用于创建和管理其上的堆外直接内存存储区域的内存管理器。比如,根据特定的示例实施方式,每一计算机可以包括至少一个处理器;内存;计算机特有的内存管理软件;和自动分配并由相关计算机的计算机特有的内存管理软件直接管理的计算机特有的堆外直接内存数据存储区域,所述计算机特有的堆外直接内存数据存储区域可根据从计算机特有的内存管理软件到调节数据的数值高达相关计算机的内存的大小的方向扩展。
也需注意特定的示例实施方式涉及操作多种系统、内存管理器/内存管理软件组件等的方法。
这些特征、方面、优点和示例实施方式可能分别以多种组合被使用和/或被应用以完成本发明的进一步实施方式。
附图说明
通过参考以下示范说明的实施例结合附图的详细描述可以更好地且更完全地理解这些或其他附图和改进,其为:
图1是根据一个示例实施方式的连续的ByteSource分配的简化视图;
图2显示在特定的示例实施方式中,可以怎样将页,包括缓存组片提供给OffHeapStorageArea逻辑存储空间。
图3是特定的示例实施方式,说明用于从OffHeapStorageArea偷取页的示例程序的流程图。
图4是显示一个适用于在特定的示例实施方式中的服务器阵列的示例方框图。
图5是显示特定的示例实施方式的多层次高速缓存途径的示例流程图。
图6是执行特定示例实施方式的堆外直接内存高速缓存器的分层存储方法的例子。
图7是对照用于有和没有执行特定的示例实施方式的堆外内存管理途径的测试方案的最大的全面无用单元收集持续活动的图表。
图8是对照用于有和没有执行特定的示例实施方式的堆外内存管理途径的测试方案的最大的延迟的图表。
图9-10是分别显示当执行特定的示例实施方式时,相对于增加的数据大小平均延迟和通过量的图表。
图11是根据特定的示例实施方式,分布式高速缓存器系统的逻辑图
图12显示根据特定的示例实施方式,用于分布式高速缓存器系统的网络拓补结构的视图。
图13显示根据特定的示例实施方式,分配高速缓存器系统的层叠的分集存储器体系视图。
图14是显示根据特定的实例实施方式,包括在两个应用层上的堆外直接内存管理并且为了服务器阵列的示例架构的另一个方框图。
具体实施方式
特定的示例实施方式的一方面涉及高并发的,可预测的、快速的、自我管理的、进程内的用于存储数据的空间,其被隐藏于(hidden away from)无用单元收集器和它的相关中断,例如,在基于Java的环境中。在特定的示例中,空间可能是自调节的(self-tuning),并且可能以要求对用户的应用代码没有或者实质上没有改变的方式与框架连接。就这一点而言,在特定的示例实施方式中,空间可能“位于”标准的界面比如,Map、HttpSessions、Ehcache 和/或类似的“之后(sit behind)”。
当特定的示例实施方式的堆外(off-heap)直接内存数据存储技术与Java,ByteBuffer和BufferSource相关被实施,可能以它们没有被设计的非传统的和不可预料的方式使用它们。也就是说,在特定的示例实施方式中,Java ByteBuffer可能用于以比另外的将预料到的较少的短暂态(less transient)的方式在堆外(off-heap)存储中留存数据。将ByteBuffer当作它们是内存且然后,进一步,同样地管理它们,相信是特定示例实施方式的新的特征。
本申请的发明人已经意识到在高速缓冲存储器中存储的元素具有可串行化的简单的生命周期。通过人工地移动缓存的堆外的数据并管理高速缓冲存储器,可能避免与无用单元收集相关的问题。虽然一些问题通过采用这个途径解决,但是,造成其它问题。
第一个问题涉及Java没有被设计为与堆外(off-heap)内存(有时也指直接内存)一起工作(work with)。因此,将需要的是尽可能少的与操作系统(OS)内存管理模块相互作用试图尝试用Java被设计和被执行的方式克服这个问题。在特定的示例实施方式中,在前面分配了尽可能多的内存,其被所需的高速缓存器的大小或系统的限制限定在上端。堆外(off-heap)或直接内存可以为非常大的高速缓存器提供非常快和一致的响应时间。
然而,第二个问题产生在尝试决定怎样做出这些分配。通常地,可取的是分配尽可能大的内存的组块。通常地,组块越大,其具有的能够分配的组片越大并且在每个组块内将产生的存储残片越少。在特定的示例实施方式中,做出具有预定的上限(例如,1GB)的对组块的初始请求。组块以这种方式被分配直到它们不能再被分配。一旦发生故障情况(例如,一旦对最大值请求的请求被拒绝),比如,其可能发生在第一次请求,请求的大小可能以某种预定的方式被缩减。比如,在特定的示例实施方式中,请求的大小可能被减半直到可以重新做出分配。在特定的示例实施方式中,可能可取的是对组块大小设定较低的限值,因为用小组块组页(page with)不值得。
在特定的示例实施方式中,计算分配花了多长时间可能是可取的。如果一个分配或如果多个分配(例如,平均,总共,基于一些数量的超过阈值的单个分配等)花费时间长,可能停止分配过程。冗长的分配时间能够标志正提交的(over-committing)源的类型,可能最终使计算机或计算机系统失效(bring down)。比如,Linux内核可能出乎意料地降低(takedown)大程序以引起(account to)尝试扩展分配程序。然而,将被降低(take down)的最可能的选择中的一个似乎是正试图平衡堆外存储器的应用,因为它可能表现为正在运行的资源最密集的(resource-intensive)应用。
第三个问题涉及平衡怎样使事务在堆外存储器内内部运作。在特定的示例实施方式中,每一页可能来源于单一比特缓冲器,具有可能被相应的Java比特缓冲器(Java ByteBuffer) 约束的页大小。从而可能执行页偷取(stealing)。任何时间页被分配,特定的参数包括不论请求人是窃贼、受害人、还是拥有者(owner)都可能被通过。如上所述,这些参数可能较优地帮助建立关于谁能偷,偷什么,什么时间偷的优先顺序。在特定的示例实施方式中,可能执行多个高速缓存器,并且页偷取也使得可能平衡怎样使用多个高速缓存器。理论上,窃贼可能从它自己的高速缓存器上或其它的高速缓存器上偷取。这提供内存管理的灵活的方法。
现在将提供可以怎样分配特定的示例实施方式去操作的更详细的描述。如上所述,在特定的示例实施方式中,比特缓存器(ByteBuffer)可以作为例子代表存储器。比如,在Java应用的情况下,java.nio.buffer.ByteBuffer可以作为例子代表在其最低层(level)的存储器。在代码内,比特缓存器(ByteBuffer)可能由比特源(ByteSource)产生。
在特定的示例实施方式内可以使用两种类型的缓存器源(BufferSource),即堆外缓存器源(OffHeapBufferSource)类型和堆内缓存器源(HeapBufferSource)类型。所述堆外缓存器源(OffHeapBufferSource)类型可以提供到其存储器位于Java堆外的比特缓存器(ByteBuffer)的访问。在Java内,这些指“直接比特缓存器(ByteBuffer)”。这种类型的比特缓存器(ByteBuffer)是在生产中几乎专有地使用的种类(例如,在非测试环境中)。所述堆内缓存器源(HeapBufferSource)类型可以提供到其存储器位于Java堆内的比特缓存器(ByteBuffer)的访问。通过这些源创建的比特缓存器(ByteBuffer)的实例依靠通常的堆内Java比特阵列实例。这种类型的源通常只用于检测方案。
由于缓存器源(BufferSource)本身是界面,当发出创建比特缓存器(ByteBuffer)的请求时可能使用执行更复杂的操作的更复杂的实现。比如,在特定的示例实施方式中,当堆外分配失败时,可能允许从堆外堆到堆上缓存器的退却。
因为许多原因,从Java执行环境中直接分配比特缓存器(ByteBuffer)通常是一项花费高的操作。例如,分配典型地需要对基础操作系统的调用。因为基础操作系统不是一个无用单元收集环境,通常地情况是在分配时期间完成更多工作以减少内存碎片。此外,直接缓冲区分配通常在虚拟机(VM)的宽层面内同步,并且,因此它不是并行的。另外,它有时需要迫使的无用单元收集调用(例如,SUN公司的虚拟机甚至具有对多样参考处理线程的100毫秒睡眠-生产线程(sleep-to-yield)。更进一步的,为了安全的原因,分配执行实施的分配内存的归零。这样,本领域普通技术人员通常不会看到在ByteBuffer直接分配中的许多明显的优势,或者也许认为这样做的相信成本远高于可能的好处。
为了降低在可能关密钥的时刻导致的费用,在特定的示例实施方式中,存储需求没有直接通过比特源(BufferSource)满足。相反,存储分配通过PageSource处理,并且存储器自身返回为页面实例Page instances。页是ByteBuffer实例的组片(分段)周围的封包器, 其也获悉被拥有者约束的页的概念。
PageSource实现可能通过使用UpFrontAllocatingPageSource类型来完成。在特定的示例实施方式中,这可能对预先的ByteBuffer分配,能复原的存储残片(fragmentation-resilient)页面分配,和/或牺牲者/小偷偷取性能起重要作用(feature)。
正如它的名称所提出的,UpfrontaAllocatingPageSource可以在创建时(atconstruction time)执行全部或实质上全部的BufferSource分配(calls)。这可以帮助确保所有花费大的ByteBuffer分配是完整的,这时候任何常规的分配操作都在页源上执行。因为ByteButter分配发生在创建时,可能在创建时提供将请求的堆外内存的总数。这种分配方法帮助确保从操作系统(OS)保留了所有要求的存储器,并且,因此,随后的分配失败变得较少可能。通过这些页源分配的页可能从较大的ByteBuffer组块的池(pool)被分配。这些组块的分配可以以多种方式中的一种进行,例如,通过在固定大小的组块中的分配或者在可变大小的组块中的分配。
在以固定大小组块模式的分配中,从固定大小组块中的操作系统(OS)请求所需内存的数量(加上可能不同大小的后面的组块)。可能在创建时提供所述组块大小,并且分配足够的这种大小的组块的失败可能导致创建页源本身的失败。
在可变大小组块模式的分配中,从尽可能大的组块中的操作系统(OS)请求所需内存的数量。组块大小的界限可能在创建时是指定的。然后分配在上限进行开始。在分配失败时减小该界限大小,并且以新的更低的值继续。应该在足够内存已经被分配之前,将分配大小降低到组块大小的下限以下,然后页源的创建将会失败。降低的数量可能是一个预定的常数或者其他数量。例如,在特定的示例实施方式中,要求的组块大小可能根据每次失败被削减一半,直到分配完成或直到通过可选择的下限,不论哪个先出现。
在特定的示例实施方式中,每次分配的持续时间可能在两个不同分配过程中被监控。分配时间(例如,每单位内存)应该降低到一个初始的阈值,可能发布警告以指示较慢的分配情况。这类减速有时可以由大量操作系统OS页的错误活动指示。如果分配时间低于一秒,更极度的(severe)阈值,然后Java程序可能被终止以避免引起主机中的不稳定。
在UpfrontAllocatingPageSource分配内,信息存储在一套扩展的AA树中。正如所知,AA树是平衡树的一种形式,用来存储和有效地检索有序数据。AA树操作可执行许多数据循环以实现这个平衡,但是相对简单的平衡算法倾向于具有快速执行时间。AA树趋向于相对平缓可达到更快的检索时间。当然,其他的数据结构也许能用于不同的实施例中,同时这些数据结构可以作为树或其他结构。在特定的示例实施方式中,每个ByteBuffer组块都有一个单一树,并且树都扩展到作为在相关的组块内存储空闲区域集的区域集。在特定的示例实施方 式中,来自每个组块内的页面分配都被能力2大小约束,而且被分配在与它们自身大小一致的一个粒度(例如,一个8字节页面只能被分配在一个8的倍数的地址)。当然,其他次方可以用于页面分配,和/或其他位或字节大小可以用来寻找相应的所在地址。
此示例“定义的能量”(例如能量2)方法具有一定的优势。例如,以这个方式强制分配,可能降低另一个示例,通过限制区域成为能量2并且通过地址对树(或其他数据结构)排序,可能在单一的位屏蔽中存储在每一子树中发现的空闲区域的集。可以通过对这些位屏蔽值执行一个简单的检索找到最低有效区域,逐步发现包含一个足够大小的空闲区域的最左侧(最低地址)的子决策树。
图1是根据一个示例实施方式的连续的ByteSource分配的简化视图。三个ByteSource分配都存在于图1的示例中,第一,第二,第三组块被分配。从图1的图表将注意到,这些组块的大小不同,表明对第一个大小的第一个请求是成功的,但要求的大小被减少第一数量(通过一个或多个对减小大小的组块的请求)来获得第二块,和进一步第二数量(再次通过一个或多个对减小大小的组块的请求)获得的第三块。第一个组块表现为具有多个可以用来存储数据的空闲组片。然而,使用上述的Page Source的方法分配两个示例的缓存器组片。页封包这些组片,使得他们可以存取。
UpfrontAllocatingPageSource可能还提供了一个页面偷取的机会。页面的源代码上的分配请求可能有与之相关的附加性能。第一个性能可能是一个布尔数据类型,识别给定的页面是否可以偷取。为了让页面被偷取,拥有者可能被限制以便可以给拥有者作出回叫信号以确保页面的安全恢复。
第二个性能可能是一个小偷指数(index)。传入分配可以有权先偷取分配的牺牲者,如果牺牲者的小偷指数比他们自身低。如果没有足够的可用空间以完成分配。然后合格的牺牲者(victim)可能会被用来满足分配。这个概念允许一个页面源代码的不同用户按重要性排列,以便牺牲不太重要的数据以存储更重要的数据。
根据特定的示例实施方式,所述OffHeapHashMap是以其他的离堆映射和缓存可能为基础的映射实现。在某些实现中,OffHeapHashMap可能是一个开放访问散列表实现,其表存储在依靠单一页面的IntBuffer内。在这样的示例实现中在哈希表内的重新标记,可能与slot step呈线性关系,如具有为4int(128位)的每个入口结构。以下结构可能与特定的示例实施方式相关使用:
这里可用的30位元数据空间可以用于存储附加的有关入口的信息。例如,高速缓存器可能使用一些所述的空间来存储收回的(eviction)相关数据。示例的收回相关的(eviction-related)技术在后面作更详细的阐述。所述OffHeapHashMap实现还可以提供钩(hook)用于执行自定义的操作,添加映射的,查找映射,消除了一个映射,表扩张tableexpansion故障,和/或存储引擎故障storage engine failure。
当入口从映射添加入和移出,映射的表可以扩大和收缩。在表内寻找可用的位置(slot)失败可能导致要么再探查限制的增加(例如,如果表中有一个低负载因素);否则,表可能被扩大(例如,在特定的示例例子中扩大至两倍于它的大小)。如果入口的移除促使表的负载系数低于一个预定的阈值,然后可以做出收缩该表的尝试(例如,收缩至它的大小的一半)。如果这触发了收缩失败,随后的收缩阈值可能会降低(例如,降低一半),以防止反复失败的收缩尝试,可能与入口集合(clumping)有关。
在特定的示例实施方式中,StorageEngine可能负责为映射入可以储存在相关OffHeapHashMap的表的64位量编码{密钥,值}对。所述堆外存储基础架构可以支持专门的StorageEngine实现的使用,以适合特定的密钥和值类型。存储引擎可能被分为两个示例类别。在第一类别中,存储引擎可以编码整个64位编码值内的{密钥,值}对。在第二类中,存储引擎可能存储二级数据结构中的{密钥,值}对,并使用编码以将“指针”存储进二级数据结构。
密钥的类型较小,并且通常能在编码内部适合。例如,经常可能将密钥和指针两者存储为编码空间内部在二级结构内的值,引起上述的组合的混合存储引擎。
在特定的示例实施方式中,标准的(canonical)一般的StorageEngine实现是OffHeapBufferStroageEngine。这个实现可以使用一对可移植性实例以将密钥和值对象变换成比特阵列形式。基本的可移植性实现可以依赖用于该变换的的常规的Java串行化。然而,如果对输入类型的约束更严格,更有效的方案是可能的。一个示例将包括存储字节阵列作为 其本身,或者存储字符串(String)作为基本的字符(char)阵列的字节阵列扩展。一旦{密钥,值}对变换成字节阵列,它们可能会被存储于二级数据结构中,并且到存储位置的所述“指针”可能被返回到存储在映射的表中。
OffHeapStorageArea的实例提供了集合多个统一大小的页的方法,所述页通过PageSource实例返回成为逻辑上连续但物理上离散的存储区域。OffHeapStorageArea实例当需要时通过从他们相关的PageSource分配新的页动态地增长。
这些OffHeapStorageArea实例可能被用作二级数据结构,其中OffHeapBufferStorageEngine存储其最新可便携的密钥和值。他们在堆外中提供单一的可寻址的存储区域,整数(integers)和字节阵列值可以存储到所述堆外中,并且然后被恢复。内部地,所述存储区域使用标准的分配内存(malloc)和自由(free)算法的改进的Java端口(虽然其他算法可以使用在不同的示例实施方式中)。可以将头和尾两者的边界标记保持在分配区域,以便可能以相反的方向移动(traverse)分配的和空闲组块两者。这较优地允许关于在小偷请求上占用的页的安全恢复的有效实现。
在这一点上,图2显示在特定的示例实施方式中,可以怎样将页,包括缓存组片提供给OffHeapStorageArea逻辑存储空间。图2中,OffHeapStorageArea的逻辑存储空间包括多个数据块和空闲块,每一个都被彼夹在各自的头和尾的边界标签之间。如图2所示,页(包含缓存组片),包括OffHeapStorageArea逻辑区域,其转而包括标记的填充块和空闲块。
图3是特定的示例实施方式,说明用于从OffHeapStorageArea偷取页的示例程序的流程图。在步骤S302中,使用分配器的边界标记向后移动(traverse)内部的分配器,并且通过“removeAtAddress”回收信号将分配区域移动到存储区域的所有者。
这个重复持续到存储空间大小通过页面下降(drops),如S304步骤所确定。一旦期望的下降发生,在步骤S306中,所述页是未从存储空间映射的。如果未映射的页是如步骤S308中确定的小偷目标,那么这个过程是完整的。然而,在步骤S310中,如果未映射的页不是小偷的目标,则移动(traverse)映射页的列表以分配目标。在步骤S312中,目标的内容被复制到未映射页。在步骤S314中,目标映射被先前的未映射页替代,并且现在目标是空闲的,小偷完成。
将注意到,这一过程较优地允许以前使用的页面从存储空间安全地恢复,没有并行使用的风险。
并行的和/或锁定的OffHeapHashMap的变体也是可能的。例如,使用OffHeapHashMap,标准的数据结构的方法可以用来产生一个独占锁定的(类似哈希表)映射;一个共享读取,独占的写映射;一个分段的,独占锁定的并发映射;和一个分段的,共享读取,独占的写并发 映射。
堆外高速缓存器可能被认为有别于堆外映射,因为为了成功,引入的“存放”操作可能被允许从高速缓存器移除元素。从而,在特定的示例实施方式中,映射可能被视为具有比高速缓存器更高的优先级。在堆外映射中,当没有空间可用的时候,请求“存放”值的将会失败。
由于几个原因,映射中的“存放”操作可能失败。例如,映射的存储引擎可能在其二级数据结构中没有足够的可用空间来存储引入的{密钥,值}对。为访问这个失败的形式(form),在特定的示例实施例中,可能移除一个或更多映射,因为它只需要在存储引擎的二级数据结构能释放足够的空间。另一个失败的来源涉及到映射的表没有一个给定密钥可以存储的空闲位置(slot),在其中可以存储给定的密钥。在这种情况下,简单地移除任何一个或多个{密钥,值}对可能够。因为密钥只能在它的再探测(re-probe)序列内散列到一个位置(slot),可能移除用于这个序列内的密钥中的一个的映射。
可能使用时钟收回(eviction)计划(scheme)执行在堆外存储器实现内的收回(eviction)决定。在特定的实施方式中,用于高速缓存器的时钟位可以存储在用于每个入口的元数据区域。当每个高速缓存访问时(通过前面提到的OffHeapHashMap钩(hook)),设定用于访问映射的时钟位。当存储引擎发生故障时,钟针可以通过扫描表预设定所有设置的时钟位来扫描,找到一个未设置时钟位时扫描停止。然后从高速缓存器移出(evicted)与未设置时钟位一致的入口。当表调整大小失败时(因为为了成功,移出(evicted)应该在引入密钥的再探测(re-probing)序列内做出),一个不同的程序可以被遵循。首先,一个常规的移出(evicted)选择可以被执行,如果所选的映射落在re-prob序列中,则获得成功。如果这是不正确的,那么拥有先进的钟针(clock hand)和重置一些时钟位,可以检查再探测(re-probing)序列内的时钟位,并且可以挑选(picked)具有未设置的时钟位的第一个入口。如果没有未设置的位,一个序列入口可以随机被挑选。实施时钟收回(eviction)计划(scheme)的一个优点与速度相关。当然,将注意到可以在不同的示例实施方式中使用其他的移出(evicted)计划(例如,最近最少使用(LRU)的,最不经常使用的(LFU)等)。
在共享的读取高速缓存器中,时钟信息在读取锁定下更新,更新为允许“竞争地(racily)”传送的时钟信息(例如,可以接纳竞态条件),并且这些时钟数据的可见性改变为随后的移出(evicting)写线程,其通过在保护的ReentrantReadWriteLock中的不稳定的写/读对来保证。
在分段的高速缓存器中,PageSource是由各部分共享,具有以上时钟移出(evicted)计划可能不包括的移出(evicted)方案。被分段共享的PageSource可能会耗尽,然而尽管 所有自身的单元都已经被移出(evicted),目标部分不能完成“存放”操作/在这个示例方案中,为了使得“存放”成功,页面必须通过其他片段释放。为完成这个目标,保存对所有片段的参数的顶层映射,可能在每一片段开始收缩操作。这个操作是重新尝试的。这个过程可能会持续到操作成功或所有其他的映射都清除,并且操作仍然失败,在映射失败的情况下,它太大而不合适在分配的off-heap区域内。收缩可能以类似方式下完成页面偷取,通过要求每一部分潜在的OffHeapStorageArea释放其最近的页,从而移除存储在那页的映射。当映射被移除时,然后片段的表区域的收缩自然地发生。
用于服务阵列的示例实现
在特定的示例实施方式中,服务器数组(例如,硬件服务器数组)可能负责存储整个群集状态包括群集对象状态,锁定状态,客户端对象状态,搜索索引状态等等。它也可能在有要求时负责检索和提供这些信息给客户(L1s)。如一些操作,例如,分布式无用信息收集(DGC)也可能依赖于存储在服务器数组上的信息来操作。
存储在特定的示例实施方式的服务器数组的信息的数量可能非常庞大,并且可能与群集内的数据大小、群集内节点的数量、用于群集内的活动锁定的数量、在群集内生成的搜索索引等等成比例。特定的示例实施方式的服务器阵列可能有能力促进一些这样的信息,像需要的时候集合对象状态到持续的存储器。在特定的示例实施方式中,为了快速访问其余的信息可能存储在堆中。
然而这个方法存在几个问题。保存在永久存储中的信息读取比较慢,从而潜在地提高读取延迟的应用。因为信息存储在永久层,它可能需要随着状态信息的改变更新。因此,写入可能有较高的延迟和较低的吞吐量。一些信息(例如,锁定状态和映射状态对象)没有存储在永久存储中,它可能需要存储在堆中。相应的,对于伴随着很多节点访问他们的更大的数据大小,需要更多的堆空间来处理。无用单元收集长度指数增伴随更大的堆。由于无用单元收集中止更长和/或更频繁,运行大于6GBs的带堆可能会显得不切实际。较长的无用单元收集中止同样会使得它无法满足更严格的SLAs(服务等级协议)。此外,整个机器的内存可能不能使用服务器数组。
尽管它们可能存在,在特定的示例实施方式中的这些问题可能在服务器数组上解决。更特别地是,某些实施例提供对内存的巨大组块的访问可用到以前无法使用的机器。图4是显示一个适用于在特定的示例实施方式中的服务器阵列的示例方框图。
正如所知道的,一个高速缓存存储数据显然可用于其他更快的介质或接近于更快速访问的应用。某些实施例的技术可能用于为数据对象提供一个堆外高速缓存器,例如在服务器数组中。永久存储可能前移,同时数据对象可能为了更快访问而存储。换句话说,堆外高速缓存可能置于常规堆(可能在暂时内存实现)与永久存储(可能实现于非暂时计算机存储介质,例如一个物理磁盘)之间。
服务器数组可以在一个持久的模式或一个临时的交换模式运行。在一个持久模式中,集群的数据可能被写入磁盘防止服务器故障。在一个临时的交换模式中,数据只能在内存中没有空间存储时才被写入磁盘。某些实施例因此可以作为一个对象高速缓存工作,结合变体例子在各自内部运作,例如,如下所述。
在实施例中的持久模式,由于对象状态的改变,状态被写入堆外高速缓存和永久存储。这可能帮助防止服务器故障、功率故障或类似状况。如果堆接近充满,堆中的对象将全部移除。一个对象缓存在堆外高速缓存中的复制可能在永久存储上保留(例如,在磁盘上)。如果堆外高速存储被充满,那么一些off-heap高速缓存中的最少用对象可能通过一种启发式挑选并且从中移除。这些对象的一个复制可能保留在磁盘的状态信息不会丢失。
当一个对象需要读取时,对象可能从堆被访问。如果它不存在那里,那么堆外高速缓存可能被检查,并且最后磁盘或永久存储可能被检查。当一个对象只存在于永久存储并且被读取,它可能会断陷入off-heap高速缓存和/或堆。同时,在堆外高速缓存中一个对象的每一次访问,统计可能被更新以致于当一个移出(evicted)发生时,最少用对象都被堆外高速缓存移出(evicted)。
在特定的示例实施方式中,在临时的交换(swap)模式,对象停留在堆中直到它们因为缺乏空间被移出(evicted)。当它们被移出(evicted)时,状态写入堆外高速缓存。只有从堆外高速缓存移出(evicted)它们写入到永久存储。因此,对象状态驻留在一个堆内、堆外直接内存和永久存储。
当堆外高速缓存器填满时,其中的对象被移出(evicted)。移出(evicted)对象的一个通告作用在持久层持续状态到磁盘。多个对象可能持续分批处理,以帮助从持久层实现最大或至少增加通过量。
当一个对象被读取,对象从堆被访问。如果它是不存在那里,那么堆外高速缓存可能被检查,并且最后磁盘或永久存储可能被检查。当一个对象只存在于永久存储并且被读取,它可能会断陷入off-heap高速缓存和/或堆。同时,在堆外高速缓存中一个对象的每一次访问,统计可能被更新以致于的那个一个移出(evicted)发生时,其中最少使用的从那里被移出(evicted)。
通过使用特定的示例实施方式中的技术作为一个服务器数组中对象高速缓存,它可能能够实现更快的从堆外高速缓存读取访问数据,替代去到磁盘,在临时交换模式下更快地写入数据,随着数据返回到堆外高速缓存,在堆充满时替代磁盘,和/或能够使用机器中的大多数可用RAM。
大量的状态信息可能存储在服务器数组中,所述服务器数组使服务器能够正常地执行常规操作。一些状态信息承接可能包含大部分内存,例如,映射状态对象、锁定状态对象、搜索索引对象、客户端状态对象等。这些服务器中的数据结构随着服务器管理数据量的增长而增长。然而特定的示例实施方式可能执行用于服务器日常操作所需的存储账簿(bookkeeping)数据结构。
一个映射的接口明显地存储这些堆外高速缓存中的账簿数据结构可能在特定的示例实施方式中实现。在“存放”操作进入映射,密钥和值明显地序列化并且存储在off-heap中。在来自映射的“获取”操作,数据可能没有序列化,而且从off-heap高速缓存中读取。优化的序列可能未意识到数据明显地从off-heap位置存储和读取这个事实。另外这些接口,如列表、队列、集合、和/或类似的都可能实现明显地存储数据堆外。
这有利于使较小的堆存储更大数据集合,增加服务器内所有可用内存的利用率,减少无用单元收集中止和/或更多可预见的无用单元收集活动,和/或满足更严格的低延迟和更高吞吐量SLA的能力。
由于从不像堆外高速缓存中的其它任何地方的存储在堆外存储中的数据是不可用的,堆外存储可能不允许移出(evicted)任何此数据。一个堆外内存的大组块可能在存储和高速缓存之间分配和内部管理。在一定量的内存的基础上分配给服务器数组;并且在数据和使用模式的基础上,存储和高速缓存都如需要或要求的那样扩大和收缩。当所有内存分配到堆外已满,那么高速缓存开始移出(evicted)对象去适应新的对象。如果存储需要更多的内存去扩大并且存储新的入口,那么对象都从堆外高速缓存中移出(evicted),以便扩大存储的空间。
一些可能的提高方法可能与某些实施例相关。例如,在特定的示例实施方式中,只有映射状态对象存储在堆外存储中。但是在其他的实施例中,更多的状态(如锁定状态、搜索索引状态、客户端状态等)可以存储在堆外存储中。另外的接口,例如列表、集合和列队接口对于堆外存储。类似的,特殊用途的序列化可以建立以帮助避免在数据序列化和非序列化时的字节数组复制,从而帮助避免额外垃圾产生。
特定的示例实施方式提供一个高容量的解决方案(例如,提高到每节点1TB或更高),而一些目前的解决方案范围只有大约每字节32GB。在一个类似的情况中,特定的示例实施方式可能通过成千上万的应用使用,相比一些目前的方法只能支持几千个应用。
用于二级缓存(Ehcache)的示例实现
作为一个二级缓存(Ehcache)的延伸,特定的示例实施方式使用一个并行共享读取,作为一个存在于内存中(在堆上)与在磁盘上之间的媒介层独占写入堆外高速缓存。因此,实施例可以与分层缓存技术关联起来。
高速缓存上的“存放”操作可以填充堆外和磁盘层上,并且内存层上的“正存放”可能如果对一个密钥的写入已经在内存层内(例如,密钥是一个热集合的存在成员,如当它经常被访问时)或者如果内存层现在低于它的最大大小。这个映射帮助降低高速缓存的大块加载所引起的内存移出(evicted)活动(因为“正存放”新入口可以涉及在阈值下旧入口的移出(evicted)),同时仍保留了现有正常操作下热集合密钥的内存本质。
高速缓存器检索最初在内存层查找。如果这个搜索不成功,那么可能咨询(consulted)堆外层。如果失败,磁盘层最终会被检查。如果找到一个匹配的入口,那么每个层可能被访问入口所填充,并且发生未使用单元的必要移出(evicted)。
图5是显示特定的示例实施方式的多层次高速缓存途径的示例流程图。如图5所示,存放和获取操作检查连续层,为了确定这些层是否充满或分别包含数据。第一个可用层的一个碰撞结束了存放或获取的过程,然而一个在给定水平的失误把检查移动到下一个层底部,直到没有层存在为止。
为了与二级缓存(Ehcache)堆外存储层的大存储大小保持同步,提供了一个等效磁盘存储实现。在实施例中,这可能像堆外存储一样,再利用相同的映射函数,但是使用一个单一文件备份所有信息。这被完成使用适应现有的堆外存储。
首先,PageSource可能用于OffHeapHashMap实现,而不是创建页通过直接ByteBuffers备份(最终由RAM备份),创建MappedByteBuffers都是通过一个内存映射文件的部分来备份。这些内存映射部分可能通过OS(操作系统)在RAM中缓冲,但是仍然最终可能通过底层文件来备份。
其次,一个由相同文件备份的自定义StorageEngine实现可能已经被使用,但是自定义PageSource可能用于文件内分配空间存储密钥和值。在内部,FileBackedStorageEngine可以使用一个为了存储密钥和值保留文件组块的成倍扩展系列。最初,存储引擎可以从一个给定大小组块(例如64kb)开始。一旦这个组块被填满后,将会分配另一个两倍大小(例如,128kb)的组块,诸如此类的存储扩展。这些区域可能通过页面资源的保留来降低并行使用文件相同部分的引擎和表的可能性。这个成倍扩展组块大小的措施同样降低了组块的数量所需一个给定磁盘存储大小将会增长过甚的可能性,反过来可帮助降低元数据与跟踪组块占据太 多堆相关的可能性。
空间可能通过使用一个类似经常从off-heap组块分配页面的扩张的AA树为{密钥,值}对分配。这种方法可以替代一个就地算法使用,所以分配器信息(以一个非常“随机”的方式经常读取)可以保持在Java堆的低延迟区域,而不是磁盘上一个“随机”访问就可以由磁盘寻道延迟引起很多问题的高延迟区域。一些磁盘空间的效率因为四舍五入分配牺牲给了最近的两个电源。然而,这种方法已发现显著地减少了可能发生在磁盘存储中的碎片。据悉,可用空间元数据存储在堆中。磁盘可用空间内的严重碎片将会导致堆中元数据大小显著地增加.
一旦空间因为密钥被分配,实际磁盘写入可能缓存在堆中,而一个分离线程异步地写入数据到磁盘上的分配区域。当写入待定时,读取请求仍然可能通过堆中数据复制来服务。
用于HttpSession的示例执行
特定的示例实施方式可能与HttpSession相关被用于,例如,提供在如上所述的堆外高速缓存器中存储超文本传输协议会话(http session)的能力。HttpSession允许应用服务器按比例增加到数以亿计的用户而不是数万用户。当HttpSession被创建,它们要么直接存放在堆外高速缓存器中要么存储在堆上高速缓存器中,后来当堆上满了,就存储在堆外高速缓存器中。恢复通过第一次检查堆上高速缓存器工作,如果由于所需的数据不在出现错误,试图从堆外高速缓冲器恢复。
这样,特定的示例实施方式可能能够访问机器中所有的RAM 单一的无用单元收集程序没有与无用单元收集相关的。在无用单元收集运行时间内在标准的高速缓存器界面后对堆外内存的访问可能是未认识到的。同上,访问可能通过映射、阵列、列表和集界面提供的堆外内存来存储定期可串行化的在无用单元收集运行时间内堆外的对象以减少无用单元收集中断。在无用单元收集运行时间内可用的内存可能从堆外内存的组块中的OS被预先分配并且然后被内部管理。通过管理和存储分段中的数据并为任何给定的操作(比如,写/升级/移除/获取/调整大小等)只锁定其部分数据,堆外访问可以是通过所有正在访问它的进程高并发的。特定的示例实施方式也可能使用分段和C型(style)空间管理技术的结合来创建无中断或实质无中断的堆外映射/阵列/列表/数据结构。
特定的示例实施方式的技术可能缓存兆兆字节值的穿过计算机系统中的多个字节的数据。转而,这样做可以允许数以亿计的应用同时执行。页偷取也成为可能,甚至通过网络环境。
图6是执行特定示例实施方式的堆外直接内存高速缓存器的分层存储方法的例子。在图 6的图表中显示了示例的速度(以每秒完成的事务请求数)和可能的存储大小。图6被设计为具有朝着尽可能接近于应用代码一致地存储数据,但没有重载Java堆和它相关的无用单元收集器的目标。在最低层,数据存储在外部数据库,其呈现最慢的访问时间。比如,二级缓存打算排出尽可能多的对该层的访问以提高应用性能。相反,最顶层呈现在大存储器(BigMemory)保存最经常使用的数据的Java堆内的区域,允许读/写延迟少于1微秒。层直接在表示特定示例实施方式的内存中的高速缓存器的堆下面并且稍微远离堆,它虽然常驻在那儿,但隐藏于无用单元收集器以便它被设计为避免在JVM中引起中断。已经发现当执行特定的示例实施方式时,可以没有无用单元收集障碍(penalties)以大约100微秒访问大小为数以百计的千兆位字节的高速缓存器。
为了应用使用Terracotta服务器阵列(Terracotta Server Array)作为用于企业二级缓存(Enterprise Ehcache)的分布式高速缓存器,特定的示例实施方式的技术增加可用于服务器阵列中的每个节点的内存。随着更多的内存任凭每个Terracotta服务节点使用,兆兆字节范围分布式高速缓存器传递给一部分数量的节点。观察到服务器的数量可以由四个或更多的因素以实际的商业部署(commercial deployment)合并。
进一步示例的网络组件两者和/或多者之间的互操作性
应用扩展(scale)从单一机器安装到非常大的,多数据中心和云部署的请求范围。由于应用使用增加,并且更多的用户发送越来越大的波,那个应用的操作者经常发现提高大小以满足逐步提高的要求是具有挑战的。完成用于企业应用的高性能可扩展性(scalability)可能是费用大的问题和复杂的挑战。典型的方法要求发展密集的应用再设计,昂贵的数据库许可,和高级硬件。
在可扩展性(scalability)连续的一端(例如,在单一机器上运行的应用),增加的大小典型地包括试图增加原性能。快速缓存通常是降低延迟(latency)和提高传送率最容易和最有效的方法。高速缓存器存储retrive或计算起来相对费用大或费时的存储结果以便可以不用产生重复操作的费用完成依靠那些结果的后来的工作。增加有效的高速缓存通过放大命令能提高应用性能,有时具有很小的代码影响。
但是,对于高速缓存大量数据的应用,由于长无用单元收集中断,在Java虚拟机(JVM)中在传统的内存中的高速缓存可能是有问题的。在内存中存储更多数据要求更大的Java堆,因为很难并且有时甚至不可能预测什么时候将发生无用单元收集和它将持续多久。
但是,特定的示例实施方式可能用Java的直接缓存器API和高性能内存管理器在内存中 存储高速缓存器数据,但离开其中它对无用单元收集器是不可见的Java堆否则将在更大的堆大小引起长的和不可预测的中断。
并且如上所指,在此描述的示例堆外直接内存存储区域技术可能用在单一计算机上,与通过多个不同的的计算机节点运行的应用相关,在服务器上或者作为服务器阵列的一部分,和/或以这些位置的多种结合和子结合。因此可能以可靠地方式提供分布式高速缓存,例如,使得数据在多个JVM内的多个高速缓存管理器和它们的高速缓存器之间共享。从而可能线性地扩展应用以随请求增长,依靠保持一致通过群集的数据,卸载数据库以降低相关的内部整理自检(overhead),提高具有分布式内存中数据的应用性能,甚至访问更多强大的(powerful)API以平衡这些功能(capabilities)等。
这样,将注意到分配高速缓存技术可能用于群集的或横向扩展scaled-out的应用环境,例如,提供高水平的性能、可用性、和可扩展性。从而,特定的示例实施方式可能作为用于其他难以解决的性能和可扩展性问题的纯软件software only的方案被实施。
图11是根据特定的示例实施方式,分布式高速缓存器系统的逻辑图,其中多个应用服务器通过网络连接与服务器阵列连接。如图11所示,数据可能在节点层(L1高速缓存器)和服务器阵列(L2高速缓存器)之间被分割。
由于具有其它的复制机制,L1可以保存多达可适于节点的数据。在特定的示例实施方式中,在L2中可能提供所有高速缓存器数据的完全的副本。因此,L1可以作为在一些方案中最近使用的数据的热设定(hot-set)。此外,因为该分布式高速缓存途径是持久的并且高可用的,该高速缓冲器可能很大程度上不受特定的节点的终止的影响。例如,当节点重新启动时,它可能简单地重连接服务器阵列L2高速缓存器并且由于它使用数据填进它的本地L1高速缓存器。
图12显示根据特定的示例实施方式,用于分布式高速缓存器系统的网络拓补结构的视图。如图12所示,在L1,可能在每个应用中出现二级缓存(Ehcache)库,并且二级缓存实例,在进程内运行,位于每个JVM中。在L2,每个二级缓存实例(或节点)保持与一个或更多服务器连接。为了高可用性的目的,可能成对设置这些服务器,并且可能将一对称为一个镜像组。为了高可用性的目的,每个服务器可能在一个专用的服务器上运行。为了向外扩展的目的,可能增加许多对。一致的散列法可能被节点使用以存储和恢复在正确地服务器对中的高速缓存器数据。从而术语条带或分区可能用于指每个镜像组。
图13显示根据特定的示例实施方式,分配高速缓存器系统的层叠的分集存储器体系视图。一些或所有的进程内L1实例可能包括堆内内存和堆外内存(例如,使用此处描述的直接比特缓存器方法)。一些或所有的L2可能包括堆内内存和堆外内存,和磁盘存储器(例如, 为了在一个镜像组内的两个服务器同时遭受碰撞或动力故障的情况下的持续性)。注意到为了这些和/或其它的目的,某些L1实例也包括物理磁盘存储器。
图14是显示根据特定的实例实施方式,包括在两个应用层上的堆外直接内存管理并且为了服务器阵列的示例架构的另一个方框图。如图14所示,该应用层具有多个应用服务器分配应用工作量,并且可以视需要增加更多以处理更大的工作量。特定的示例实施方式可能与多个应用服务器和容器比如,Apache Tomcat,IBM WebSphere,JBoss,和Oracle WebLogic相配。虽然在图14中显示了多个服务器,需注意的是也可能与单独的Java服务器应用相关使用在此描述的技术。每个应用服务器具有在以微秒响应高速缓存器查找的二级缓存界面(Ehcache interface)后的内存中高速缓存器。
没有出现在内存高速缓存器中的用于高速缓存器进入(entries)的查找被自动通过TCP通信发送到服务器阵列。服务器阵列以毫秒响应高速缓存器查找。在应用层写入高速缓存器可能被发送给调节已知的写的服务器阵列,保持它给磁盘,并且使得高速缓存器更新具有在应用层其余的服务器需要的可配置的一致性保证。
所述服务器阵列是独立的可扩展的在商用硬件上运行的高速缓存器服务器的集合。这个阵列传送企业级数据管理给应用层中的二级缓存(Ehcache)。每一个高速缓存服务器可能具有内存高速缓存器和磁盘后备永久存储器,类似于RAID,该阵列可能被分配为多组服务器形成镜像条带。分布式高速缓存器中的数据穿过存在的条带被分区。可以根据需要增加更多的条带以增加总的可寻址的高速缓存器大小和I/O通过量。比如,为了高可用性,每个条带可能被事务处理镜像化。条带中的服务器节点应该被重新启动或失败,镜像中的一个可能自动使其发生,帮助提供提高的正常运行时间和数据可靠性。
依靠持久的存在磁盘上的存储器的可分配的内存高速缓存器的层叠的组合可以帮助允许对非常大的高速缓存器的高性能访问,不要求数以百计的服务器适应所有的内存中的高速缓存器。在应用层内,每个应用服务器中的进程内的二级缓存高速缓存器可能使用可分配数量的存储器提供对多达适合可用的RAM的高速缓存器数据的低延迟访问。在此描述的示例的堆外直接存储器技术可能用于容纳(accommodate)每个JVM的数以百计(或甚至更多)的千兆位字节。在需要的基础上,不适合内存的数据可能被自动地从服务器阵列恢复。
所述服务器阵列可能同样地具有可分配的磁盘后备内存高速缓存器。该内存高速缓存器和服务器阵列中条带的数量能够按大小分类以拟合(fit)多达要求的或需要的内存中的数据。该灵活性可能考虑到兆兆字节或更大数值范围(scale)的高速缓存器适应两个或一打商用服务器的可管理的和成本效益好的服务器阵列。
应用可能能够从同样的二级缓存界面(Ehcache interface)检索(retrieve)任何高 速缓存器入口,不管入口是否在本地内存中还是在服务器阵列中。在特定的示例例子中,如果高速缓存器入口被存储在应用服务器上的内存中,将以微秒返回高速缓存器读取。如果高速缓存器入口不在本地内存中,将可能从服务器阵列以毫秒自动地检索(retrieve)它。
为提高企业应用的性能,以下和/或其它方面可能根据它们在符合应用要求上相对的影响被平衡,即,通过量(如,一般以应用能够处理的事物的比率测量);延迟(如,完成个别事务花费的时间);和一致性(如,应用操作的数据的可预测性、相干性coherency和正确性的等级)。使用特定的示例实施方式的技术,通过给服务器阵列增加更多的条带可以提高通过量;和/或能够减少延迟并且通过在应用层中增加更多的应用服务器可以提高用于应用操作的可用的CPU的能力(power)。
应用层中的应用逻辑从服务器阵列中的高速缓存器逻辑的分离可能允许每一个根据它特别的任务被最优化。比如,在应用层出现的进程内高速缓存器可以被优化为高并发性和低线程竞争(thread contention)提高每个应用节点的性能。在特定的方案中,因为在应用层中的硬件操作没有高速缓存服务器任务的重载(overloaded),可以将它的资源用于应用业务逻辑。所述应用JVM堆可以被分配的相对较小并且,因此,不受造成点对点高速缓存器中的长服务中断的无用单元收集操作的影响。
服务器阵列的专用的高速缓存器功能可以提供不可用于其它高速缓存器技术的使得多个运行时间优化的中心权限(central authority)。比如,可以在运行时间将事务hatched,folded,和重新排序以提高通过量。因为没有要求交叉节点确认,可以减少延迟。在特定的示例例子中,可以根据需要灵活地扩展服务器阵列,没有故障时间。
在服务器阵列中的每个条带可以是用循环分区算法传遍条带的高速缓存器数据的什么也不共享(share-nothing)的分区。结果,可以增加没有附加的内部整理自检(overhead)的新的条带。比如,与静态分区方案相比,服务器阵列使用的循环分区可以允许增加新的条带,不用再散列(rehash)所有条带。因此,可以促使新的条带更快地联机(online)。
基于上文所述,然后,将注意到一些或所有以下的和/或其它的特征可以成为可能:在特定的示例实施方式中,计算机系统包括至少一个提供的处理器,一个有形(tangibly)存储数据的非瞬变计算机可读存储介质。软件应用可通过至少一个处理器执行并且被程序化以使用数据。
堆外内存被动态地部署并且被内存管理器直接管理,以使堆外内存可被软件应用感知成为本地应用层内存的一部分并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和运行计算机系统的操作系统的任何内存管理器。所述堆外内存可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外 内存中的数据显然地可以微秒提供给来自堆外内存的软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。
根据特定的示例实施方式,所述软件应用和/或内存管理器是基于Java的。
根据特定的示例实施方式,存储在堆外内存可读功能的数据是来自非瞬态计算机可读存储器介质的数据和/或来自网络数据资源的数据。
根据特定的示例实施方式,通过内存管理器,在堆外存储器中的数据变得可以访问遗留系统和/或应用。
根据特定的示例实施方式,堆外内存为软件应用提供针对兆兆位字节大小的数据的兆兆位字节大小的窗口。
根据特定的示例实施方式,(例如,为了高可用性的目的)堆外内存内的数据被反映(mirrored)到物理存储单元。
在特定的示例实施方式中,提供一种管理计算机系统的内存的方法,该计算机系统包括至少一个处理器,一个有形(tangibly)存储数据的非瞬变计算机可读存储介质,和通过至少一个处理器可执行的并且被程序化以使用数据的软件应用。
堆外内存被动态地部署并且使用内存管理器直接管理,以使堆外内存数据存储区域可被软件应用感知成为本地应用层内存的一部分并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和运行计算机系统的操作系统的任何内存管理器。所述堆外直接内存数据存储区域可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外直接内存数据存储区域中的数据显然地可以微秒提供给来自堆外内存的软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。这个方法可以与基于Java的环境相关操作,并且可以进一步包括:(a)试图分配在预分配的最大大小的组块中的Java比特缓存块响应以预设的最大大小的堆外直接内存数据存储器;(b)重复所述分配比特缓存块的尝试直到堆外直接内存数据存储区域以预定的大小被创建,或者直到尝试失败,不论哪个先出现;(c)当分配比特缓存块的尝试失败,降低预分配的最大大小并且重复(a)-(b);(d)接收堆外直接内存数据存储区域的范围请求,该范围具有相关的大小;(e)通过页源(page source),寻找堆外直接内存数据存储区域的不用的组片。(f)返回表明不用的组片的页,该页成为封包(wrapped)比特缓存块,其包含对存储数据的组片的访问和对创建组片的分配器对象的访问。(g)继续返回页直到堆外直接内存数据存储区域被耗尽。(h)管理从堆外直接内存数据存储区域返回的页作为单一的相干的(coherent)存储数据密钥(key)和值的逻辑地址空间,在存储具有连接数据密钥和值的元数据信息的散列表的堆外直 接内存数据存储区域内具有单一的页。并且可选择地(i)通过再散列进入一个新的页,分别响应入口进一步被加入和被移出而扩展和收缩所述散列表。
根据特定的示例实施方式,根据试图的分配的失败,预分配的最大大小被减半。
根据特定的示例实施方式,所述方法可以进一步包括当预分配的最大大小被减少到低于阈值时引起故障。
根据特定的示例实施方式,对数据被存储的或将被存储的组片的访问是对一个或更多缓存块的补偿(offset)。
根据特定的示例实施方式,使用分配内存和空闲算法实施(h)内的管理。
根据特定的示例实施方式,数据密钥和值作为字节阵列存储。
根据特定的示例实施方式,所述散列表作为IntBuffer存储。
根据特定的示例实施方式,页被返回以使每一所述的页有能量(power)2的大小。根据特定的示例实施方式,数据可以在一个地址被存储到堆外直接内存数据存储区域,该地址有与每一所述的页的大小相同的能量2。
根据特定的示例实施方式,单一的树关联每一组块,每一所述的树被增大(augment)作为存储相关组块内的空闲区域集合的一个区域集合。根据特定的示例实施方式,每一所述的树是AA树。根据特定的示例实施方式,在给定的AA树的每一子树内发现的空闲区的集合被存储在位屏蔽内。
根据特定的示例实施方式,页偷取是可行的并且允许在不同的页的用户之间共享页。根据特定的示例实施方式,所述单一的页包含不可偷取的散列表。
根据特定的示例实施方式,每一个页请求包括指示使用中的页是否应该被偷取的参数以符合分配要求(如果需要)并且从而创建新的页的小偷参数;与创建的新的页相关的、允许该页请求指示新的页后续是否能够被偷取以符合配置要求的的牺牲者(victim)参数;和指示新的页的拥有者(owner)是谁的拥有者(owner)参数。
根据特定的示例实施方式,所述小偷和牺牲者(victim)参数是指示页偷取的相对优先顺序的数字值。
根据特定的示例实施方式,当页源指示它需要空间并且不能返回适当大小的页时,所述方法可能进一步包括:分配标记为牺牲者(victim)的空闲区域和页试图找出合适大小的目标区域以满足页源的要求;在页源的部分上接触目标区域内的牺牲者的拥有者(owner);引起牺牲者的拥有者(owner)到指示物的任何移动;并且返回到页源,目标区域内的牺牲者。
根据特定的示例实施方式,第一和第二树结构可能为每个所述组块被保持,第一树结构指示那个组块内的空闲区域并且第二树结构指示那个组块内的空闲和牺牲者(victim)区域。
要注意的是这些和/或其它的示例技术可能被应用于不管位于哪里的堆外直接内存存储区域。比如,要注意的是这些和/或其它的示例技术可能被应用于位于应用服务器、服务器阵列内的节点上的堆外直接内存存储区域。
在特定的示例实施方式中,提供一种计算机系统。提供多个计算机节点,和可以穿过Java虚拟机(JVM)环境中的多个计算机节点执行的应用。每个计算机节点包含至少一个处理器;内存管理软件;和一个动态分配的并且由相关的计算机节点的内存管理软件直接管理的堆外直接内存数据存储区域,所述堆外直接内存数据存储区域可根据从相关计算机节点的内存管理软件到调节的兆兆位字节值的数据的方向扩展以便从那儿可提供存储在堆外直接内存数据存储区域的所述数据,而不用必须重复地访问来自非瞬态计算机可读存储介质或网络存储单元的所述数据。
根据特定的示例实施方式,每一计算机节点被分配为在检查任何其它计算机节点的堆外直接内存数据存储区域之前和在检查网络存储单元之前搜索它本身的用于要求的数据的堆外直接内存数据存储区域。
在特定的示例实施方式中,提供一种系统。应用可在至少一个计算机上执行。也提供独立可扩展的调节的内存管理器的服务器阵列和相关的数据存储节点。每一所述的数据存储节点包括通过应用可用的有形存储数据的非瞬变计算机可读存储介质。每一所述内存管理器包括:至少一个处理器,动态分配并且由内存管理器直接管理的堆外内存。所述堆外内存可根据从内存管理器到调节的兆兆位字节值的数据的方向扩展以便从堆外内存可提供存储在堆外内存的所述数据,而不用必须重复地访问来自节点非瞬态计算机可读存储介质的所述数据。当请求的数据没有出现在至少一个计算机上的高速缓存器内,请求未被应用认识到时,所述至少一个计算机包括分配为自动开始来自服务器阵列的数据请求的编程逻辑。
根据特定的示例实施方式,所述至少一个计算机可以包括多个计算机和可能通过多个计算机可执行的应用。根据特定的示例实施方式,每一所述计算机可以具有它自身的用于创建和管理其上的堆外直接内存存储区域的内存管理器。比如,根据特定的示例实施方式,每一计算机可以包括至少一个处理器;内存;计算机特有的内存管理软件;和自动分配并由相关计算机的计算机特有的内存管理软件直接管理的计算机特有的堆外直接内存数据存储区域,所述计算机特有的堆外直接内存数据存储区域可根据从计算机特有的内存管理软件到调节数据的数值高达相关计算机的内存的大小的方向扩展。
根据特定的示例实施方式,每一计算机被分配为明显地检查它本身的计算机特有的用于数据的堆外直接内存数据存储区域,先于从另一个计算机请求所述数据并且先于从服务器阵 列请求所述数据。
根据特定的示例实施方式,所述服务器阵列被分配为满足基于对所述内存管理器中的一个的微秒数据查找的毫秒内的请求。
根据特定的示例实施方式,为高可用性的目的,所述服务器阵列中的每个所述的内存管理器进一步包括非瞬态计算机可读介质以反映数据。
根据特定的示例实施方式,所述服务器阵列显然是可扩展的以便附加的内存管理器和/或节点可加入服务器节点,而不用必须重新分配所述应用。
需注意还根据进一步的示例实施方式,这些特征、方面、优点和实施方式可以以任何适当的组合或子组合被结合。也需注意特定的示例实施方式涉及操作多个系统、内存管理器/内存管理软件组件等的方法。
测试数据
依靠持久的存在磁盘上的存储器的可分配的内存高速缓存器的层叠的组合允许对非常大的高速缓存器的高性能访问,不要求数以百计的服务器适应所有的内存中的高速缓存器。
为测试特定的示例实施方式的优点,设计并执行一个实验。该实验要求高速缓存Java应用内的内存中的高达350GB的数据。实验开始于将100GB的数据高速缓存入150GB Java堆。没有调整,结果是不可用的,因为紧接的全部无用单元收集周期消耗了所有的处理时间。经过很大程度的调整,并且将堆大小增加至200GB以减少总的堆占用,应用程序运行,但得到很差的性能,因为它常常被长的无用单元收集停顿而中断。在堆内保持大的缓存不是一个可扩展的方案。
所述测试方案包括连续写入和只读操作的组合。更特别的,所述测试方案包括在其中平均地在读和写之间分开访问的高速缓存器。
测试环境包括具有24核的服务器和378GB的RAM,在Red Hat Enterprise Linux上运行Java SE 1.6.0_21。所有的软件,包括OS和Java虚拟机,都是64位,允许大内存寻址空间。测试应用以两个测试方案运行,即,根据特定的示例实施方式,设计和管理用于堆上高速缓存器的Java堆(250GB),和小Java堆(2GB)和350GB的堆外高速缓存器。
在两种方案中,其中通过高速缓存器90%的时间访问数据的10%的“热集”的高速缓存方案被建模。当高速缓存器的大小增加超过4GB时,没使用特定的示例实施方式的技术的应用性能快速并且一致地下降。然而,当高速缓存器的大小达到350GB时,包括特定的示例实施方式的技术的测试方案一致地保持非常好的性能和延迟。
在两者测试方案中,测量性能参数,比如当高速缓存器的大小增长时,无用单元收集花 费的总时间,和应用通过量(以事务每秒)和最大延迟(大概由无用单元收集活动引起的)。
图7是对照用于有和没有执行特定的示例实施方式的堆外内存管理途径的测试方案的最大的全面无用单元收集持续活动的图表。
对于堆上数据高速存储器,无用单元收集时间随堆占用增加直到应用成为非响应的。
然而,对于特定的示例实施方式的技术,由于数据高速缓存器被保持在内存中但远离Java堆,因此即使高速缓存器的大小增加GC时间保持恒定并较小,例如,因为堆外高速缓存器不受无用单元收集影响。
图8是对照用于有和没有执行特定的示例实施方式的堆外内存管理途径的测试方案的最大的延迟的图表。当在堆上高速缓存测试方案中无用单元收集持续时间增加,最大延迟也一样。然而,由于在特定的示例实施方式中,堆外高速缓存器的大小不影响Java堆,即使高速缓存器的大小增长,无用单元收集时间保持一致,并且通常不存在。
图9-10是分别显示当执行特定的示例实施方式时,相对于增加的数据大小平均延迟和通过量的图表。如从图9-10可以看出的,当高速缓存器的大小从4GB增长到150GB,且超过时,特定的示例实施方式提供一致的性能。它们也显示特定的示例实施方式促进在服务器内的最大内存使用,即使有非常大(例如,350GB或更多)的数据高速缓存器的大小,根据最大延迟和通过量可预测符合SLA,并且简化部署,因为不一定需要分配和分布高速缓存器。
以229,623毫秒(ms)运行用于20GB高速缓存器的堆上分配影响261,618TPS的平均通过量。这包括预热阶段和多个试运行以确保最佳性能。相反,运行与特定的示例实施方式相同的测试分配影响819,998TPS的平均通过量,只有73,127ms的运行时间。这样,通过量和性能超过堆上测试有三倍增加。以下表格概述影响总体性能的无用单元收集相关的结果。
上表显示了在测试过程中收集无用单元所花费的总时间、最长和最短的无用单元收集停顿时间以及平均时间。可以看出,在只有堆上方式以及利用20GB的Java堆来保持20GB内 存,无用单元收集所花费的总时间超过247秒,最大停顿时间大约为66秒以及平均停顿时间为大约50秒。该表还将涉及在更小的堆上进行的测试(由于堆外高速缓存器保存20GB内存)进行对比。在后者中,平均停顿时间为0.25秒,总的无用单元收集时间只有大约一秒。
下表显示了关于吞吐量的数据,提示了大量相似的结论。
公制 | 只有堆上内存 | 实施例 |
占用空间 | 20.608MB | 198.438MB |
释放的内存 | 10,908.54MB | 366.736MB |
释放的内存/分 | 2,259.784MB/min. | 146.075MB/min. |
总时间 | 4min.,49sec. | 2min.,30sec. |
累积停顿时间 | 247.86sec. | 1.03sec. |
吞吐量 | 14.42% | 99.32% |
完全无用单元收集性能 | 44.01MB/sec | 356.203MB/sec. |
上表说明了,在特定的示例实施方式中,Java堆花费大量的时间运行应用代码,而非执行无用单元收集活动。堆上内存的结果刚好相反:花费大量的时间执行无用单元收集活动,而运行应用代码的时间仅为执行无用单元收集活动时间的15%。在这些测试中,从吞吐量和延迟的角度来看,特定的示例实施方式相比Java堆上的存储器,明显提供了更好的性能。
除了这些特定的测试,通过其他的实施方式,已经实测到15x~100x范围内的性能增益和延迟改良。例如,利用在LAN上的基于磁盘的数据库,已实测到100x的改良;利用基于RAM的固态存储器(solid-state drives,SSD),已实测到15x的改良;利用基于闪存的SSD甚至可以获得更大的改良。
可理解的,尽管上述实施例的测试中使用一定的实例配置,其还可以执行其他配置运行,例如:无用单元收集调整是/不是一个进行中耗费时间的工作;Java虚拟机为32位或64位的版本;内存大小可改变(例如,从2GB到250GB以及其他);应用程序使用本地或分布的内存;等等。
在特定的示例实施方式中,还可以涉及一种开放资源的方式。
整个企业内,一般存在必要的条件以支持数据存取,而且数据存取遵循一连串的连续性 规则。这连串的范围可能从适合仅读取接入的完全异地操作,到完全相互的关密钥业务数据存取。例如,在特定的实施例中,可能提供一个从最终的(单调读或写)到完全锁定的实际的连续统一体,从而提供一种更灵活的可配置的方案,在一定程度上能够满足用户的连续性需求以提高性能。在特定的示例实施方式中,这为可配置的参数。
在特定的示例实施方式中,还可以涉及XA事务,例如,为了容纳现有的XA用户,或高速存储器实例中需要精确的业务要求的其他用户。
可理解的,“通融千兆字节数据”意味着可通融(例如,根据比例缩放,管理,一般使可利用的,等等)至少1TB的数据。这样,也就是说,堆外存储器从作为内存管理者到可通融千兆字节数据的趋势上升级为计算机系统存储器的大小,那么堆外存储器可升级为1TB、10TB、100TB、和/或其他大小,且也可能限制于计算机系统存储器大小。相似地,“升级为计算机系统存储器尺寸”以及类似这样的术语没必要严格说明,因为整合所有的方式升级为计算机系统存储器尺寸实际上是被禁止的,在一些情况下由于其他的事项会占有至少其中一部分的空间,例如,操作系统内核等等。相反,在特定的情况下,这些措辞可以更好的理解为“达到最大可能的限度”或“计算机系统内所有可利用的内存”。例如,一个内存为1TB的系统,Linux内核占有的内存为1GB,那么这里公开的实例中的内存管理者仍然要接入升级为计算机系统存储器尺寸的内存,那么允许接入999GB字节的计算机内存。
术语“毫秒范围内”在一些情况下可以理解为不大于10秒,较佳的为不大于1秒。类似地,术语“微秒范围内”在一些情况下可理解为大于10毫秒,较佳的为不大于1毫秒。在特定的实施方式中,还可以取十分之一缩小量之外的缩放比例。
可理解的,“Java”一词可表示为一种语言或一种技术或同时表示为两者,要根据其使用的特定环境。当“Java”可表示为一种技术时,其为一种包含远大于原始语言定义的世界通用标准。因此,应当理解“基于Java环境”表示为使用这种广阔技术领域的一种环境,无论是Java本身写入的应用程序环境,还是使用JVM的应用程序(可支持多种语言,Java语言为其中一种),和/或其他类似的。
可理解的,尽管描述的一些实施方式是关于Java-和/或基于Java环境的,本发明公开的实例方案也可以应用到包括无用单元收集环境的任何系统中,利用上述的和/或其他的方式能够和/或应该可以避免以提高性能。
应当理解,这里所使用的终端系统、子系统、服务器、可变成逻辑电路等等应结合软件、硬件、韧体等等来一起执行。且,此处所述的存储器应为硬件驱动器、记忆存储器、固态硬盘驱动器,CD-ROM、DVD、磁带后备器、存储区域网络系统的结合体或/及任何有形(tangibly)的计算机存储媒介。较佳地,所述技术与处理器协同执行存储在计算机存储介质中的命令。
以上所述是本发明的优选实施方式,应当指出,对于本技术领域的普通技术人员来说,在不脱离本发明原理的前提下,还可以做出若干改进和润饰,这些改进和润饰也视为本发明的保护范围。
Claims (40)
1.一种计算机系统,包括:
至少一个处理器;
一个有形存储数据的非瞬变计算机可读存储介质;
可通过至少一个处理器执行并且被程序化以使用数据的软件应用;和
堆外内存,其被动态地布署并且被内存管理器直接管理,以使堆外内存可被软件应用感知成为本地应用层内存的一部分并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和在计算机系统上运行的操作系统的任何内存管理器,
其中,所述堆外内存可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外内存中的数据显然地可以在毫秒内从堆外内存提供给软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。
2.如权利要求1所述的系统,其中所述软件应用和内存管理器是基于Java的。
3.如权利要求1所述的系统,其中存储在堆外内存可读功能的数据是来自非瞬态计算机可读存储器介质的数据和/或来自网络数据资源的数据。
4.如权利要求1所述的系统,其中堆外存储器中的数据可以通过内存管理器访问遗留系统和/或应用。
5.如权利要求1所述的系统,其中堆外内存为软件应用提供针对兆兆位字节大小的数据的兆兆位字节大小的窗口。
6.如权利要求1所述的系统,其中堆外内存内的数据被反映到物理存储单元。
7.一种管理计算机系统的内存的方法,包括至少一个处理器,一个有形存储数据的非瞬变计算机可读存储介质,和通过至少一个处理器可执行的并且被程序化以使用数据的软件应用,所述方法包括:
使用内存管理器,动态地部署并且直接管理堆外直接内存存储区域,以使所述堆外内存数据存储区当成为本地应用层内存的一部分时通过软件应用是可感知的并且是可管理的,在初始分配后,独立于计算机系统的任何内存管理器和运行计算机系统的操作系统的任何内存管理器,
其中,所述堆外直接内存数据存储区域可扩展为高达计算机系统的内存的大小,根据来自内存管理器的指令,调节兆兆字节值的数据,以便存储在堆外直接内存数据存储区域中的数据显然地可以在微秒内从堆外内存提供给软件应用并且不用必须重复访问来自非瞬态计算机可读存储介质的数据。
8.如权利要求7所述的方法,其中所述方法与基于Java的环境相关操作,并且进一步包括:
(a)尝试以预设的最大大小分配在预分配的最大大小的组块中的Java比特缓存块响应堆外直接内存数据存储器的请求;
(b)重复所述分配比特缓存块的试直到堆外直接内存数据存储区域以预定的大小被创建,或者直到尝试失败,不论哪个先出现;
(c)当分配比特缓存块的尝试失败,降低预分配的最大大小并且重复(a)-(b);
(d)接收堆外直接内存数据存储区域的范围请求,该范围具有相关的大小;
(e)通过页源,寻找堆外直接内存数据存储区域的不用的组片;
(f)返回表明不用的组片的页,所述页成为封包比特缓存块,其包含对存储数据的组片的访问和对创建组片的分配器对象的访问;
(g)继续返回页直到堆外直接内存数据存储区域被耗尽;
(h)管理从堆外直接内存数据存储区域返回的页作为单一的相干的存储数据密钥和值的逻辑地址空间,在存储具有连接数据密钥和值的元数据信息的散列表的堆外直接内存数据存储区域内具有单一的页;并且
(i)通过再散列进入一个新的页,分别扩展和收缩所述散列表以响应被加入和被移出的进一步的入口。
9.如权利要求8所述的方法,其中根据试图的分配的失败,所述预分配的最大大小被减半。
10.如权利要求8所述的方法,进一步包括当减少预分配的最大大小到低于阈值时引起故障。
11.如权利要求8所述的方法,其中对在其中存储数据的或将被存储的组片的访问是对一个或更多缓存块的补偿。
12.如权利要求8所述的方法,其中使用分配内存和空闲算法实施所述(h)内的管理。
13.如权利要求8所述的方法,其中数据密钥和值作为字节阵列存储。
14.如权利要求8所述的方法,其中所述散列表作为IntBuffer存储。
15.如权利要求8所述的方法,其中返回页以使每一所述的页有能量2的大小。
16.如权利要求15所述的方法,进一步包括在一个地址存储数据到堆外直接内存数据存储区域,该地址有与每一所述的页的大小相同的能量2。
17.如权利要求8所述的方法,进一步包括为每一组块关联单一的树,每一所述的树被增大作为存储关联组块内的空闲区域集的一个区域集。
18.如权利要求17所述的方法,其中每一所述的树是AA树。
19.如权利要求18所述的方法,进一步包括在位屏蔽内存储在给定的AA树的每一子树内发现的空闲区域的集。
20.如要求8所述的方法,进一步包括使得页偷取允许在不同的页的用户之间共享页。
21.如要求20所述的方法,其中每一个页请求包括
指示使用中的页是否应该被偷取以符合分配要求(如果需要)并且从而创建新的页的小偷参数;
与创建的新的页相关的、允许该页请求指示新的页后续是否能够被偷取以符合分配要求的的牺牲者参数;
和指示新的页的拥有者是谁的拥有者参数。
22.如要求21所述的方法,其中所述小偷和牺牲者参数是指示页偷取的相对优先顺序的数字值。
23.如要求22所述的方法,其中所述单一的页包含不可偷取的散列表。
24.如要求8所述的方法,进一步包括:当页源指示它需要空间并且不能返回适当大小的页时,分配标记为牺牲者的空闲区域和页尝试找出合适大小的目标区域以满足页源的要求;
在页源的部分上接触目标区域内的牺牲者页的拥有者;
引起牺牲者页的拥有者到指示物的任何移动;并且
返回到页源,目标区域内的牺牲者页。
25.如要求24所述的方法,进一步包括为每个所述组块保持第一和第二树结构,第一树结构指示那个组块内的空闲区域并且第二树结构指示那个组块内的空闲和牺牲者区域。
26.一种计算机系统,包括:
多个计算机节点,可以通过Java虚拟机JVM环境中的多个计算机节点执行的应用,其中:
每个计算机节点包括:
至少一个处理器;
内存管理软件,和
一个动态分配的并且由相关的计算机节点的内存管理软件直接管理的堆外直接内存数据存储区域,所述堆外直接内存数据存储区域可根据从相关计算机节点的内存管理软件到调节的兆兆位字节值的数据的方向扩展以便从那儿可提供存储在堆外直接内存数据存储区域的所述数据,而不用必须重复地访问来自非瞬态计算机可读存储介质或网络存储单元的所述数据。
27.如权利要求26所述的计算机系统,其中每一计算机节点被分配为在检查任何其它计算机节点的堆外直接内存数据存储区域之前和在检查网络存储单元之前搜索它本身的用于要求的数据的堆外直接内存数据存储区域。
28.如权利要求26所述的计算机系统,其中每一计算机节点被分配为:
(a)尝试以预设的最大大小分配在预分配的最大大小的组块中的Java比特缓存块响应堆外直接内存数据存储器的请求;
(b)重复所述分配比特缓存块的试直到堆外直接内存数据存储区域以预定的大小被创建,或者直到尝试失败,不论哪个先出现;
(c)当分配比特缓存块的尝试失败,降低预分配的最大大小并且重复(a)-(b);
(d)接收堆外直接内存数据存储区域的范围请求,该范围具有相关的大小;
(e)通过页源,寻找堆外直接内存数据存储区域的不用的组片。
(f)返回表明不用的组片的页,所述页成为封包比特缓存块,其包含对存储数据的组片的访问和对创建组片的分配器对象的访问。
(g)继续返回页直到堆外直接内存数据存储区域被耗尽。
(h)管理从堆外直接内存数据存储区域返回的页作为单一的相干的存储数据密钥和值的逻辑地址空间,在存储具有连接数据密钥和值的元数据信息的散列表的堆外直接内存数据存储区域内具有单一的页。
29.如权利要求28所述的计算机系统,其中每一计算机节点的所述内存管理软件进一步分配为(i)通过再散列进入一个新的页,分别扩展和收缩所述散列表以响应被加入和被移出的进一步的入口。
30.如权利要求28所述的计算机系统,其中所述内存管理器根据(a)被分配为避免Java无用单元收集。
31.一种系统,包括:
在至少一个计算机上执行的应用;和
独立可扩展的调节的内存管理器的服务器阵列和相关的数据存储节点;其中:
每一所述的数据存储节点包括通过应用可用的有形存储数据的非瞬变计算机可读存储介质,
每一所述内存管理器包括:
至少一个处理器,和
动态分配并且由内存管理器直接管理的堆外内存,
所述堆外内存可根据从内存管理器到调节的兆兆位字节值的数据的方向扩展以便从堆外内存可提供存储在堆外内存的所述数据,而不用必须重复地访问来自节点非瞬态计算机可读存储介质的所述数据,且
当请求的数据没有出现在至少一个计算机上的高速缓存器内,请求未被应用认识到时,所述至少一个计算机包括分配为自动开始来自服务器阵列的数据请求的编程逻辑。
32.如权利要求31所述的系统,其中所述至少一个计算机包括多个计算机和可能通过多个计算机可执行的应用。
33.如权利要求32所述的系统,其中每一计算机包括:
至少一个处理器;
内存;
计算机特有的内存管理软件;和
自动分配并由相关计算机的计算机特有的内存管理软件直接管理的计算机特有的堆外直接内存数据存储区域,所述计算机特有的堆外直接内存数据存储区域可根据从计算机特有的内存管理软件到调节数据的数值高达相关计算机的内存的大小的方向扩展。
34.如权利要求33所述的系统,其中每一计算机被分配为明显地检查它本身的计算机特有的用于数据的堆外直接内存数据存储区域,先于从另一个计算机请求所述数据并且先于从服务器阵列请求所述数据。
35.如权利要求31所述的系统,其中所述服务器阵列被分配为满足基于对所述内存管理器中的一个的微秒数据查找的毫秒内的请求。
36.如权利要求31所述的系统,其中为高可用性的目的,所述服务器阵列中的每个所述的内存管理器进一步包括非瞬态计算机可读介质以反映数据。
37.如权利要求31所述的系统,其中所述服务器阵列显然是可扩展的以便附加的内存管理器和/或节点可加入服务器节点,而不用必须重新分配所述应用。
38.一种提供数据给在至少一个网络系统内的计算机上可执行的应用的方法,该网络系统包括包含多个独立地可扩展调节的内存管理器和相关的数据存储节点的服务器阵列,
其中:
每一所述的数据存储节点包括通过应用可用的有形存储数据的非瞬变计算机可读存储介质,
每一所述内存管理器包括:
至少一个处理器,和
动态分配并且由内存管理器直接管理的堆外内存,
所述堆外内存可根据从内存管理器到调节的兆兆位字节值的数据的方向扩展以便从堆外内存可提供存储在堆外内存的所述数据,而不用必须重复地访问来自节点非瞬态计算机可读存储介质的所述数据,且
当请求的数据没有出现在至少一个计算机上的高速缓存器内,请求未被应用认识到时,所述至少一个计算机包括分配为自动开始来自服务器阵列的数据请求的编程逻辑。
39.如权利要求38所述的方法,其中每一计算机节点涉及每一所述的节点被分配为:
(a)尝试以预设的最大大小分配在预分配的最大大小的组块中的Java比特缓存块响应堆外直接内存数据存储器的请求;
(b)重复所述分配比特缓存块的试直到堆外直接内存数据存储区域以预定的大小被创建,或者直到尝试失败,不论哪个先出现;
(c)当分配比特缓存块的尝试失败,降低预分配的最大大小并且重复(a)-(b);
(d)接收堆外直接内存数据存储区域的范围请求,该范围具有相关的大小;
(e)通过页源,寻找堆外直接内存数据存储区域的不用的组片。
(f)返回表明不用的组片的页,所述页成为封包比特缓存块,其包含对存储数据的组片的访问和对创建组片的分配器对象的访问;
(g)继续返回页直到堆外直接内存数据存储区域被耗尽;
(h)管理从堆外直接内存数据存储区域返回的页作为单一的相干的、用于存储数据密钥(key)和值的逻辑地址空间,在存储具有连接数据密钥和值的元数据信息的散列表的堆外直接内存数据存储区域内具有单一的页。
40.如权利要求39所述的方法,其中所述应用可通过多个计算机执行,每一所述计算机具有它自身的用于创建和管理其上的堆外直接内存存储区域的内存管理器。
Applications Claiming Priority (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US201161446442P | 2011-02-24 | 2011-02-24 | |
US61/446,442 | 2011-02-24 | ||
US13/354,892 US8832674B2 (en) | 2011-02-24 | 2012-01-20 | Off-heap direct-memory data stores, methods of creating and/or managing off-heap direct-memory data stores, and/or systems including off-heap direct-memory data store |
US13/354,892 | 2012-01-20 |
Publications (1)
Publication Number | Publication Date |
---|---|
CN103558992A true CN103558992A (zh) | 2014-02-05 |
Family
ID=46719893
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
CN201210046529.8A Pending CN103558992A (zh) | 2011-02-24 | 2012-02-24 | 堆外直接内存数据存储器,创建和/或管理堆外直接内存数据存储器的方法,和/或包括堆外直接内存数据存储器的系统 |
Country Status (2)
Country | Link |
---|---|
US (3) | US8832674B2 (zh) |
CN (1) | CN103558992A (zh) |
Cited By (11)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107341154A (zh) * | 2016-04-29 | 2017-11-10 | 北京京东尚科信息技术有限公司 | 一种数据导出的方法和装置 |
CN107728937A (zh) * | 2017-09-15 | 2018-02-23 | 上海交通大学 | 一种使用非易失性内存介质的键值对持久存储方法及系统 |
CN107844579A (zh) * | 2017-11-10 | 2018-03-27 | 顺丰科技有限公司 | 优化用于分布式数据库中间件取数的方法、系统及设备 |
CN108196937A (zh) * | 2017-12-26 | 2018-06-22 | 金蝶软件(中国)有限公司 | 字符串对象的处理方法、装置、计算机设备和存储介质 |
CN109783006A (zh) * | 2017-11-14 | 2019-05-21 | 三星电子株式会社 | 计算系统及操作计算系统的方法 |
CN109902032A (zh) * | 2019-01-31 | 2019-06-18 | 泰康保险集团股份有限公司 | 堆外内存管理方法、装置、介质及电子设备 |
CN110895475A (zh) * | 2018-09-10 | 2020-03-20 | 深圳云天励飞技术有限公司 | 搜索服务器的启动方法、装置及搜索服务器 |
CN111091488A (zh) * | 2019-12-10 | 2020-05-01 | 河北万方中天科技有限公司 | 基于OpenCV的内存管理方法、装置及终端 |
CN111241010A (zh) * | 2020-01-17 | 2020-06-05 | 中国科学院计算技术研究所 | 一种基于缓存划分及回滚的处理器瞬态攻击防御方法 |
CN113626446A (zh) * | 2021-10-09 | 2021-11-09 | 阿里云计算有限公司 | 数据存储和查找方法、装置、电子设备及介质 |
CN116909689A (zh) * | 2023-09-14 | 2023-10-20 | 中航金网(北京)电子商务有限公司 | 虚拟机热迁移方法、装置、存储介质和电子设备 |
Families Citing this family (75)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7991910B2 (en) | 2008-11-17 | 2011-08-02 | Amazon Technologies, Inc. | Updating routing information based on client location |
US7970820B1 (en) | 2008-03-31 | 2011-06-28 | Amazon Technologies, Inc. | Locality based content distribution |
US7962597B2 (en) | 2008-03-31 | 2011-06-14 | Amazon Technologies, Inc. | Request routing based on class |
US9003035B1 (en) | 2010-09-28 | 2015-04-07 | Amazon Technologies, Inc. | Point of presence management in request routing |
US8832674B2 (en) | 2011-02-24 | 2014-09-09 | Software Ag Usa, Inc. | Off-heap direct-memory data stores, methods of creating and/or managing off-heap direct-memory data stores, and/or systems including off-heap direct-memory data store |
US10467042B1 (en) | 2011-04-27 | 2019-11-05 | Amazon Technologies, Inc. | Optimized deployment based upon customer locality |
US9104678B1 (en) * | 2011-12-31 | 2015-08-11 | Richard Michael Nemes | Methods and apparatus for information storage and retrieval using a caching technique with probe-limited open-address hashing |
US9083608B2 (en) * | 2012-01-24 | 2015-07-14 | International Business Machines Corporation | Automatically selecting appropriate platform to run application in cloud computing environment |
US9389965B1 (en) * | 2012-03-12 | 2016-07-12 | Emc Corporation | System and method for improving performance of backup storage system with future access prediction |
US9154551B1 (en) | 2012-06-11 | 2015-10-06 | Amazon Technologies, Inc. | Processing DNS queries to identify pre-processing information |
US10515141B2 (en) | 2012-07-18 | 2019-12-24 | Software Ag Usa, Inc. | Systems and/or methods for delayed encoding of XML information sets |
US9760549B2 (en) | 2012-07-18 | 2017-09-12 | Software Ag Usa, Inc. | Systems and/or methods for performing atomic updates on large XML information sets |
US9922089B2 (en) | 2012-07-18 | 2018-03-20 | Software Ag Usa, Inc. | Systems and/or methods for caching XML information sets with delayed node instantiation |
US9489293B2 (en) * | 2012-08-17 | 2016-11-08 | Netapp, Inc. | Techniques for opportunistic data storage |
US9021050B2 (en) * | 2012-08-31 | 2015-04-28 | Yume, Inc. | Network service system and method with off-heap caching |
US9513886B2 (en) | 2013-01-28 | 2016-12-06 | Arizona Board Of Regents On Behalf Of Arizona State University | Heap data management for limited local memory(LLM) multi-core processors |
GB2511325A (en) | 2013-02-28 | 2014-09-03 | Ibm | Cache allocation in a computerized system |
US8893155B2 (en) * | 2013-03-14 | 2014-11-18 | Microsoft Corporation | Providing distributed array containers for programming objects |
US9015689B2 (en) | 2013-03-14 | 2015-04-21 | Board of Regents on Behalf of Arizona State University | Stack data management for software managed multi-core processors |
US8683262B1 (en) | 2013-06-21 | 2014-03-25 | Terracotta Inc. | Systems and/or methods for rapid recovery from write-ahead logs |
US9128855B1 (en) * | 2013-06-26 | 2015-09-08 | Emc Corporation | Flash cache partitioning |
US9767019B2 (en) | 2013-09-17 | 2017-09-19 | Red Hat, Inc. | Pauseless garbage collector write barrier |
US10223256B1 (en) * | 2013-10-28 | 2019-03-05 | Pivotal Software, Inc. | Off-heap memory management |
US9697220B2 (en) * | 2013-12-13 | 2017-07-04 | Oracle International Corporation | System and method for supporting elastic data metadata compression in a distributed data grid |
US9514018B2 (en) | 2014-01-28 | 2016-12-06 | Software Ag | Scaling framework for querying |
US9678787B2 (en) | 2014-05-23 | 2017-06-13 | Microsoft Technology Licensing, Llc | Framework for authoring data loaders and data savers |
US10990288B2 (en) * | 2014-08-01 | 2021-04-27 | Software Ag Usa, Inc. | Systems and/or methods for leveraging in-memory storage in connection with the shuffle phase of MapReduce |
US9680919B2 (en) | 2014-08-13 | 2017-06-13 | Software Ag Usa, Inc. | Intelligent messaging grid for big data ingestion and/or associated methods |
US9753850B1 (en) * | 2014-08-15 | 2017-09-05 | Hazelcast, Inc. | On-heap huge slab allocator |
CN106716412B (zh) | 2014-09-25 | 2020-08-14 | 甲骨文国际公司 | 用于支持分布式计算环境中的零拷贝二进制基数树的系统和方法 |
US9734204B2 (en) | 2014-12-11 | 2017-08-15 | International Business Machines Corporation | Managed runtime cache analysis |
US10176097B2 (en) | 2014-12-16 | 2019-01-08 | Samsung Electronics Co., Ltd. | Adaptable data caching mechanism for in-memory cluster computing |
US10097448B1 (en) | 2014-12-18 | 2018-10-09 | Amazon Technologies, Inc. | Routing mode and point-of-presence selection service |
US9965514B2 (en) | 2014-12-19 | 2018-05-08 | Software Ag Usa, Inc. | Techniques for real-time generation of temporal comparative and superlative analytics in natural language for real-time dynamic data analytics |
US10225326B1 (en) | 2015-03-23 | 2019-03-05 | Amazon Technologies, Inc. | Point of presence based data uploading |
US9832141B1 (en) | 2015-05-13 | 2017-11-28 | Amazon Technologies, Inc. | Routing based request correlation |
US10410135B2 (en) | 2015-05-21 | 2019-09-10 | Software Ag Usa, Inc. | Systems and/or methods for dynamic anomaly detection in machine sensor data |
US10223257B2 (en) | 2015-07-27 | 2019-03-05 | International Business Machines Corporation | Multi-section garbage collection |
US10942864B2 (en) | 2015-11-20 | 2021-03-09 | Hewlett Packard Enterprise Development Lp | Shared memory for distributed data |
CA3008830C (en) * | 2015-12-16 | 2020-09-22 | Ab Initio Technology Llc | High throughput, high reliability data processing system |
US9846651B2 (en) * | 2016-01-22 | 2017-12-19 | Samsung Electronics Co., Ltd. | Computing system with cache management mechanism and method of operation thereof |
US9983999B2 (en) | 2016-01-22 | 2018-05-29 | Samsung Electronics Co., Ltd. | Computing system with cache management mechanism and method of operation thereof |
US10467152B2 (en) | 2016-05-18 | 2019-11-05 | International Business Machines Corporation | Dynamic cache management for in-memory data analytic platforms |
US10204175B2 (en) * | 2016-05-18 | 2019-02-12 | International Business Machines Corporation | Dynamic memory tuning for in-memory data analytic platforms |
US10075551B1 (en) * | 2016-06-06 | 2018-09-11 | Amazon Technologies, Inc. | Request management for hierarchical cache |
US10110694B1 (en) | 2016-06-29 | 2018-10-23 | Amazon Technologies, Inc. | Adaptive transfer rate for retrieving content from a server |
US10616250B2 (en) | 2016-10-05 | 2020-04-07 | Amazon Technologies, Inc. | Network addresses with encoded DNS-level information |
US10678562B2 (en) * | 2016-11-17 | 2020-06-09 | K&M Systems, Inc. | Systems and methods for facilitating real-time analytics |
US10831549B1 (en) | 2016-12-27 | 2020-11-10 | Amazon Technologies, Inc. | Multi-region request-driven code execution system |
CN108628678B (zh) * | 2017-03-21 | 2020-11-03 | 中国移动通信集团河北有限公司 | 内存参数的确定方法、装置及设备 |
US10628307B2 (en) * | 2017-05-08 | 2020-04-21 | International Business Machines Corporation | Coordinating heap contraction of multiple runtimes in the cloud environment |
US11580084B2 (en) * | 2017-06-22 | 2023-02-14 | Microsoft Technology Licensing, Llc | High performance dictionary for managed environment |
US11307909B2 (en) * | 2017-08-29 | 2022-04-19 | SK Hynix Inc. | System for slowdown status notification and operating method thereof |
US20190044809A1 (en) * | 2017-08-30 | 2019-02-07 | Intel Corporation | Technologies for managing a flexible host interface of a network interface controller |
US10742593B1 (en) | 2017-09-25 | 2020-08-11 | Amazon Technologies, Inc. | Hybrid content request routing system |
CN108345673A (zh) * | 2018-02-09 | 2018-07-31 | 弘成科技发展有限公司 | 在线成人教育高等院校定制化报表导出方法 |
US10901910B2 (en) * | 2018-04-05 | 2021-01-26 | International Business Machines Corporation | Memory access based I/O operations |
US20190332370A1 (en) * | 2018-04-30 | 2019-10-31 | Microsoft Technology Licensing, Llc | Storage reserve in a file system |
US10838875B2 (en) * | 2018-05-11 | 2020-11-17 | Oath Inc. | System and method for managing memory for large keys and values |
US10776256B2 (en) * | 2018-05-16 | 2020-09-15 | International Business Machines Corporation | Sharing consumed off-heap for parallel data loading |
US10481817B2 (en) * | 2018-06-28 | 2019-11-19 | Intel Corporation | Methods and apparatus to optimize dynamic memory assignments in multi-tiered memory systems |
US11169804B2 (en) * | 2018-09-24 | 2021-11-09 | Oracle International Corporation | Method for vectorizing d-heaps using horizontal aggregation SIMD instructions |
US11068375B2 (en) * | 2018-10-17 | 2021-07-20 | Oracle International Corporation | System and method for providing machine learning based memory resiliency |
US10862852B1 (en) | 2018-11-16 | 2020-12-08 | Amazon Technologies, Inc. | Resolution of domain name requests in heterogeneous network environments |
US11016778B2 (en) | 2019-03-12 | 2021-05-25 | Oracle International Corporation | Method for vectorizing Heapsort using horizontal aggregation SIMD instructions |
US10884641B2 (en) | 2019-04-16 | 2021-01-05 | Paypal, Inc. | Low latency gateway for an asynchronous orchestration engine using direct memory |
US10929054B2 (en) | 2019-06-06 | 2021-02-23 | International Business Machines Corporation | Scalable garbage collection |
US11573793B2 (en) | 2020-03-18 | 2023-02-07 | Oracle International Corporation | Lazy push strategies for vectorized D-Heaps |
CN111651374A (zh) * | 2020-04-14 | 2020-09-11 | 北京齐尔布莱特科技有限公司 | 一种数据处理方法、装置、计算设备及可读存储介质 |
CN111736776B (zh) * | 2020-06-24 | 2023-10-10 | 杭州海康威视数字技术股份有限公司 | 一种数据存储、读取方法及装置 |
CN113742095A (zh) * | 2021-01-14 | 2021-12-03 | 北京沃东天骏信息技术有限公司 | 一种缓存数据处理方法、装置、电子设备及存储介质 |
US11526437B1 (en) * | 2021-06-11 | 2022-12-13 | International Business Machines Corporation | Heap space management |
CN113608804B (zh) * | 2021-10-11 | 2022-01-04 | 北京华品博睿网络技术有限公司 | 一种可持久化的Java堆外缓存系统及方法 |
CN114265670B (zh) * | 2022-03-02 | 2022-09-23 | 阿里云计算有限公司 | 一种内存块整理方法、介质及计算设备 |
US11971817B2 (en) * | 2022-04-29 | 2024-04-30 | Oracle International Corporation | Managing lifecycles of sets of foreign resources |
Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020055929A1 (en) * | 2000-11-06 | 2002-05-09 | International Business Machines Corporation | Computer system with multiple heaps |
CN1581106A (zh) * | 2003-08-07 | 2005-02-16 | 西门子共同研究公司 | 用于大数据体的先进内存管理体系 |
US20100312850A1 (en) * | 2009-06-09 | 2010-12-09 | Bhalchandra Dattatray Deshpande | Extended virtual memory system and method in a computer cluster |
Family Cites Families (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US8832674B2 (en) * | 2011-02-24 | 2014-09-09 | Software Ag Usa, Inc. | Off-heap direct-memory data stores, methods of creating and/or managing off-heap direct-memory data stores, and/or systems including off-heap direct-memory data store |
-
2012
- 2012-01-20 US US13/354,892 patent/US8832674B2/en active Active
- 2012-02-24 CN CN201210046529.8A patent/CN103558992A/zh active Pending
-
2014
- 2014-08-07 US US14/454,017 patent/US9176870B2/en active Active
-
2015
- 2015-10-02 US US14/873,383 patent/US9990132B2/en active Active
Patent Citations (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20020055929A1 (en) * | 2000-11-06 | 2002-05-09 | International Business Machines Corporation | Computer system with multiple heaps |
CN1581106A (zh) * | 2003-08-07 | 2005-02-16 | 西门子共同研究公司 | 用于大数据体的先进内存管理体系 |
US20100312850A1 (en) * | 2009-06-09 | 2010-12-09 | Bhalchandra Dattatray Deshpande | Extended virtual memory system and method in a computer cluster |
Cited By (19)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN107341154A (zh) * | 2016-04-29 | 2017-11-10 | 北京京东尚科信息技术有限公司 | 一种数据导出的方法和装置 |
CN107728937A (zh) * | 2017-09-15 | 2018-02-23 | 上海交通大学 | 一种使用非易失性内存介质的键值对持久存储方法及系统 |
CN107728937B (zh) * | 2017-09-15 | 2020-09-04 | 上海交通大学 | 一种使用非易失性内存介质的键值对持久存储方法及系统 |
CN107844579A (zh) * | 2017-11-10 | 2018-03-27 | 顺丰科技有限公司 | 优化用于分布式数据库中间件取数的方法、系统及设备 |
CN107844579B (zh) * | 2017-11-10 | 2021-10-26 | 顺丰科技有限公司 | 优化用于分布式数据库中间件取数的方法、系统及设备 |
CN109783006B (zh) * | 2017-11-14 | 2022-05-17 | 三星电子株式会社 | 计算系统及操作计算系统的方法 |
CN109783006A (zh) * | 2017-11-14 | 2019-05-21 | 三星电子株式会社 | 计算系统及操作计算系统的方法 |
CN108196937A (zh) * | 2017-12-26 | 2018-06-22 | 金蝶软件(中国)有限公司 | 字符串对象的处理方法、装置、计算机设备和存储介质 |
CN110895475A (zh) * | 2018-09-10 | 2020-03-20 | 深圳云天励飞技术有限公司 | 搜索服务器的启动方法、装置及搜索服务器 |
CN110895475B (zh) * | 2018-09-10 | 2023-03-31 | 深圳云天励飞技术有限公司 | 搜索服务器的启动方法、装置及搜索服务器 |
CN109902032B (zh) * | 2019-01-31 | 2021-05-25 | 泰康保险集团股份有限公司 | 堆外内存管理方法、装置、介质及电子设备 |
CN109902032A (zh) * | 2019-01-31 | 2019-06-18 | 泰康保险集团股份有限公司 | 堆外内存管理方法、装置、介质及电子设备 |
CN111091488A (zh) * | 2019-12-10 | 2020-05-01 | 河北万方中天科技有限公司 | 基于OpenCV的内存管理方法、装置及终端 |
CN111091488B (zh) * | 2019-12-10 | 2023-06-23 | 河北元然昀略科技有限公司 | 基于OpenCV的内存管理方法、装置及终端 |
CN111241010A (zh) * | 2020-01-17 | 2020-06-05 | 中国科学院计算技术研究所 | 一种基于缓存划分及回滚的处理器瞬态攻击防御方法 |
CN111241010B (zh) * | 2020-01-17 | 2022-08-02 | 中国科学院计算技术研究所 | 一种基于缓存划分及回滚的处理器瞬态攻击防御方法 |
CN113626446A (zh) * | 2021-10-09 | 2021-11-09 | 阿里云计算有限公司 | 数据存储和查找方法、装置、电子设备及介质 |
CN116909689A (zh) * | 2023-09-14 | 2023-10-20 | 中航金网(北京)电子商务有限公司 | 虚拟机热迁移方法、装置、存储介质和电子设备 |
CN116909689B (zh) * | 2023-09-14 | 2024-01-16 | 中航国际金网(北京)科技有限公司 | 虚拟机热迁移方法、装置、存储介质和电子设备 |
Also Published As
Publication number | Publication date |
---|---|
US8832674B2 (en) | 2014-09-09 |
US9990132B2 (en) | 2018-06-05 |
US20120222005A1 (en) | 2012-08-30 |
US9176870B2 (en) | 2015-11-03 |
US20160026392A1 (en) | 2016-01-28 |
US20140351549A1 (en) | 2014-11-27 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN103558992A (zh) | 堆外直接内存数据存储器,创建和/或管理堆外直接内存数据存储器的方法,和/或包括堆外直接内存数据存储器的系统 | |
US11907200B2 (en) | Persistent memory management | |
US11288252B2 (en) | Transactional key-value store | |
US9959279B2 (en) | Multi-tier caching | |
US8069191B2 (en) | Method, an apparatus and a system for managing a snapshot storage pool | |
KR102051282B1 (ko) | 선택적 리소스 이동을 이용하는 네트워크 결합 메모리 | |
US8909887B1 (en) | Selective defragmentation based on IO hot spots | |
CN110226157A (zh) | 用于减少行缓冲冲突的动态存储器重新映射 | |
US20180011893A1 (en) | Hash index | |
US8176233B1 (en) | Using non-volatile memory resources to enable a virtual buffer pool for a database application | |
US20180011892A1 (en) | Foster twin data structure | |
US11100083B2 (en) | Read only bufferpool | |
US20180107601A1 (en) | Cache architecture and algorithms for hybrid object storage devices | |
US20140181042A1 (en) | Information processor, distributed database system, and backup method | |
CN109117088B (zh) | 一种数据处理方法及系统 | |
US20190391963A1 (en) | Hybrid model of fine-grained locking and data partitioning | |
WO2014142337A1 (ja) | ストレージ装置と方法及びプログラム | |
KR101686346B1 (ko) | 하이브리드 ssd 기반 하둡 분산파일 시스템의 콜드 데이터 축출방법 | |
CN111611223B (zh) | 非易失性数据的访问方法、系统、电子设备和介质 | |
US11474938B2 (en) | Data storage system with multiple-size object allocator for disk cache | |
CN114518962A (zh) | 内存的管理方法及装置 | |
US20240086362A1 (en) | Key-value store and file system | |
Oh et al. | Mitigating Journaling Overhead via Atomic Write | |
CN107066624B (zh) | 数据离线存储方法 | |
Son et al. | An Empirical Performance Evaluation of Transactional Solid-State Drives |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
C06 | Publication | ||
PB01 | Publication | ||
SE01 | Entry into force of request for substantive examination | ||
SE01 | Entry into force of request for substantive examination | ||
C02 | Deemed withdrawal of patent application after publication (patent law 2001) | ||
WD01 | Invention patent application deemed withdrawn after publication |
Application publication date: 20140205 |