创新触手可及: 通过 IBM eXtremeMemory 实现超越 Java 堆的弹性缓存

让 WebSphere eXtreme Scale 变得更完美

IBM® WebSphere® eXtreme Scale 的 7.1.1 版引入了一个额外的内存型弹性缓存模型,即 IBM eXtremeMemory,它使您能够利用 Java™ 堆外部的系统内存作为弹性缓存。这允许用户使用更小的 WebSphere eXtreme Scale 容器 Java 堆大小,并最大程度地减少了垃圾收集暂停对事务响应时间的影响。因为 eXtremeMemory 位于 Java 虚拟机 (JVM) 环境之外,所以我们开发了一种名为 IBM eXtremeIO 的新传输方式,用它来提高 eXtremeMemory 弹性缓存的容错能力。eXtremeIO 实现了 WebSphere eXtreme Scale 容器之间高效的内存到内存复制。本文将概述 eXtremeMemory 和 eXtremeIO 功能。 本文来自于 IBM WebSphere Developer Technical Journal 中文版

Charles Le Vay, 高级软件架构师, IBM

Charles Le Vay 是一位高级软件架构师,他最近加入 WebSphere Emerging Technologies 团队,担任技术推广职务。他目前主要致力于在企业中推广弹性数据网格技术的优势。在此之前,他是 IBM 的 WebSphere Application Server 的 Web Service 互操作性架构师。他是 Web 服务互操作性组织(Web Service Interoperability Organization,WS-I)可靠安全概要(Reliable Secure Profile,RSP)工作组的 IBM 代表。作为一名互操作性架构师,Charles 确保 IBM 产品满足行业标准互操作性条件。他负责确定并详细描述用于实现 Web 服务互操作性的最佳实践。在担任该职位之前,Charles 致力于移动应用程序开发、无线技术以及将企业应用程序安全地扩展到移动设备。在加入 IBM 之前,Charles 为海军开发了高级潜艇声纳系统,并专门研究信号处理和水声学。他毕业于杜克大学并拥有物理学学位。



2012 年 9 月 13 日

每一期的 “创新触手可及” 系列文章都提供了与新兴技术相关的主题的新信息和讨论(无论是从开发人员还是从业者的角度),以及对领先的 IBM® WebSphere® 产品的幕后观察。

简介

IBM WebSphere eXtreme Scale 是 IBM 的一个基于软件的战略性弹性缓存平台。WebSphere eXtreme Scale 是一个基于 Java 的内存型数据网格,它跨数百个服务器动态处理、分区、复制和管理应用程序数据和业务逻辑。它具有极高的灵活性,适用于广泛的缓存场景。WebSphere eXtreme Scale 具有全面的弹性。可在数据网格中添加或删除服务器,数据网格将自动重新分发,以便最充分地使用可用的资源,同时仍然提供对数据的持续访问和无缝的容错能力。WebSphere eXtreme Scale 提供了成熟的多数据中心功能,可轻松集成其他 IBM 应用程序基础架构产品,为您的企业提供一个强大、高性能的弹性缓存解决方案。

WebSphere eXtreme Scale 软件的 7.1.1 版引入了一个额外的内存型弹性缓存模型,即 IBM eXtremeMemory,该模型能够利用 Java 堆外部的系统内存作为弹性缓存。这允许用户使用更小的 WebSphere eXtreme Scale 容器 Java 堆大小,并最大程度地减少了垃圾收集暂停对事务响应时间的影响。因为 eXtremeMemory 位于 Java 虚拟机 (JVM) 环境之外,所以我们开发了一种名为 IBM eXtremeIO 的新传输方式,用它来提高 eXtremeMemory 弹性缓存的容错能力。eXtremeIO 实现了配置来使用 eXtremeMemory 的 WebSphere eXtreme Scale 容器之间高效的内存到内存复制。

本文将探讨垃圾收集因某些服务水平协议指标而暂停对基于 Java 的内存型数据网格事务响应时间有何影响。本文将分享有关开发 eXtremeMemory 和 eXtremeIO 的理由的一些见解,探讨 eXtremeMemory 和 eXtremeIO 对事务响应时间一致性的影响,以及实现此功能的技术细节。


响应时间一致性何时至关重要

许多业务应用程序设计用于满足一组特定的服务水平协议 (SLA)。一个 SLA 可包含一些性能指标,这些指标可能包括吞吐量、正常运行时间、可用性和响应时间。对于近似实时的大规模事务性业务流程,响应时间至关重要。更具体而言,响应时间一致性非常重要。这个响应时间指标是以百分比的形式进行度量的。例如,90% 的事务响应时间应该小于 5 毫秒。这意味着在给定时间间隔内,不超过 10% 的事务响应时间可长于 5 毫秒,或者 90% 的事务响应时间必须小于 5 毫秒。当将此标准应用于某个基于 Java 的弹性数据网格时,如图 1 所示,您可以看到此指标很难超过 80% 时。超过 80% 后,响应时间显著增加,这是弹性数据网格 JVM 中的垃圾收集暂停的累积效应。

图 1. 超过 90% 后的显著响应时间增加
图 1. 超过 90% 后的显著响应时间增加

垃圾收集始终是 Java 运行时的一部分。它的用途是释放一个由 Java 程序创建的、不再引用的对象,使编程人员无需管理分配的资源,进而最大程度地减少了与内存管理有关的错误。JVM 负责管理进程堆。垃圾收集器执行压缩等操作并扩展进程内存大小。

当调节 Java 运行时时,主要目的是确定最佳的 JVM 堆大小,从而最大程度地提高性能。增加 JVM 堆大小可允许在分配失败并触发垃圾收集之前创建更多对象。这使应用程序能够在垃圾收集周期之间运行更长时间。但是,堆大小越大,垃圾收集所花的时间(暂停时间)就越长。所以,JVM 堆大小调节是垃圾收集之间的间隔与执行垃圾收集所需的暂停时间之间的一种权衡。

垃圾收集器使用启发式方法来管理进程堆。JVM 为不同的用例和目标提供了不同的启发式方法:最佳的吞吐量、最佳的暂停时间、是否属于同一期的、是否平衡和实时。运行启发式方法具有相关的成本。多年来,垃圾收集已变得越来越智能和高效。

WebSphere eXtreme Scale 利用了数十、数百或者甚至数千个 JVM 作为弹性内存型数据网格的基础构建块。需要的 JVM 的数量取决于网格的大小需求。每个 JVM 的 Java 堆内存用于存储弹性数据网格中的一部分数据。数据分区为数据块或数据碎片 (shard)。碎片分散在弹性数据网格中可用的 JVM 上。弹性数据网格的一个功能是容错。这通过数据复制来完成。当事务在网格中写入或更新数据时,该操作在主要碎片上执行。作为同一个事务的一部分,数据会复制到一个与主要碎片不在同一个 JVM 中的副本碎片。因此,如果包含主要碎片的 JVM 失败,副本碎片中的数据仍然可用。弹性数据网格会在事务中自动处理此复制。

因为垃圾收集暂停会在托管弹性数据网格的所有 Java 运行时上发生,所以垃圾收集显然会对网格的总体性能产生一定的影响。这里的关键是垃圾收集何时发生以及每个压缩周期的时间长度。如果垃圾收集在一个事务中顺序发生,或者在一个事务运行期间在该事务中包含的特定 JVM 上多次发生,则可能影响该事务的响应时间。对 SLA 的影响是在整个事务生命周期中的所有压缩时间的总和。

有两个极端可突出某种潜在的问题情形。首先,考虑许多小的压缩周期,这些周期集中在一起可慢慢延长事务的响应时间。这种行为会产生可预测的响应时间,但平均响应时间无法满足 SLA。相反,考虑少量具有很长压缩时间的压缩周期。在此情形下,平均响应时间通常表现很好,但当发生大型压缩时,SLA 就会受到显著影响。现在,考虑网格中的 JVM 上的数千个事务,在一个事务期间在 JVM 上发生顺序垃圾收集的统计概率会增加,因为事务量太大。

图 2 显示了配置为同步复制的网格上的一个 PUT 操作流程。同步复制暗示着事务仅在主要碎片和副本碎片上都已完成写入操作后才会完成。

图 2. PUT 操作的事务流
图 2. “put” 操作的事务流

因此,如果垃圾收集在事务的所有 JVM 中顺序发生,所以累积暂停时间会延长事务的响应时间。出于此原因,特定的响应时间很难达到 90%。这并不是说这些延长的事务响应时间比典型的响应时间长几个数量级,但对于非常具有时效性的业务流程,甚至极小的响应时间变化也是不可接受的,并且不会满足更加严格的响应时间指标。


eXtremeMemory + eXtremeIO 解决方案

因为一般用途的 Java 应用程序中的 Java 对象没有严格定义的生命周期,所以垃圾收集启发式方法是执行有效的内存管理的首选方式。WebSphere eXtreme Scale 不是一个一般用途的 Java 应用程序,它专门设计为一个弹性数据网格。弹性数据网格是一组分布式映射,每个映射包含存储为键值对的 Java 对象。映射条目有一个由执行的操作确定的已知生命周期:

  • 键和值对象在 INSERT 期间分配。
  • 键和值对象在 DELETE 期间撤销。
  • 新值对象在 UPDATE 期间分配,旧值对象在 UPDATE 期间撤销。

因此,WebSphere eXtreme Scale 应该能够使用此信息明确管理映射条目内存资源,而不是将此任务委托给启发式方法。这种定义良好的对象生命周期是设计 eXtremeMemory 的关键。

IBM eXtremeMemory 扩展了 WebSphere eXtreme Scale 的功能,以便利用弹性数据网格中的 Java 堆外部的系统内存。当启用 IBM eXtremeMemory 时,该功能会显著减少 WebSphere eXtreme Scale 容器 JVM 的堆大小,因为 Java 堆不再是弹性数据网格内存的主要存储机制。图 3 显示了没有 eXtremeMemory 的 WebSphere eXtreme Scale 进程内存需求的区别,以及启用了 eXtremeMemory 后所需的 WebSphere eXtreme Scale 进程堆大小的显著减小。通过显著减小堆大小,垃圾收集的暂停会显著缩短。启用了 eXtremeMemory 之后,垃圾收集不再参与弹性数据网格内存的管理。eXtremeMemory 直接基于映射条目的定义良好的生命周期来管理系统内存资源。它使用系统原语分配内存和撤销内存。在实际中,eXtremeMemory 仅受托管平台上可寻址的系统内存量的限制。

图 3. 启用和禁用 eXtremeMemory 后的 eXtreme Scale 进程内存
图 3. 启用和禁用 eXtremeMemory 后的 eXtreme Scale 进程内存

对象请求代理 (ORB) 是 Java 2 平台的一个运行时组件,用于使用 Internet 的 ORB 间协议 (IIOP) 的分布式计算。在设计上,WebSphere eXtreme Scale 是一个分布式系统。因此,ORB 服务用作所有 WebSphere eXtreme Scale 组件之间的基础传输方法。ORB 使基于 Java 的 WebSphere eXtreme Scale 客户端可远程访问弹性数据网格容器中的对象。它还提供了一种通信机制,WebSphere eXtreme Scale 容器可通过该机制跨 JVM 执行复制,确保弹性数据网格中的容错能力。

对于存储在 Java 堆(启用了 eXtremeMemory)中的对象,ORB 是一种有效的传输方法。但是,当对象存储在 Java 堆外部的系统内存中时,对于读操作,必须首先从系统内存(堆外)为对象去除序列化,然后将其放入 Java 堆中,使 Java 客户端能够通过 ORB 访问该对象。对于写或更新操作,对象首先写入到 Java 堆中,然后会将它序列化并写入系统内存中。可以使用一个自定义序列化程序最大程度地减少这种额外的序列化开销,该序列化程序取代了标准的 Java 序列化。自定义序列化程序同时针对序列化性能和已序列化的对象的内存密度进行了优化。

IBM eXtremeIO 是一种增强的复制协议,用于减少启用 eXtremeMemory 时的序列化成本。eXtremeIO 取代了 ORB,用于 WebSphere eXtreme Scale 容器间通信。这消除了在主要碎片和副本碎片之间进行复制所需的序列化开销。eXtremeIO 使系统内存中的对象无需去除序列化即可在碎片之间复制。图 4 显示在启用了 eXtremeMemory 时 PUT 操作的传输方法。ORB 用于 WebSphere eXtreme Scale 客户端 JVM 与主要碎片之间的通信。eXtremeIO 用于主要碎片与副本碎片之间的通信。

实验室测试表明,对于每个事务的平均响应时间,eXtremeMemory 和 eXtremeIO 的组合大约会增加 10-20% 的额外开销;但是,标准偏差得到了显著减少。这是保持响应时间一致性所需付出的少许代价。

图 4. 在启用 eXtremeMemory 时的传输方法
图 4. 在启用 eXtremeMemory 时的传输方法

结果

IBM eXtremeMemory 和 eXtremeIO 将垃圾收集对超过 80% 的 WebSphere eXtreme Scale 响应时间的影响降到了最低。eXtremeMemory 显著减小了 eXtreme Scale 容器 JVM 的堆大小,因为 Java 堆不再是弹性数据网格内存的主要存储机制。通过显著减小堆大小,可以显著缩短垃圾收集暂停时间。启用 eXtremeMemory 之后,垃圾收集不再参与弹性数据网格内存的管理。图 5 显示了与图 1 中相同的测试配置的结果,但这一次启用了 eXtremeMemory。结果显示响应时间一致性超过了 90%。

图 5. 90% 的响应时间小于 5 毫秒
图 5. 90% 的响应时间小于 5 毫秒

细节

要启用 eXtremeMemory 功能,只需将 enableXM=true 添加到 objectgrid.xml 文件中。此外,还可添加 maxXMSize=xxxx,其中 xxxx 以 MB 为单位,支持您设置可用于 eXtremeMemory 的最大内存大小。如果未配置这个 maxXMSize,eXtremeMemory 最大内存大小默认为系统内存的 25%。

eXtremeMemory 目前仅支持使用 64 位 Java 的 x86 64 位 Linux® 系统。当启用 eXtremeMemory 时,映射集中的所有映射必须使用 WebSphere eXtreme Scale 优化 COPY_TO_BYTES 或 COPY_TO_BYTES_RAW 复制模式。

eXtremeMemory 仅支持独立配置中的 WebSphere eXtreme Scale 容器。不支持在 IBM WebSphere Application Server 进程中运行的 WebSphere eXtreme Scale 容器服务器。此外,当需要以下 WebSphere eXtreme Scale 功能时,不推荐或支持 eXtremeMemory:

  • 自定义 evictor 插件。
  • 复合索引。
  • 内置的写入隐藏加载器。
  • 用于为处于复制模式下的客户端映射创建事件监听器实现的 ReplicationMapListener 接口。

结束语

IBM eXtremeMemory 和 IBM eXtremeIO 扩展了 WebSphere eXtreme Scale 的功能,以利用 Java 堆外部的系统内存作为弹性缓存。它减少了垃圾收集对高达 90% 的响应时间变化的影响。eXtremeMemory 仅为总体事务响应时间增加了极小的开销。对于具有很高时效性的业务流程,在甚至极细微的响应时间变化都无法接受时,eXtremeMemory 是一个解决方案。

参考资料

学习

获得产品和技术

讨论

条评论

developerWorks: 登录

标有星(*)号的字段是必填字段。


需要一个 IBM ID?
忘记 IBM ID?


忘记密码?
更改您的密码

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件

 


这是您第一次登陆到 developerWorks,已经自动为您创建了您的概要文件。 选择您概要文件中可以公开的信息的信息(如姓名、国家/地区,以及公司),这些信息同时也会与您所发布的内容相关联。 您可以随时更新您的 IBM 账号。

所有提交的信息确保安全。

选择您的昵称



当您初次登录到 developerWorks 时,将会为您创建一份概要信息,您需要指定一个昵称。您的昵称将和您在 developerWorks 发布的内容显示在一起。

昵称长度在 3 至 31 个字符之间。 您的昵称在 developerWorks 社区中必须是唯一的,并且出于隐私保护的原因,不能是您的电子邮件地址。

标有星(*)号的字段是必填字段。

(昵称长度在 3 至 31 个字符之间)

单击提交则表示您同意developerWorks 的条款和条件。 查看条款和条件.

 


所有提交的信息确保安全。


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=10
Zone=WebSphere
ArticleID=835136
ArticleTitle=创新触手可及: 通过 IBM eXtremeMemory 实现超越 Java 堆的弹性缓存
publish-date=09132012