管理 Apache Geode

管理 Apache Geode 描述如何规划和实现与Apache Geode的管理，监视和故障排除相关的任务。

• Apache Geode管理和监控

  Apache Geode提供用于管理集群和监视集群成员运行状况的API和工具。

• 管理堆和堆外内存

  默认情况下，Apache Geode使用JVM堆。 Apache Geode还提供了一种从堆中存储数据的选项。 本节介绍如何管理堆和堆外内存以最好地支持您的应用程序。

• 磁盘存储

  使用Apache Geode磁盘存储，您可以将数据保存到磁盘，作为内存中副本的备份，并在内存使用过高时将数据溢出到磁盘。

• 缓存和区域快照

  快照允许您保存区域数据并在以后重新加载。 典型的用例是将数据从一个环境加载到另一个环境，例如从生产系统捕获数据并将其移动到较小的QA或开发系统中。

• 区域压缩

  本节介绍区域压缩，其优点和用法。

• 网络分区

  Apache Geode体系结构和管理功能有助于检测和解决网络分区问题。

• 安全

  安全框架通过在连接时验证组件和成员来建立信任。 它有助于操作的授权。

• 性能调整和配置

  一组工具和控件允许您监视和调整Apache Geode性能。

• 日志

  全面的日志消息可帮助您确认配置和代码中的系统配置和调试问题。

• 统计

  集群中的每个应用程序和服务器都可以访问有关Apache Geode操作的统计数据。 您可以使用gfsh的alter runtime命令或gemfire.properties文件来配置统计信息的收集，以便于系统分析和故障排除。

• 故障排除和系统恢复

  本节提供了处理常见错误和故障情况的策略。

Apache Geode管理和监控

Apache Geode提供用于管理集群和监控成员运行状况的API和工具。

• 管理和监控功能

  Apache Geode使用联合Open Open MBean策略来管理和监视集群的所有成员。 此策略为您提供集群的统一单代理视图。

• Geode管理和监控工具概述

  Geode提供了各种管理工具，可用于管理Geode集群。

• 架构和组件

  Geode的管理和监视系统由一个JMX Manager节点(应该只有一个)和一个集群中的一个或多个受管节点组成。 集群中的所有成员都可通过MBean和Geode Management Service API进行管理。

• JMX管理器操作

  任何成员都可以托管嵌入式JMX Manager，它提供集群的所有MBean的联合视图。 通过在ManagementService上调用相应的API调用，可以将成员配置为在启动时或在其生命中的任何时间成为管理器。

• 联合MBean架构

  Geode使用MBean来管理和监控Geode的不同部分。 Geode的联合MBean架构是可扩展的，允许您拥有Geode集群的单代理视图。

• 配置RMI注册表端口和RMI连接器

  Geode以编程方式模拟Java提供的开箱即用的JMX，并在所有可管理成员上创建带有RMI Registry和RMI Connector端口的JMXServiceURL。

• 通过Management API执行gfsh命令

  您还可以使用管理API以编程方式执行gfsh命令。

管理和监控功能

Apache Geode使用联合Open Open MBean策略来管理和监视集群的所有成员。 此策略为您提供集群的统一单代理视图。

应用程序和管理器开发更容易，因为您不必在MBean上找到正确的MBeanServer来发出请求。 相反，您与单个MBeanServer交互，该MBeanServer从所有其他本地和远程MBeanServers聚合MBean。

Geode管理架构的其他一些关键优势和特性：

• Geode监控紧密集成到Geode的流程中，而不是在单独安装和配置的监控代理中运行。 您可以使用相同的框架来实际管理Geode并执行管理操作，而不仅仅是监控它。
• 所有Geode MBean都是MXBeans。 它们代表有关集群状态及其所有成员的有用且相关的信息。 由于MXBeans将Open MBean模型与预定义的一组类型一起使用，因此客户端和远程管理程序不再需要访问表示MBean类型的特定于模型的类。 使用MXBeans可以为您选择的客户端增加灵活性，并使Geode管理和监控更容易使用。
• 集群中的每个成员都可以通过MXBeans进行管理，每个成员在Platform MBeanServer中托管自己的MXBean。
• 可以将任何Geode成员配置为为Geode集群中的所有成员提供所有MXBean的联合视图。
• Geode还将JMX的使用修改为行业标准，并且对通用JMX客户端友好。 您现在可以使用任何符合JMX的第三方工具轻松监控或管理集群。 例如，JConsole。

参考

有关MXBeans和Open MBean的更多信息，请参阅：

• http://docs.oracle.com/javase/8/docs/api/javax/management/MXBean.html
• http://docs.oracle.com/javase/8/docs/api/javax/management/openmbean/package-summary.html

Geode管理和监控工具概述

Geode提供了各种管理工具，可用于管理Geode集群。

Geode管理和监视工具允许您配置集群的所有成员和进程，监视系统中的操作以及启动和停止成员。 在内部，Geode使用Java MBean（特别是MXBeans）来公开管理控件和监视功能。 您可以通过编写使用这些MXBeans的Java程序来监视和控制Geode，也可以使用Geode提供的几种工具之一来监视和管理您的集群。 这些任务的主要工具是gfsh命令行工具，如本节所述。

Geode提供以下工具来管理Geode安装：

gfsh命令行工具

gfsh命令行工具提供了一组用于配置，管理和监视集群的命令。 gfsh是管理集群的推荐工具。

使用gfsh：

• 启动和停止Geode进程，例如定位器和缓存服务器
• 部署应用程序
• 创建和销毁区域
• 执行函数
• 管理磁盘存储
• 导入和导出数据
• 监控Geode流程
• 启动Geode监控工具
• 关闭集群
• 编写涉及Geode成员的各种操作
• 保存集群的所有成员的配置

gfsh在它自己的shell中运行，或者你可以直接从OS命令行执行gfsh命令。 gfsh可以与远程系统交互使用http协议。 您还可以编写在gfsh shell中运行的脚本以自动启动系统。

您可以使用gfsh为集群创建共享集群配置。 您可以定义适用于整个集群的配置，或仅适用于类似组的配置

架构和组件

Geode的管理和监视系统由一个JMX Manager节点(应该只有一个)和一个集群中的一个或多个受管节点组成。 集群中的所有成员都可通过MBean和Geode Management Service API进行管理。

架构

下图描绘了管理和监视系统组件的体系结构。

在这个架构中，每个Geode成员都是可管理的。 本地Geode进程的所有Geode MBean都自动注册在Platform MBeanServer（托管平台MXBeans的每个JVM的默认MBeanServer）中。

受管节点

群集的每个成员都是一个受管节点。 当前未同时充当JMX Manager节点的任何节点都简称为受管节点。 受管节点具有以下资源，因此它可以在本地和远程回答JMX查询：

• 代表节点上本地监视的组件的本地MXBean。 请参阅Geode JMX MBean列表，以获取受管节点现有的可能MXBean列表。
• 内置平台MBeans。

JMX Manager Node

JMX Manager节点是可以管理其他Geode成员（即其他受管节点）以及自身的成员。 JMX Manager节点可以管理集群中的所有其他成员。

要将受管节点转换为JMX Manager节点，请在gemfire.properties文件中配置Geode属性jmx-manager = true，并将该成员作为JMX Manager节点启动。

当您将-J=-Dgemfire.jmx-manager=true作为start server或start locator命令的参数提供时，可以将该成员作为JMX Manager节点启动。 有关详细信息，请参阅启动JMX Manager。

JMX Manager节点分配了以下额外资源，以便它可以回答JMX查询：

• RMI连接器，允许JMX客户端连接并访问集群中的所有MXBean。
• Local MXBean，表示此节点上本地监视的组件，与任何其他受管节点相同。
• Aggregate MXBeans:
  • DistributedSystemMXBean
  • DistributedRegionMXBean
  • DistributedLockServiceMXBean
• 具有Scope=ALL的ManagerMXBean，它允许各种集群范围的操作。
• 受管节点上的MXBeans代理。
• 内置平台MXBeans。

JMX集成

管理和监视工具(如gfsh命令行界面和Pulse)使用JMX/RMI作为连接到Geode节点的通信层。 默认情况下，所有Geode进程都允许从localhost到Platform MBeanServer的JMX连接。 默认情况下，受管节点和JMX管理器节点都启用了RMI连接器以允许JMX客户端连接。

JConsole（以及支持Sun的Attach API的其他类似JMX客户端）可以通过使用Attach API连接到任何本地JVM，而无需RMI连接器。 这允许来自同一台机器的连接。

如果JVM配置为启动RMI连接器，则JConsole（和其他JMX客户端）可以连接到任何JVM。 这允许来自其他机器的远程连接。

JConsole可以连接到任何Geode成员，但如果它连接到非JMX-Manager成员，则JConsole仅检测节点的本地MBean，而不检测集群的MBean。

当Geode定位器或服务器成为集群的JMX Manager时，它将启用RMI连接器。 然后，JConsole只能连接到那个JVM，以查看整个集群的MBean。 它不需要连接到所有其他JVM。 Geode管理提供集群中所有MBean的联合视图所需的JVM间通信。

gfsh只能连接到JMX Manager或定位器。 如果连接到定位器，定位器将为现有JMX Manager提供必要的连接信息。 如果定位器检测到JMX Manager尚未在集群中运行，则定位器使自己成为JMX Manager。 gfsh无法连接到其他非Manager或非定位器成员。

有关如何配置RMI注册表和RMI连接器的信息，请参阅配置RMI注册表端口和RMI连接器。

管理API

Geode管理API代表JMX用户的Geode集群。 但是，它们不提供JMX中存在的功能。 它们仅为Geode监控和管理提供的各种服务提供网关。

Geode管理的入口点是通过ManagementService接口。 例如，要创建Management Service的实例：

ManagementService service = ManagementService.getManagementService(cache);

生成的ManagementService实例特定于提供的缓存及其集群。 getManagementService的实现现在是一个单例，但最终可能支持多个缓存实例。

您可以使用Geode管理API来完成以下任务：

• 监控客户端的健康状态。
• 获取单个磁盘备份的状态和结果。
• 查看与特定成员的磁盘使用情况和性能相关的指标。
• 浏览为特定成员设置的Geode属性。
• 查看JVM指标，例如内存，堆和线程使用情况。
• 查看网络指标，例如接收和发送的字节数。
• 查看分区区域属性，例如存储区总数，冗余副本和最大内存信息。
• 查看持久成员信息，例如磁盘存储区ID。
• 浏览区域属性。

请参阅org.apache.geode.managementJavaDocs获得更多细节。

您还可以使用ManagementService API执行gfsh命令。 请参阅通过Management API执行gfsh命令和org.apache.geode.management.cli的JavaDocs。

Geode管理和监控工具

本节列出了当前可用于管理和监控Geode的工具：

• gfsh. Apache Geode命令行界面，提供简单而强大的命令shell，支持Geode应用程序的管理，调试和部署。 它具有上下文相关帮助，脚本以及使用简单API从应用程序内调用任何命令的功能。 见gfsh。
• Geode Pulse. 易于使用的基于浏览器的仪表板，用于监控Geode部署。 Geode Pulse提供集群中所有Geode成员的集成视图。 请参阅Geode Pulse。
• Pulse Data Browser. 此Geode Pulse实用程序提供了一个图形界面，用于在Geode集群中执行OQL即席查询。 请参阅数据浏览器。
• Other Java Monitoring Tools such as JConsole and jvisualvm.JConsole是Java 2平台中提供的基于JMX的管理和监视工具，它提供有关Java应用程序的性能和资源消耗的信息。 请参阅http://docs.oracle.com/javase/6/docs/technotes/guides/management/jconsole.html。 Java VisualVM (jvisualvm) 是一个用于分析Java虚拟机的分析工具。 Java VisualVM对Java应用程序开发人员有用，可以对应用程序进行故障排除，并监视和改进应用程序的性能。 Java VisualVM可以允许开发人员生成和分析堆转储，跟踪内存泄漏，执行和监视垃圾收集，以及执行轻量级内存和CPU分析。 有关使用jvisualvm的更多详细信息，请参阅http://docs.oracle.com/javase/6/docs/technotes/tools/share/jvisualvm.html。

JMX管理器操作

任何成员都可以托管嵌入式JMX Manager，它提供集群的所有MBean的联合视图。 通过在ManagementService上调用相应的API调用，可以将成员配置为在启动时或在其生命中的任何时间成为管理器。

您需要在集群中启动JMX Manager才能使用Geode管理和监视工具，例如gfsh 和Geode Pulse。

注意: 充当JMX Manager的每个节点都有额外的内存要求，具体取决于它管理和监视的资源数量。 作为JMX Manager可以增加任何进程的内存占用，包括定位器进程。 有关计算Geode进程内存开销的更多信息，请参阅缓存数据的内存要求。

• 启动一个 JMX Manager
• 配置一个 JMX Manager
• 停止一个 JMX Manager

启动一个 JMX Manager

JMX Manager节点是管理其他Geode成员（以及他们自己）的成员。 JMX Manager节点可以管理集群中的所有其他成员。 通常，定位器将用作JMX Manager，但您也可以将任何其他成员（如服务器）转换为JMX Manager节点。

要允许服务器成为JMX Manager，请在服务器的gemfire.properties文件中配置Geode属性jmx-manager=true。 此属性将节点配置为被动地成为JMX Manager节点; 如果gfsh在连接到集群时找不到JMX Manager，则服务器节点将作为JMX Manager节点启动。

注意: 所有定位器的默认属性设置是gemfire.jmx-manager=true。 对于其他成员，默认属性设置为gemfire.jmx-manager=false。

要在服务器启动时强制服务器成为JMX Manager节点，请在服务器的gemfire.properties文件中设置Geode属性jmx-manager-start=true和jmx-manager=true。 请注意，对于节点，必须将这两个属性都设置为true。

要在命令行上将成员作为JMX Manager节点启动，请提供-J=-Dgemfire.jmx-manager-start =true和-J=-Dgemfire.jmx-manager=true作为参数。 start server或`start locator’命令。

例如，要在gfsh命令行上将服务器作为JMX Manager启动：

gfsh>start server --name=<server-name> --J=-Dgemfire.jmx-manager=true \
--J=-Dgemfire.jmx-manager-start=true

默认情况下，任何定位器在启动时都可以成为JMX Manager。 启动定位器时，如果集群中未检测到其他JMX Manager，则定位器会自动启动定位器。 如果启动第二个定位器，它将检测当前的JMX Manager，并且不会启动另一个JMX Manager，除非第二个定位器的gemfire.jmx-manager-start属性设置为true。

对于大多数部署，每个集群只需要一个JMX Manager。 但是，如有必要，您可以运行多个JMX Manager。 如果要为Pulse监视工具提供高可用性和冗余，或者运行除gfsh之外的其他JMX客户端，则使用jmx-manager-start = true属性强制单个节点(定位器或服务器)成为JMX管理器在启动时。 由于作为JMX Manager存在一些性能开销，我们建议使用定位器作为JMX Manager。 如果您不希望定位器成为JMX管理器，则在启动定位器时必须使用jmx-manager = false属性。

节点成为JMX Manager后，将应用配置JMX Manager中列出的所有其他jmx-manager- *配置属性。

以下是启动新定位器也启动嵌入式JMX Manager的示例（在检测到另一个JMX Manager不存在之后）。 此外，gfsh还会自动将您连接到新的JMX Manager。 例如：

gfsh>start locator --name=locator1
Starting a Geode Locator in /Users/username/apache-geode/locator1...
....
Locator in /Users/username/apache-geode/locator1 on 192.0.2.0[10334] as locator1
is currently online.
Process ID: 27144
Uptime: 5 seconds
Geode Version: 1.7
Java Version: 1.8.0_121
Log File: /Users/username/apache-geode/locator1/locator1.log
JVM Arguments: -Dgemfire.enable-cluster-configuration=true 
-Dgemfire.load-cluster-configuration-from-dir=false 
-Dgemfire.launcher.registerSignalHandlers=true 
-Djava.awt.headless=true -Dsun.rmi.dgc.server.gcInterval=9223372036854775806
Class-Path: /Users/username/apache-geode/lib/geode-core-1.2.0.jar
:/Users/username/apache-geode/lib/geode-dependencies.jar
Successfully connected to: JMX Manager [host=192.0.2.0, port=1099]
Cluster configuration service is up and running.

定位器还跟踪可以成为JMX Manager的所有节点。

创建缓存后，JMX Manager节点立即开始从其他成员联合MBean。 JMX Manager节点准备就绪后，JMX Manager节点会向所有其他成员发送通知，通知他们它是新的JMX Manager。 然后其他成员将完整的MBean状态放入每个隐藏的管理区域。

在任何时候，您都可以使用MemberMXBean.isManager()方法确定节点是否为JMX Manager。

使用Java API，任何使用jmx-manager=true配置的受管节点也可以通过调用ManagementService.startManager()方法转换为JMX Manager节点。

注意: 如果以编程方式启动JMX Manager并希望启用命令处理，则还必须将gfsh-dependencies.jar的绝对路径(位于安装的lib目录中)添加到应用程序的CLASSPATH。 不要将此库复制到CLASSPATH，因为此库通过相对路径引用lib中的其他依赖项。

配置一个 JMX Manager

在gemfire.properties文件中，您可以按如下方式配置JMX管理器。

停止一个 JMX管理器

要使用gfsh停止JMX Manager，只需关闭托管JMX Manager的定位器或服务器即可。

对于定位器：

gfsh>stop locator --dir=locator1
Stopping Locator running in /home/user/test2/locator1 on ubuntu.local[10334] as locator1...
Process ID: 2081
Log File: /home/user/test2/locator1/locator1.log
....
No longer connected to ubuntu.local[1099].

对于服务器：

gfsh>stop server --dir=server1
Stopping Cache Server running in /home/user/test2/server1 ubuntu.local[40404] as server1...
Process ID: 1156
Log File: /home/user/test2/server1/server1.log
....
No longer connected to ubuntu.local[1099].

请注意，gfsh已自动断开您与已停止的JMX Manager的连接。

要使用管理API停止JMX管理器，请使用ManagementService.stopManager()方法阻止成员成为JMX Manager。

当Manager停止时，它会从其Platform MBeanServer中删除其他成员的所有联合MBean。 它还会发出通知，通知其他成员它不再被视为JMX Manager。

联邦MBean架构

Geode使用MBean来管理和监控Geode的不同部分。 Geode的联合MBean架构是可扩展的，允许您拥有Geode集群的单代理视图。

Geode MBean和MBeanServers的联合

MBeanServers的联合意味着一个成员JMX Manager Node可以提供MBeanServer托管的所有MBean的代理视图。 联合还意味着操作和通知分布在集群中。

Geode federation负责以下功能：

• MBean代理创建
• MBean状态传播
• 通知传播
• 操作调用

MBean代理命名约定

每个Geode MBean都遵循特定的命名约定，以便于分组。 例如：

GemFire:type=Member,service=LockService,name=<dlsName>,memberName=<memberName>

在JMX Manager节点上，此MBean将作为域注册到GemFire / 。

以下是一些示例MBean名称：

MemberMBean:

GemFire:type=Member,member=<Node1>

使用MXBeans

在其管理API中，Geode提供MXBeans以确保任何客户端（包括远程客户端）都可以使用所创建的任何MBean，而无需客户端访问特定类以访问MBean的内容。

MBean代理创建

Geode代理本质上是本地MBean。 每个Geode JMX管理器成员都托管指向每个受管节点的本地MBean的代理。 当在该受管节点中发生事件时，代理MBean还将发出受管节点中本地MBean发出的任何通知。

注意: JMX Manager节点上的聚合MBean未被代理。

Geode JMX MBean列表

本主题提供了Geode中可用的各种管理和监视MBean的说明。

下图说明了为管理和监视Apache Geode而开发的不同JMX MBean之间的关系。

• JMX Manager MBeans

  本节介绍JMX Manager节点上可用的MBean。

• Managed Node MBeans

  本节介绍所有受管节点上可用的MBean。

JMX Manager MBeans

本节介绍JMX Manager节点上可用的MBean。

JMX Manager节点包括Managed Node MBeans下列出的所有本地bean以及仅可用的以下bean 在JMX Manager节点上：

• ManagerMXBean
• DistributedSystemMXBean
• DistributedRegionMXBean
• DistributedLockServiceMXBean

ManagerMXBean

表示托管成员的Geode Management层。 控制管理范围。 此MBean提供start和stop方法，以将受管节点转换为JMX Manager节点或停止节点成为JMX Manager。 对于潜在的管理者(jmx-manager=true和jmx-manager-start=false)，这个MBean是在Locator请求时创建的。

注意: 您必须配置节点以允许它成为JMX Manager。 有关配置信息，请参阅配置JMX Manager。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.ManagerMXBean JavaDocs。

DistributedSystemMXBean

系统范围的聚合MBean，提供整个集群的高级视图，包括所有成员(缓存服务器，对等方，定位器)及其缓存。 在任何给定的时间点，它都可以提供完整集群及其操作的快照。

DistributedSystemMXBean提供用于执行集群范围操作的API，例如备份所有成员，关闭所有成员或显示各种集群指标。

您可以将标准JMX NotificationListener附加到此MBean以侦听整个集群中的通知。 有关详细信息，请参阅Geode JMX MBean通知。

这个MBean还提供了一些MBean模型导航APIS。 应使用这些API来浏览Geode系统公开的所有MBean。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.DistributedSystemMXBean JavaDocs。

DistributedRegionMXBean

系统范围的命名区域的聚合MBean。 它为托管和/或使用该区域的所有成员提供了一个区域的高级视图。 例如，您可以获取托管该区域的所有成员的列表。 某些方法仅适用于分区区域。

MBean Details

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.DistributedRegionMXBean JavaDocs。

DistributedLockServiceMXBean

表示DistributedLockService的命名实例。 可以在成员中创建任意数量的DistributedLockService。

DistributedLockService的命名实例定义了一个空间，用于锁定由指定分发管理器定义的集群中的任意名称。 可以使用不同的服务名称创建任意数量的DistributedLockService实例。 对于集群中已创建具有相同名称的DistributedLockService实例的所有进程，在任何时间点，只允许一个线程拥有该实例中给定名称的锁。 此外，线程可以锁定整个服务，从而防止系统中的任何其他线程锁定服务或服务中的任何名称。

MBean Details

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.DistributedLockServiceMXBean JavaDocs。

受管节点MBean

本节介绍所有受管节点上可用的MBean。

所有受管节点上可用的MBean包括：

• MemberMXBean
• CacheServerMXBean
• RegionMXBean
• LockServiceMXBean
• DiskStoreMXBean
• AsyncEventQueueMXBean
• LocatorMXBean
• LuceneServiceMXBean

JMX Manager节点将自己拥有受管节点MBean，因为它们也是集群中的可管理实体。

MemberMXBean

成员对其连接和缓存的本地视图。 它是管理特定成员的主要网关。 它公开了成员级属性和统计信息。 像createCacheServer()和createManager()这样的操作将有助于创建一些Geode资源。 任何JMX客户端都可以连接到MBean服务器，并使用此MBean开始管理Geode成员。

See MemberMXBean Notifications for a list of notifications emitted by this MBean.

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.MemberMXBean JavaDocs。

CacheServerMXBean

表示Geode CacheServer。 提供有关服务器，订阅，持久队列和索引的数据和通知。

有关此MBean发出的通知的列表，请参阅CacheServerMXBean Notifications。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.CacheServerMXBean JavaDocs。

RegionMXBean

成员局部区域的视角。

MBean Details

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.RegionMXBean JavaDocs。

LockServiceMXBean

表示LockService的命名实例。 可以在成员中创建任意数量的LockServices。

MBean Details

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.LockServiceMXBean JavaDocs。

DiskStoreMXBean

表示为一个或多个区域提供磁盘存储的DiskStore对象

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.DiskStoreMXBean JavaDocs。

AsyncEventQueueMXBean

AsyncEventQueueMXBean提供对AsyncEventQueue的访问，AsyncEventQueue表示将事件传递到AsyncEventListener的通道。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.AsyncEventQueueMXBean JavaDocs。

LocatorMXBean

LocatorMXBean表示定位器。

MBean Details

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.LocatorMXBean JavaDocs。

LuceneServiceMXBean

成员对现有Lucene索引的本地视图。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.cache.lucene.management.LuceneServiceMXBean JavaDocs。

GatewaySenderMXBean

GatewaySenderMXBean表示网关发件人。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.GatewaySenderMXBean JavaDocs。

GatewayReceiverMXBean

GatewayReceiverMXBean表示网关接收器。

MBean 细节

有关可用MBean方法和属性的信息，请参阅org.apache.geode.management.GatewayReceiverMXBean JavaDocs。

通过JConsole浏览Geode MBean

您可以使用JConsole浏览集群中的所有Geode MBean。

要通过JConsole查看Geode MBean，请执行以下步骤：

1. 启动gfsh提示符。

2. 通过使用嵌入式JMX Manager连接到定位器或直接连接到JMX Manager，连接到正在运行的集群。 例如：

   gfsh>connect --locator=locator1[10334]

   或者

   gfsh>connect --jmx-manager=locator1[1099]

3. 启动 JConsole:

   gfsh>start jconsole

   如果成功，将显示“正在运行JDK JConsole”消息。 JConsole应用程序使用RMI直接启动并连接到JMX Manager。

4. 在JConsole屏幕上，单击MBeans选项卡。 展开GemFire。 然后展开每个MBean以浏览各个MBean属性，操作和通知。

   以下是Geode集群中MBean层次结构的示例屏幕截图：

   

Geode JMX MBean通知

Apache Geode MBean在发生特定事件或Geode系统中引发警报时发出通知。 使用标准JMX API，用户可以添加通知处理程序来侦听这些事件。

• 通知联邦

  从受管节点发出的所有通知都将联合到系统中的所有JMX Manager。

• JMX MBean通知列表

  本主题列出了Geode MBeans发出的所有可用JMX通知。

通知联邦

从受管节点发出的所有通知都将联合到系统中的所有JMX Manager。

这些通知是联合的，然后由DistributedSystemMXBean发出。 如果将javax.management.NotificationListener附加到DistributedSystemMXBean，NotificationListener可以侦听来自所有MemberMXBeans和所有CacheServerMXBeans的通知。

将监听器附加到MXBeans

将通知侦听器附加到DistributedSystemMXBean时，DistributedSystemMXBean将充当整个集群的通知中心。 您不必将侦听器附加到每个单独的成员或缓存服务器MBean，以便侦听集群中的所有通知。

以下是使用JMX MBeanServer API将NotificationListener附加到MBean的示例：

NotificationListener myListener = ...
ObjectName mbeanName = ... 
MBeanServer.addNotificationListener(mbeanName, myListener, null, null);

JMX Manager将为所有集群成员发出通知，但有两个例外：

• 如果使用cache.xml定义区域和磁盘等资源，则这些资源的通知不会联合到JMX Manager。 在这些情况下，DistributedSystemMXBean无法发出这些通知。
• 如果在创建资源后启动JMX Manager，则JMX Manager无法为该资源发出通知。

系统警报通知

系统警报是包含在JMX通知中的Geode警报。 JMX Manager将自身注册为系统中每个成员的警报侦听器，默认情况下，它会接收集群中任何节点使用SEVERE警报级别记录的所有消息。 因此，DistributedSystemMXBean将代表DistributedSystem发出这些警报的通知。

默认情况下，JMX Manager会自行注册以仅为SEVERE级别警报发送通知。 要更改JMX Manager将发送通知的警报级别，请使用DistributedMXBean.changeAlertLevel方法。 可设置的警报级别为WARNING，ERROR，SEVERE和NONE。 更改级别后，JMX Manager将仅发出该级别的日志消息作为通知。

通知对象包括类型，源和消息属性。 系统警报还包括userData属性。 对于系统警报，通知对象属性对应于以下内容：

• type: system.alert
• source: Distributed System ID
• message: alert message
• userData: name or ID of the member that raised the alert

JMX MBean通知列表

本主题列出了Geode MBeans发出的所有可用JMX通知。

通知由以下MBean发出：

• MemberMXBean 通知
• MemberMXBean Gateway 通知
• CacheServerMXBean 通知
• DistributedSystemMXBean 通知

MemberMXBean 通知

MemberMXBean Gateway 通知

CacheServerMXBean 通知

DistributedSystemMXBean 通知

配置RMI注册表端口和RMI连接器

Geode以编程方式模拟Java提供的开箱即用的JMX，并在所有可管理成员上创建带有RMI Registry和RMI Connector端口的JMXServiceURL。

配置JMX Manager端口和绑定地址

您可以在启动将承载Geode JMX Manager的进程时配置特定的连接端口和地址。 为此，请指定jmx-manager-bind-address的值，它指定JMX管理器的IP地址和jmx-manager-port，它定义了RMI连接端口。

默认的Geode JMX Manager RMI端口为1099.如果保留1099用于其他用途，则可能需要修改此默认值。

使用开箱即用的RMI连接器

如果由于某种原因需要在部署中使用标准JMX RMI用于其他监视目的，请在要使用标准JMX RMI的任何成员上将Geode属性jmx-manager-port设置为0。

如果您使用开箱即用的JMX RMI而不是启动嵌入式Geode JMX Manager，则在为客户应用程序启动JVM时应考虑设置-Dsun.rmi.dgc.server.gcInterval = Long.MAX_VALUE-1 和客户进程。 每个Geode进程在创建和启动JMX RMI连接器之前在内部设置此设置，以防止暂停进程完全垃圾回收。

通过Management API执行gfsh命令

您还可以使用管理API以编程方式执行gfsh命令。

注意: 如果以编程方式启动JMX Manager并希望启用命令处理，则还必须将gfsh-dependencies.jar的绝对路径(位于Geode安装的$ GEMFIRE/lib中)添加到应用程序的CLASSPATH中。 不要将此库复制到CLASSPATH，因为此库通过相对路径引用$ GEMFIRE/lib中的其他依赖项。 以下代码示例演示了如何使用Java API处理和执行gfsh命令。

首先，检索CommandService实例。

注意: CommandService API目前仅在JMX Manager节点上可用。

// Get existing CommandService instance or create new if it doesn't exist
commandService = CommandService.createLocalCommandService(cache);
// OR simply get CommandService instance if it exists, don't create new one
CommandService commandService = CommandService.getUsableLocalCommandService();

接下来，处理命令及其输出：

// Process the user specified command String
Result regionListResult = commandService.processCommand("list regions");
// Iterate through Command Result in String form line by line
while (regionListResult.hasNextLine()) {
   System.out.println(regionListResult.nextLine());
}

或者，您可以从命令字符串创建一个可以重复使用的CommandStatement对象，而不是处理该命令。

// Create a command statement that can be reused multiple times
CommandStatement showDeadLocksCmdStmt = commandService.createCommandStatement
    ("show dead-locks --file=deadlock-info.txt");
Result showDeadlocksResult = showDeadLocksCmdStmt.process();
// If there is a file as a part of Command Result, it can be saved 
// to a specified directory
if (showDeadlocksResult.hasIncomingFiles()) {
    showDeadlocksResult.saveIncomingFiles(System.getProperty("user.dir") + 
                  "/commandresults");
}

管理堆和堆外内存

默认情况下，Apache Geode使用JVM堆。 Apache Geode还提供了一种从堆中存储数据的选项。 本节介绍如何管理堆和堆外内存以最好地支持您的应用程序。

调整JVM垃圾收集参数

由于Apache Geode专门用于处理内存中保存的数据，因此您可以通过调整Apache Geode使用JVM堆的方式来优化应用程序的性能。

有关可用于改进垃圾回收(GC)响应的所有特定于JVM的设置，请参阅JVM文档。 至少，请执行以下操作：

1. 将初始和最大堆开关-Xms和-Xmx设置为相同的值。 gfsh start server选项--initial-heap和--max-heap实现了相同的目的，增加了提供资源管理器默认值的值，例如逐出阈值和临界阈值。
2. 配置JVM以进行并发标记清除(CMS)垃圾回收。
3. 如果您的JVM允许，请将其配置为在堆使用率比资源管理器“eviction-heap-percentage”的设置低至少10％时启动CMS收集。 您希望收集器在Geode驱逐或驱逐不会产生更多空闲内存时工作。 例如，如果eviction-heap-percentage设置为65，则将堆垃圾收集设置为在堆使用率不高于55％时启动。

对于gfsh start server命令，使用--J开关传递这些设置，例如：‑‑J=‑XX:+UseConcMarkSweepGC。

以下是为应用程序设置JVM的示例：

$ java app.MyApplication -Xms=30m -Xmx=30m -XX:+UseConcMarkSweepGC -XX:CMSInitiatingOccupancyFraction=60

注意: 启动服务器时，请勿使用-XX:+UseCompressedStrings和-XX:+UseStringCache JVM配置属性。 这些JVM选项可能会导致数据损坏和兼容性问题。

或者，使用gfsh：

$ gfsh start server --name=app.MyApplication --initial-heap=30m --max-heap=30m \
--J=-XX:+UseConcMarkSweepGC --J=-XX:CMSInitiatingOccupancyFraction=60

使用Geode资源管理器

Geode资源管理器与您的JVM终身垃圾收集器一起使用，以控制堆使用并保护您的成员免受因内存过载而导致的挂起和崩溃。

Geode资源管理器通过驱逐旧数据来防止缓存占用过多内存。 如果垃圾收集器无法跟上，则资源管理器会拒绝添加到缓存，直到收集器释放了足够的内存。

资源管理器有两个阈值设置，每个设置表示为总终端堆的百分比。 两者都默认禁用。

1. Eviction Threshold(驱逐阈值). 在此之上，管理器命令所有区域的驱逐，其中eviction-attributes设置为lru-heap-percentage。 这会提示专用的后台驱逐，独立于任何应用程序线程，它还告诉所有应用程序线程向区域添加数据以驱逐至少与添加的数据一样多的数据。 JVM垃圾收集器删除已逐出的数据，减少堆使用。 该驱逐继续下去，直到管理器确定堆的使用是再次跌破驱逐阈值。

   资源管理器仅对LRU驱逐策略基于堆百分比的区域强制执行驱逐阈值。 基于条目计数或存储器大小的驱逐策略的区域使用其他机制来管理驱逐。 有关驱逐政策的更多详细信息，请参阅驱逐。

2. Critical Threshold(临界阈值). 在此之上，所有可能将数据添加到缓存的活动都将被拒绝。 该阈值设置在驱逐阈值之上，旨在使驱逐和GC工作赶上。 此JVM，集群中的所有其他JVM以及系统的所有客户端都会收到“LowMemoryException”，以查看是否会增加此关键成员的堆消耗。 允许获取或减少数据的活动。 有关拒绝操作的列表，请参阅ResourceManager方法setCriticalHeapPercentage的Javadoc。

   无论LRU驱逐策略如何，都会对所有区域强制执行临界阈值，但可以将其设置为零以禁用其效果。

当堆使用在任一方向上通过逐出阈值时，管理器记录信息级消息。

当堆使用超过临界阈值时，管理器会记录错误级别的消息。 避免超过临界阈值。 一旦被识别为关键，Geode成员将成为只读成员，拒绝其所有区域的缓存更新，包括传入的分布式更新。

有关更多信息，请参阅联机API文档中的org.apache.geode.cache.control.ResourceManager。

如何进行后台驱逐

当管理器开始驱逐时：

1. 从为本地缓存中为堆LRU驱逐配置的所有区域，后台驱逐管理器创建随机列表，其包含每个分区区域桶（主要或次要）的一个条目和每个非分区区域的一个条目。 因此，每个分区区域桶的处理方式与单个非分区区域相同。
2. 后台逐出管理器为本地计算机上的每个处理器启动四个逐出器线程。 管理器将每个线程传递给桶/区域列表的共享。 管理器通过计数尽可能均匀地划分桶/区域列表，而不是通过内存消耗。
3. 每个线程在其桶/区域列表上循环遍历，逐个每个桶/区域驱逐一个LRU条目，直到资源管理器发送信号以停止驱逐。

另请参见缓存数据的内存要求。

使用资源管理器控制堆使用

资源管理器行为与垃圾收集（GC）活动的触发，JVM中并发垃圾收集器的使用以及用于并发的并行GC线程数密切相关。

此处提供的使用管理器的建议假设您对Java VM的堆管理和垃圾收集服务有充分的了解。

资源管理器可用于任何Apache Geode成员，但您可能不希望在任何地方激活它。 对于某些成员而言，在挂起或OME崩溃后偶尔重启可能比驱逐数据和/或拒绝分布式缓存活动更好。 此外，没有冒险超出其内存限制的成员将无法从资源管理器消耗的开销中受益。 缓存服务器通常配置为使用管理器，因为它们通常承载更多数据并且具有比其他成员更多的数据活动，从而需要更高的数据清理和收集响应能力。

对于要激活资源管理器的成员：

1. 为堆LRU管理配置Geode。
2. 设置JVM GC调整参数以与Geode管理器一起处理堆和垃圾收集。
3. 监视和调整堆LRU配置和GC配置。
4. 在投入生产之前，请使用与目标系统近似的应用程序行为和数据加载来运行系统测试，以便您可以根据生产需要进行调整。
5. 在生产中，不断监控和调整以满足不断变化的需求。

配置堆用于LRU管理的Geode

这里使用的配置术语是cache.xml元素和属性，但您也可以通过gfsh和org.apache.geode.cache.control.ResourceManager和RegionAPIs进行配置。

1. 启动服务器时，将initial-heap和max-heap设置为相同的值。

2. 设置resource-manager和client-heap-percentage阈值。 这应该尽可能接近100，同时仍然足够低，以便管理者的响应可以防止成员挂起或得到’OutOfMemoryError`。 默认情况下，阈值为零（无阈值）。

   注意: 设置此阈值时，它还启用查询监视功能，以在执行查询或创建索引时防止大多数内存不足异常。 请参阅监视内存不足的查询。

3. 将resource-manager和eviction-heap-percentage阈值设置为低于临界阈值的值。 这应该尽可能高，同时仍然足够低，以防止您的成员达到临界阈值。 默认情况下，阈值为零（无阈值）。

4. 确定哪些区域将参与堆驱逐并将其eviction-attributes设置为“lru-heap-percentage”。 见Eviction。 您为驱逐配置的区域应具有足够的数据活动，以便驱逐有用，并且应包含应用程序可以删除或卸载到磁盘的数据。

gfsh的例子:

gfsh>start server --name=server1 --initial-heap=30m --max-heap=30m \
--critical-heap-percentage=80 --eviction-heap-percentage=60

cache.xml 例子:

<cache>
<region refid="REPLICATE_HEAP_LRU" />
...
<resource-manager critical-heap-percentage="80" eviction-heap-percentage="60"/>
</cache>

注意: resource-manager规范必须出现在cache.xml文件中的区域声明之后。

设置JVM GC调整参数

如果您的JVM允许，请将其配置为在堆使用率比资源管理器eviction-heap-percentage的设置低至少10％时启动并发标记清除（CMS）垃圾回收。 您希望收集器在Geode驱逐或驱逐不会产生更多空闲内存时工作。 例如，如果eviction-heap-percentage设置为65，则将堆垃圾收集设置为在堆使用率不高于55％时启动。

监视和调整堆LRU配置

在调整资源管理器时，您的中心焦点应该是使成员保持在临界阈值以下。 提供关键阈值是为了避免成员挂起和崩溃，但由于其分布式更新的异常抛出行为，在关键时间中花费的时间会对整个集群产生负面影响。 为了保持低于临界值，调整以便在达到驱逐阈值时Geode驱逐和JVM的GC充分响应。

使用JVM提供的统计信息确保您的内存和GC设置足以满足您的需求。

GeodeResourceManagerStats提供有关内存使用以及管理器阈值和逐出活动的信息。

如果您的应用程序定期高于临界阈值，请尝试降低逐出阈值。 如果应用程序永远不会接近关键，您可以提高驱逐阈值以获得更多可用内存，而不会产生不必要的驱逐或GC周期的开销。

适用于您的系统的设置取决于许多因素，包括：

• 您存储在缓存中的数据对象的大小: 可以驱逐非常大的数据对象并相对快速地收集垃圾。 许多小对象使用相同数量的空间需要更多的处理工作来清除，并且可能需要较低的阈值以允许驱逐和GC活动跟上。
• 应用行为: 快速将大量数据放入缓存的应用程序可以更轻松地超越驱逐和GC功能。 驱逐速度较慢的应用程序可能更容易通过驱逐和GC工作来抵消，可能允许您将阈值设置为高于更易变的系统。
• 您选择的JVM: 每个JVM都有自己的GC行为，这会影响收集器的运行效率，它在需要时的速度以及其他因素。

资源管理器示例配置

这些示例将临界阈值设置为终身堆的85％，并将驱逐阈值设置为75％。 区域bigDataStore被配置为参与资源管理器的驱逐活动。

• gfsh 例子:

  gfsh>start server --name=server1 --initial-heap=30m --max-heap=30m \
  --critical-heap-percentage=85 --eviction-heap-percentage=75

  gfsh>create region --name=bigDataStore --type=PARTITION_HEAP_LRU

• XML:

  <cache>
  <region name="bigDataStore" refid="PARTITION_HEAP_LRU"/>
  ...
  <resource-manager critical-heap-percentage="85" eviction-heap-percentage="75"/>
  </cache>

  注意: resource-manager规范必须出现在cache.xml文件中的区域声明之后。

• Java:

  Cache cache = CacheFactory.create();
  ResourceManager rm = cache.getResourceManager();
  rm.setCriticalHeapPercentage(85);
  rm.setEvictionHeapPercentage(75);
  RegionFactory rf =
    cache.createRegionFactory(RegionShortcut.PARTITION_HEAP_LRU);
    Region region = rf.create("bigDataStore");

用例示例代码

这是示例中使用的配置的一种可能方案：

• 在运行Linux的4 CPU系统上具有8 Gb堆空间的64位Java VM。
• 数据区bigDataStore有大约2-3百万个小值，平均条目大小为512字节。 因此，大约4-6 Gb的堆用于区域存储。
• 托管该区域的成员还运行可能需要最多1 Gb堆的应用程序。
• 应用程序必须永远不会耗尽堆空间并且已经精心设计，如果由于应用程序问题导致堆空间变得有限，则该区域中的数据丢失是可接受的，因此默认的“lru-heap-percentage”操作销毁是合适的。
• 应用程序的服务保证使其非常不能容忍OutOfMemoryException错误。 测试表明，当使用-XX:CMSInitiatingOccupancyFraction=70配置CMS垃圾收集器时，在向区域添加数据时，将15％的头部空间留在临界阈值之上可以获得99.5％的正常运行时间而没有“OutOfMemoryException”错误。

管理 Off-Heap 内存

可以将Geode配置为在堆外内存中存储区域值，该内存是JVM中不受Java垃圾回收影响的内存。

JVM中的垃圾收集（GC）可能会成为性能障碍。 服务器无法控制JVM堆内存中的垃圾收集何时发生，并且服务器几乎无法控制调用的触发器。 堆外内存将值卸载到不受Java GC约束的存储区域。 通过利用堆外存储，应用程序可以减少受GC开销影响的堆存储量。

堆外内存与堆一起使用，它不会替换它。 密钥存储在堆内存空间中。 Geode自己的内存管理器处理堆外内存的性能优于Java垃圾收集器对某些区域数据集的性能。

资源管理器监视堆外内存的内容，并根据两个类似于监视JVM堆的阈值调用内存管理操作：eviction-off-heap-percentage和critical-off-heap-percentage。

On-heap 和 Off-heap 对象

以下对象始终存储在JVM堆中：

• 区域元数据
• 条目元数据
• Keys
• 索引
• 订阅队列元素

以下对象可以存储在堆外内存中：

• 值 - 最大值大小为2GB
• 引用计数
• 可用内存块列表
• WAN队列元素

注意: 不要将函数范围索引与堆外数据一起使用，因为它们不受支持。 尝试这样做会产生异常。

Off-heap 建议

Off-heap 存储最适合数据模式，其中：

• 存储的值在大小上相对均匀
• 存储的值大多小于128K
• 使用模式涉及许多创建的循环，然后是销毁或清除
• 这些值不需要经常反序列化
• 许多值都是长寿命的参考数据

请注意，Geode必须执行额外的工作来访问存储在堆外内存中的数据，因为它以序列化形式存储。 这项额外的工作可能会导致某些用例在堆外配置中运行速度较慢，即使它们使用较少的内存并避免垃圾收集开销。 但是，即使进行额外的反序列化，堆外存储也可以为您提供最佳性能。 可能增加开销的功能包括

• 经常更新
• 存储的大小各不相同的值
• 增量
• 查询

实现细节

堆外存储器管理器有效地处理大小相同或具有固定大小的区域数据值。 在堆外内存中分配固定和相同大小的数据值时，通常可以重用已释放的块，并且很少或根本不需要将周期用于碎片整理。

即使该区域配置为使用堆外内存，小于或等于8个字节的区域值也不会驻留在堆外内存中。 这些非常小的区域值驻留在JVM堆中，而不是对堆外位置的引用。 此性能增强可节省空间和加载时间。

使用资源管理器控制堆外使用

Geode资源管理器通过两个阈值控制堆外内存，与JVM堆内存的方式大致相同。 请参阅使用Geode资源管理器。 资源管理器通过驱逐旧数据来防止缓存占用过多的堆外内存。 如果堆外内存管理器无法跟上，则资源管理器会拒绝添加到缓存，直到堆外内存管理器释放足够的内存。

资源管理器有两个阈值设置，每个设置表示为总堆外内存的百分比。 两者都默认禁用。

1. Eviction Threshold(驱逐阈值). 驱逐应该开始的堆外记忆的百分比。 驱逐继续，直到资源管理器确定堆外内存使用再次低于驱逐阈值。 使用eviction-off-heap-percentageregion属性设置逐出阈值。 资源管理器仅对具有HEAP_LRU特征的区域强制执行驱逐阈值。 如果临界阈值不为零，则默认逐出阈值比临界阈值低5％。 如果临界阈值为零，则默认逐出阈值为总堆外内存的80％。

   资源管理器仅对LRU驱逐策略基于堆百分比的区域强制执行驱逐阈值。 基于条目计数或存储器大小的驱逐策略的区域使用其他机制来管理驱逐。 有关驱逐政策的更多详细信息，请参阅驱逐。

2. Critical Threshold(临界阈值). 高速缓存存在无法操作风险的堆外内存百分比。 当缓存使用超过临界阈值时，将拒绝所有可能向缓存添加数据的活动。 任何会增加堆外内存消耗的操作都会抛出LowMemoryException而不是完成其操作。 使用critical-off-heap-percentage区域属性设置临界阈值。

   无论LRU驱逐策略如何，都会对所有区域强制执行临界阈值，但可以将其设置为零以禁用其效果。

指定堆外内存

要使用堆外内存，请在设置服务器和区域时指定以下选项：

• 按调整JVM的垃圾收集参数中的说明启动JVM。 特别是，将初始和最大堆大小设置为相同的值。 当您计划使用堆外内存时，小于32GB的大小是最佳选择。

• 从gfsh，启动每个服务器，它将支持非堆内存，并具有非零的“off-heap-memory-size”值，以兆字节(m)或千兆字节(g)为单位。 如果您计划使用资源管理器，请指定临界阈值，逐出阈值或（在大多数情况下）两者。

  例子:

  gfsh> start server --name=server1 -–initial-heap=10G -–max-heap=10G -–off-heap-memory-size=200G \
  -–lock-memory=true -–critical-off-heap-percentage=90 -–eviction-off-heap-percentage=80

• 通过将off-heapregion属性设置为true来标记其条目值应存储在堆外的区域。为托管同一区域的数据的所有成员统一配置其他区域属性。。

  例子:

  gfsh>create region --name=region1 --type=PARTITION_HEAP_LRU --off-heap=true

gfsh Off-heap支持

gfsh支持服务器和区域创建操作以及报告功能中的堆外内存：

alter disk-store --off-heap=(true | false) 重置指定区域的off-heap属性。 有关详细信息，请参阅alter disk-store。

create region --off-heap=(true | false)设置指定区域的off-heap属性。 有关详细信息，请参阅create region。

describe member 显示堆外大小

describe offline-disk-store 显示离线区域是否处于堆外

describe region 显示区域的堆外属性的值

show metrics 包括堆外指标 maxMemory, freeMemory, usedMemory, objects, fragmentation 和 defragmentationTime

start server 支持堆外选项--lock-memory，--off-heap-memory-size，--critical-off-heap-percentage和--eviction-off-heap-percentage请参阅 启动服务器了解详情。

资源管理 API

org.apache.geode.cache.control.ResourceManager接口定义了支持堆外使用的方法：

• public void setCriticalOffHeapPercentage(float Percentage)
• public float getCriticalOffHeapPercentage()
• public void setEvictionOffHeapPercentage(float Percentage)
• public float getEvictionOffHeapPercentage()

gemfire.properties文件支持一个堆外属性：

off-heap-memory-size 指定堆外内存的大小，以兆字节(m)或千兆字节(g)为单位。 例如：

off-heap-memory-size=4096m
off-heap-memory-size=120g

有关详细信息，请参阅gemfire.properties和gfsecurity.properties(Geode Properties)。

cache.xml文件支持一个区域属性：

off-heap(=true | false) Specifies that the region uses off-heap memory; defaults to false. For example:

<region-attributes
  off-heap="true">
</region-attributes>

有关详细信息，请参阅

cache.xml文件支持两个资源管理器属性：

critical-off-heap-percentage=value 指定堆外内存的百分比达到或超过其缓存中成为不可操作的危险，由于内存不足异常的考虑。 有关详细信息，请参阅。

eviction-off-heap-percentage=value 指定应该开始驱逐的堆外内存的百分比。 可以为任何区域设置，但仅在为HEAP_LRU驱逐配置的区域中主动运行。 有关详细信息，请参阅。

例如:

<cache>
...
   <resource-manager 
      critical-off-heap-percentage="99.9" 
      eviction-off-heap=-percentage="85"/>
...
</cache>

调整堆外内存使用情况

Geode收集有关堆外内存使用情况的统计信息，您可以使用gfshshow metrics命令查看。 有关可用的堆外统计信息的说明，请参阅Off-Heap(OffHeapMemoryStats)。

默认情况下，堆外内存优化用于存储大小为128 KB的值。 此图称为“最大优化存储值大小”，我们将在此处用maxOptStoredValSize表示。 如果您的数据通常运行较大，则可以通过将OFF_HEAP_FREE_LIST_COUNT系统参数增加到大于maxOptStoredValSize/8的数字来增强性能，其中maxOptStoredValSize以KB(1024字节)表示。 因此，默认值对应于：

128 KB / 8 = (128 * 1024) / 8 = 131,072 / 8 = 16,384
-Dgemfire.OFF_HEAP_FREE_LIST_COUNT=16384

要优化最大优化存储值大小（默认值的两倍或256 KB），空闲列表计数应加倍：

-Dgemfire.OFF_HEAP_FREE_LIST_COUNT=32768

在调优过程中，您可以打开和关闭off-heap区域属性，保留其他堆外设置和参数，以便比较应用程序的堆上和堆外性能。

锁定内存(仅限Linux系统)

在Linux系统上，您可以锁定内存以防止操作系统分页堆或堆外内存。

要使用此功能：

1. 配置锁定内存的操作系统限制。 将操作系统的ulimit -l值（可能在内存中锁定的最大大小）从默认值（通常为32 KB或64 KB）增加到至少Geode用于堆栈或关闭的内存总量 堆存储。 要查看当前设置，请在shell提示符下输入ulimit -a并找到max locked memory的值：

   # ulimit -a
   ...
   max locked memory       (kbytes, -l) 64
   ...

   使用ulimit -l max-size-in-kbytes来提高限制。 例如，要将锁定的内存限制设置为64 GB：

   # ulimit -l 64000000

2. 以这种方式使用锁定内存会增加启动Geode所需的时间。 启动Geode所需的额外时间取决于所使用的内存总量，可以在几秒到10分钟或更长的范围内。 为了缩短启动时间并减少成员超时的可能性，请通过发出以下命令，指示内核在启动Geode成员之前释放操作系统页面缓存：

   $ echo 1 > /proc/sys/vm/drop_caches

3. 使用gfsh -lock-memory=true选项启动每个Geode数据存储。 如果每个主机部署多个服务器，请先顺序启动每个服务器。 如果不小心分配了可用的RAM，则按顺序启动服务器可以避免操作系统中的竞争状况，该竞争状况可能导致故障（甚至导致机器崩溃）。 确认系统配置稳定后，即可并发启动服务器。

磁盘存储

使用Apache Geode磁盘存储，您可以将数据保存到磁盘，作为内存中副本的备份，并在内存使用过高时将数据溢出到磁盘。

• 磁盘存储的工作原理

  溢出和持久性单独或一起使用磁盘存储来存储数据。

• 磁盘存储文件名和扩展名

  磁盘存储文件包括存储管理文件，访问控制文件和操作日志或oplog文件，包括一个用于删除的文件和另一个用于所有其他操作的文件。

• 磁盘存储操作日志

  在创建时，每个操作日志都在磁盘存储的max-oplog-size中初始化，其大小分为crf和drf文件。 当oplog关闭时，Apache Geode会将文件缩小到每个文件中使用的空间。

• 配置磁盘存储

  除了您指定的磁盘存储之外，Apache Geode还有一个默认磁盘存储，它在配置磁盘使用时未使用指定磁盘存储名称时使用。 您可以修改默认磁盘存储行为。

• 使用磁盘存储优化系统

  遵循本节中的准则，优化可用性和性能。

• 启动并关闭磁盘存储

  本节介绍启动和关闭期间发生的情况，并提供这些操作的过程。

• 磁盘存储管理

  gfsh命令行工具有许多选项可用于检查和管理磁盘存储。 gfsh工具，cache.xml文件和DiskStore API是在线和离线磁盘存储的管理工具。

• 为系统恢复和运营管理创建备份

  备份是磁盘存储中持久数据的副本。 备份用于将磁盘存储还原到备份时的状态。 根据集群是联机还是脱机，相应的备份和还原过程会有所不同。 在线系统目前正在运行成员。 离线系统没有任何正在运行的成员。

磁盘存储的工作原理

溢出和持久性单独或一起使用磁盘存储来存储数据。

磁盘存储可用于以下项目：

• Regions. 持久化和/或从区域溢出数据。
• Server’s client subscription queues. 溢出消息传递队列以控制内存使用。
• Gateway sender queues. 坚持这些以获得高可用性。 这些队列总是溢出。
• PDX serialization metadata. 使用Geode PDX序列化保留有关您序列化的对象的元数据。

每个成员都有自己的一组磁盘存储，它们与任何其他成员的磁盘存储完全分开。 对于每个磁盘存储，定义数据存储到磁盘的位置和方式。 您可以将来自多个区域和队列的数据存储在单个磁盘存储中。

此图显示了已定义磁盘存储D到R的成员。 该成员有两个持久区域使用磁盘存储D和溢出区域以及使用磁盘存储R的溢出队列。

Geode写入磁盘存储的内容

Geode将以下内容写入磁盘存储：

• 创建和配置磁盘存储时指定的持久性和溢出数据
• 承载存储和信息及其状态的成员，例如哪些成员在线以及哪些成员处于脱机状态和时间戳
• 磁盘存储标识符
• 磁盘存储区中的哪些区域由区域名称指定并包括所选属性
• 磁盘存储区域所依赖的共同定位区域的名称
• 记录所有区域的运营情况

Geode不会将索引写入磁盘。

磁盘存储状态

磁盘存储的文件由Geode作为一个组。 将它们视为一个单一的实体。 如果您复制它们，请将它们全部复制在一起。 不要更改文件名。

磁盘存储访问和管理根据成员是在线还是离线而不同。 当成员正在运行时，其磁盘存储在线。 当成员退出并且未运行时，其磁盘存储处于脱机状态。

• Online, 磁盘存储由其成员进程拥有和管理。 要在联机磁盘存储上运行操作，请在成员进程中使用API调用，或使用gfsh命令行界面。
• Offline, 磁盘存储只是主机文件系统中的文件集合。 可以根据文件系统权限访问这些文件。 您可以复制文件以进行备份或移动成员的磁盘存储位置。 您还可以使用gfsh命令行界面运行一些维护操作，例如文件压缩和验证。 脱机时，磁盘存储的信息对集群不可用。 对于分区区域，区域数据在多个成员之间分配，因此成员的启动取决于所有成员，并且必须等待所有成员联机。 尝试访问脱机成员存储在磁盘上的条目会导致PartitionOfflineException。

磁盘存储文件名和扩展名

磁盘存储文件包括存储管理文件，访问控制文件和操作日志或oplog文件，包括一个用于删除的文件和另一个用于所有其他操作的文件。

下表描述了文件名和扩展名; 它们后面是示例磁盘存储文件。

文件名

文件名有三个部分：用途标识符，磁盘存储库名称和oplog序列号。

文件名的第一部分: Usage Identifier

文件名的第二部分: Disk Store Name

文件名的第三部分: oplog Sequence Number

文件扩展名

磁盘存储的示例文件为persistDS1和overflowDS1：

bash-2.05$ ls -tlr persistData1/
total 8
-rw-rw-r--   1 person users        188 Mar  4 06:17 BACKUPpersistDS1.if
-rw-rw-r--   1 person users          0 Mar  4 06:18 BACKUPpersistDS1_1.drf
-rw-rw-r--   1 person users         38 Mar  4 06:18 BACKUPpersistDS1_1.crf
bash-2.05$ ls -tlr overflowData1/
total 1028
-rw-rw-r--   1 person users          0 Mar  4 06:21 DRLK_IFoverflowDS1.lk
-rw-rw-r--   1 person users          0 Mar  4 06:21 BACKUPoverflowDS1.if
-rw-rw-r--   1 person users 1073741824 Mar  4 06:21 OVERFLOWoverflowDS1_1.crf

持久区域的默认磁盘存储文件示例：

bash-2.05$ ls -tlr
total 106
-rw-rw-r--   1 person users       1010 Mar  8 15:01 defTest.xml
drwxrwxr-x   2 person users        512 Mar  8 15:01 backupDirectory
-rw-rw-r--   1 person users          0 Mar  8 15:01 DRLK_IFDEFAULT.lk
-rw-rw-r--   1 person users  107374183 Mar  8 15:01 BACKUPDEFAULT_1.drf
-rw-rw-r--   1 person users  966367641 Mar  8 15:01 BACKUPDEFAULT_1.crf
-rw-rw-r--   1 person users        172 Mar  8 15:01 BACKUPDEFAULT.if

磁盘存储操作日志

在创建时，每个操作日志都在磁盘存储的max-oplog-size中初始化，其大小分为crf和drf文件。 当oplog关闭时，Apache Geode会将文件缩小到每个文件中使用的空间。

关闭oplog之后，Geode还会尝试创建一个krf文件，其中包含键名以及crf文件中值的偏移量。 虽然启动时不需要此文件，但如果它可用，它将通过允许Geode在加载条目键后在后台加载条目值来提高启动性能。

当操作日志已满时，Geode会自动关闭它并创建一个包含下一个序列号的新日志。 这称为oplog rolling。 您还可以通过API调用DiskStore.forceRoll请求oplog滚动。 您可能希望在压缩磁盘存储之前立即执行此操作，因此最新的oplog可用于压缩。

注意: 日志压缩可以更改磁盘存储文件的名称。 通常会更改文件编号顺序，删除一些现有日志，或者使用编号较高的较新日志替换。 Geode始终以高于任何现有数字的数字开始新日志。

此示例清单显示系统中的日志，其中只有一个为存储指定的磁盘目录。 第一个日志(BACKUPCacheOverflow_1.crf和BACKUPCacheOverflow_1.drf)已关闭，系统正在写入第二个日志。

bash-2.05$ ls -tlra 
total 55180
drwxrwxr-x   7 person users        512 Mar 22 13:56 ..
-rw-rw-r--   1 person users          0 Mar 22 13:57 BACKUPCacheOverflow_2.drf
-rw-rw-r--   1 person users     426549 Mar 22 13:57 BACKUPCacheOverflow_2.crf
-rw-rw-r--   1 person users          0 Mar 22 13:57 BACKUPCacheOverflow_1.drf
-rw-rw-r--   1 person users     936558 Mar 22 13:57 BACKUPCacheOverflow_1.crf
-rw-rw-r--   1 person users       1924 Mar 22 13:57 BACKUPCacheOverflow.if
drwxrwxr-x   2 person users       2560 Mar 22 13:57 .

系统将在所有可用磁盘目录中旋转以写入其日志。 下一个日志始终在未达到其已配置容量的目录中启动（如果存在）。

磁盘存储Oplog达到配置的磁盘容量时

如果不存在容量限制范围内的目录，Geode如何处理这取决于是否启用了自动压缩。

• 如果启用了自动压缩，Geode会在其中一个目录中创建一个新的oplog，超出限制，并记录一个警告，报告：

  Even though the configured directory size limit has been exceeded a 
  new oplog will be created. The current limit is of XXX. The current 
  space used in the directory is YYY.

  注意: 启用自动压缩后，dir-size不会限制使用多少磁盘空间。 Geode将执行自动压缩，这应该释放空间，但系统可能会超过配置的磁盘限制。

• 如果禁用自动压缩，Geode不会在附加到磁盘存储块的区域中创建新的oplog操作，并且Geode会记录此错误：

  Disk is full and rolling is disabled. No space can be created

配置磁盘存储

除了您指定的磁盘存储之外，Apache Geode还有一个默认磁盘存储，它在配置磁盘使用时未使用指定磁盘存储名称时使用。 您可以修改默认磁盘存储行为。

• 设计和配置磁盘存储

  您可以在缓存中定义磁盘存储，然后通过在区域和队列配置中设置disk-store-name属性将它们分配给您的区域和队列。

• 磁盘存储配置参数

  您可以使用gfsh create disk-store命令或cache.xml中缓存声明的<disk-store>子元素来定义磁盘存储。 所有磁盘存储都可供所有区域和队列使用。

• 修改默认磁盘存储

  您可以通过为名为“DEFAULT”的磁盘存储指定所需的属性来修改默认磁盘存储的行为。

设计和配置磁盘存储

您可以在缓存中定义磁盘存储，然后通过在区域和队列配置中设置disk-store-name属性将它们分配给您的区域和队列。

注意: 除了您指定的磁盘存储，Apache Geode还有一个默认磁盘存储，它在配置磁盘使用时没有指定磁盘存储名称。 默认情况下，此磁盘存储区保存到应用程序的工作目录中。 您可以更改其行为，如创建和配置磁盘存储和修改默认磁盘。

• 设计您的磁盘存储
• 创建和配置磁盘存储
• 配置区域，队列和PDX序列化以使用磁盘存储
• 在网关发件人上配置磁盘存储

设计您的磁盘存储

在开始之前，您应该了解Geode 基本配置和编程。

1. 与您的系统设计人员和开发人员一起规划测试和生产缓存系统中预期的磁盘存储要求。 考虑空间和功能要求。

   • 为了提高效率，仅在单独的磁盘存储中溢出的数据与持久或持久且溢出的数据分开。 区域可以溢出，持久存在，或两者兼而有之。 服务器订阅队列仅溢出。

   • 计算磁盘需求时，请参考数据修改模式和压缩策略。 Geode以max-oplog-size创建每个oplog文件，默认为1 GB。 只有在压缩过程中才会从oplog中删除过时的操作，因此您需要足够的空间来存储压缩之间完成的所有操作。 对于混合使用更新和删除的区域，如果使用自动压缩，则所需磁盘空间的上限为

     (1 / (1 - (compaction_threshold/100)) ) * data size

     其中数据大小是您存储在磁盘存储中的所有数据的总大小。 因此，对于默认的压缩阈值50，磁盘空间大约是数据大小的两倍。 请注意，压缩线程可能落后于其他操作，导致磁盘使用暂时超过阈值。 如果禁用自动压缩，则所需的磁盘数量取决于手动压缩之间累积的过时操作数量。

2. 根据预期的磁盘存储要求和主机系统上的可用磁盘，与主机系统管理员一起确定磁盘存储目录的放置位置。

   • 确保新存储不会干扰在系统上使用磁盘的其他进程。 如果可能，请将文件存储到其他进程未使用的磁盘，包括虚拟内存或交换空间。 如果您有多个可用磁盘，为了获得最佳性能，请在每个磁盘上放置一个目录。
   • 为不同的成员使用不同的目录。 您可以将任意数量的目录用于单个磁盘存储。

创建和配置磁盘存储

1. 在您选择的位置，创建要为磁盘存储指定的所有目录。 如果在创建磁盘存储时指定的目录不可用，Geode会抛出异常。 您不需要用任何东西填充这些目录。

2. 打开gfsh提示符并连接到集群。

3. 在gfsh提示符下，创建并配置磁盘存储：

   • 指定磁盘存储的名称（--name）。

     • 为您的操作系统选择合适的磁盘存储名称。 磁盘存储名称用于磁盘文件名：
       • 使用满足操作系统文件命名要求的磁盘存储名称。 例如，如果将数据存储在Windows系统中的磁盘上，则磁盘存储名称不能包含任何这些保留字符，<>：“/ \ |？*。
       • 不要使用很长的磁盘存储名称。 完整文件名必须符合您的操作系统限制。 例如，在Linux上，标准限制为255个字符。

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480

   • 配置目录位置（--dir）和用于存储的最大空间（在磁盘目录名称后面指定＃和最大数字，以兆字节为单位）。

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480

   • （可选）您可以配置存储的文件压缩行为。 在这种情况，计划和方案对于任何手动压缩结合使用。 例：

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
     --compaction-threshold=40 --auto-compact=false --allow-force-compaction=true

   • 如果需要，请配置单个oplog的最大大小（以MB为单位）。 当前文件达到此大小时，系统将前滚到新文件。 使用相对较小的最大文件大小可以获得更好的性能 例：

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
     --compaction-threshold=40 --auto-compact=false --allow-force-compaction=true \
     --max-oplog-size=512

   • 如果需要，请修改队列管理参数以进行异步排队到磁盘存储。 您可以为同步或异步排队配置任何区域（区域属性disk-synchronous）。 服务器队列和网关发送方队列始终同步运行。 当达到queue-size（队列容量）或time-interval（毫秒）时，排队的数据被刷新到磁盘。 您还可以通过DiskStore flushToDisk方法同步将未写入的数据刷新到磁盘。 例：

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
     --compaction-threshold=40 --auto-compact=false --allow-force-compaction=true \
     --max-oplog-size=512 --queue-size=10000 --time-interval=15

   • 如果需要，修改用于写入磁盘的缓冲区的大小（以字节为单位）。 例：

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
     --compaction-threshold=40 --auto-compact=false --allow-force-compaction=true \
     --max-oplog-size=512 --queue-size=10000 --time-interval=15 --write-buffer-size=65536

   • 如果需要，修改disk-usage-warning-percentage和disk-usage-critical-percentagethresholds，确定将触发警告的磁盘使用百分比（默认值：90％）和百分比（默认值：99 ％）磁盘使用率将产生错误并关闭成员缓存。 例：

     gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
     --compaction-threshold=40 --auto-compact=false --allow-force-compaction=true \
     --max-oplog-size=512 --queue-size=10000 --time-interval=15 --write-buffer-size=65536 \
     --disk-usage-warning-percentage=80 --disk-usage-critical-percentage=98

以下是完整的磁盘存储cache.xml配置示例：

<disk-store name="serverOverflow" compaction-threshold="40" 
           auto-compact="false" allow-force-compaction="true"
        max-oplog-size="512" queue-size="10000"  
        time-interval="15" write-buffer-size="65536"
        disk-usage-warning-percentage="80"
        disk-usage-critical-percentage="98">
       <disk-dirs>
              <disk-dir>c:\overflow_data</disk-dir>
              <disk-dir dir-size="20480">d:\overflow_data</disk-dir>
       </disk-dirs>
</disk-store>

注意: 作为在集群中的每个服务器上定义cache.xml的替代方法 - 如果启用了集群配置服务，则在gfsh中创建磁盘存储时，可以与其余集群共享磁盘存储的配置。 请参见集群配置服务概述。

修改磁盘存储

您可以使用alter disk-store命令修改脱机磁盘存储。 如果要修改默认磁盘存储配置，请使用“DEFAULT”作为磁盘存储名称。

配置区域，队列和PDX序列化以使用磁盘存储

以下是为区域，队列和PDX序列化使用已创建和命名的磁盘存储的示例。

使用磁盘存储区域持久性和溢出的示例：

• gfsh:

  gfsh>create region --name=regionName --type=PARTITION_PERSISTENT_OVERFLOW \
  --disk-store=serverPersistOverflow

• cache.xml

  <region refid="PARTITION_PERSISTENT_OVERFLOW" disk-store-name="persistOverflow1"/>

将命名磁盘存储用于服务器订阅队列溢出（cache.xml）的示例：

<cache-server port="40404">
   <client-subscription 
      eviction-policy="entry" 
      capacity="10000"
      disk-store-name="queueOverflow2"/>
</cache-server>

将命名磁盘存储用于PDX序列化元数据（cache.xml）的示例：

<pdx read-serialized="true" 
    persistent="true" 
    disk-store-name="SerializationDiskStore">
</pdx>

在网关发件人上配置磁盘存储

网关发件人队列始终溢出，可能会保留。 如果不持久，则将它们分配给溢出磁盘存储，如果这样做，则分配给持久性磁盘存储。

将命名磁盘存储用于网关发送方队列持久性的示例：

• gfsh:

  gfsh>create gateway-sender --id=persistedSender1 --remote-distributed-system-id=1 \
  --enable-persistence=true --disk-store-name=diskStoreA --maximum-queue-memory=100

• cache.xml:

  <cache>
    <gateway-sender id="persistedsender1" parallel="true" 
     remote-distributed-system-id="1"
     enable-persistence="true"
     disk-store-name="diskStoreA"
     maximum-queue-memory="100"/> 
     ... 
  </cache>

使用默认磁盘存储区进行网关发送方队列持久性和溢出的示例：

• gfsh:

  gfsh>create gateway-sender --id=persistedSender1 --remote-distributed-system-id=1 \
  --enable-persistence=true --maximum-queue-memory=100

• cache.xml:

  <cache>
    <gateway-sender id="persistedsender1" parallel="true" 
     remote-distributed-system-id="1"
     enable-persistence="true"
     maximum-queue-memory="100"/> 
     ... 
  </cache>

磁盘存储配置参数

您可以使用gfsh create disk-store命令或cache.xml中缓存声明的<disk-store>子元素来定义磁盘存储。 所有磁盘存储都可供所有区域和队列使用。

这些<disk-store>属性和子元素在org.apache.geode.cache.DiskStoreFactory和org.apachegeode.cache.DiskStoreAPI中具有相应的gfsh create disk-storecommand-line参数以及getter和setter方法。

磁盘存储配置属性和元素

disk-dirs元素

<disk-dirs>元素定义用于磁盘存储的主机系统目录。 它包含一个或多个单个<disk-dir>元素，其中包含以下内容：

• 目录规范，作为disk-dir元素的文本提供。
• 一个可选的dir-size属性，指定用于目录中磁盘存储的最大空间量（以兆字节为单位）。 默认情况下，没有限制。 使用的空间计算为所有oplog文件的组合大小。

您可以为disk-dirs元素指定任意数量的disk-dir子元素。 数据均匀分布在目录中的活动磁盘文件中，并保持在您设置的任何限制范围内。

例子:

<disk-dirs>
    <disk-dir>/host1/users/gf/memberA_DStore</disk-dir>
    <disk-dir>/host2/users/gf/memberA_DStore</disk-dir> 
    <disk-dir dir-size="20480">/host3/users/gf/memberA_DStore</disk-dir> 
</disk-dirs>

注意: 创建磁盘存储或系统抛出异常时，目录必须存在。 Geode不会创建目录。

对不同的磁盘存储使用不同的disk-dir规范。 您不能在两个不同的成员中为同一个命名磁盘存储使用相同的目录。

修改默认磁盘存储

您可以通过为名为“DEFAULT”的磁盘存储指定所需的属性来修改默认磁盘存储的行为。

无论何时使用磁盘存储而不指定要使用的磁盘存储，Geode都会使用名为“DEFAULT”的磁盘存储。

例如，这些区域和队列配置指定持久性和/或溢出，但不指定disk-store-name。 由于未指定磁盘存储，因此这些存储使用名为“DEFAULT”的磁盘存储。

使用默认磁盘存储区域持久性和溢出的示例：

• gfsh:

  gfsh>create region --name=regionName --type=PARTITION_PERSISTENT_OVERFLOW

• cache.xml

  <region refid="PARTITION_PERSISTENT_OVERFLOW"/>

使用默认磁盘存储区进行服务器订阅队列溢出（cache.xml）的示例：

<cache-server port="40404">
    <client-subscription eviction-policy="entry" capacity="10000"/>
</cache-server>

更改默认磁盘存储的行为

Geode使用默认磁盘存储配置设置初始化默认磁盘存储。 您可以通过为名为“DEFAULT”的磁盘存储指定所需的属性来修改默认磁盘存储的行为。 关于默认磁盘存储，您唯一无法更改的是名称。

以下示例更改默认磁盘存储以允许手动压缩并使用多个非默认目录：

cache.xml:

<disk-store name="DEFAULT" allow-force-compaction="true">
     <disk-dirs>
        <disk-dir>/export/thor/customerData</disk-dir>
        <disk-dir>/export/odin/customerData</disk-dir>
        <disk-dir>/export/embla/customerData</disk-dir>
     </disk-dirs>
</disk-store>

使用磁盘存储优化系统

遵循本节中的准则，优化可用性和性能。

1. Apache Geode建议在Linux或Solaris平台上运行时使用ext4文件系统。 ext4文件系统支持预分配，这有利于磁盘启动性能。 如果您在具有高写入吞吐量的延迟敏感环境中使用ext3文件系统，则可以通过将maxOplogSize（请参阅DiskStoreFactory.setMaxOplogSize）设置为低于默认值1 GB的值来提高磁盘启动性能。 通过在Geode进程启动时指定系统属性gemfire.preAllocateDisk=false来禁用预分配。
2. 启动系统时，大致同时启动具有持久区域的所有成员。 创建和使用启动脚本以确保一致性和完整性。
3. 使用gfshshutdown命令关闭系统。 这是一个有序的关闭，可以定位磁盘存储以加快启动速度。
4. 配置磁盘的关键使用阈值（disk-usage-warning-percentage和disk-usage-critical-percentage）。 默认情况下，这些设置为80％用于警告，99％用于关闭缓存的错误。
5. 确定文件压缩策略，并在需要时开发监视文件和执行常规压缩的过程。
6. 确定磁盘存储的备份策略并遵循它。 您可以使用backup disk-store命令备份正在运行的系统。
7. 如果在磁盘存储脱机时删除任何永久区域或更改其配置，请考虑同步磁盘存储中的区域。

启动并关闭磁盘存储

本节介绍启动和关闭期间发生的情况，并提供这些操作的过程。

启动

当您使用持久区域启动成员时，将从磁盘存储中检索数据以重新创建成员的持久区域。 如果成员未保存该区域的所有最新数据，则其他成员将拥有数据和区域创建块，等待其他成员。 具有共置条目的分区区域也在启动时阻塞，等待共置区域的条目可用。 永久网关发件人的处理方式与共处理区域相同，因此它也可以阻止区域创建。

使用日志级别的信息或以下信息，系统会提供有关等待的消息。 这里，server2的磁盘存储区具有该区域的最新数据，server1正在等待server2。

Region /people has potentially stale data.
It is waiting for another member to recover the latest data.
My persistent id:
  DiskStore ID: 6893751ee74d4fbd-b4780d844e6d5ce7
  Name: server1
  Location: /192.0.2.0:/home/dsmith/server1/.
Members with potentially new data:
[
  DiskStore ID: 160d415538c44ab0-9f7d97bae0a2f8de
  Name: server2
  Location: /192.0.2.0:/home/dsmith/server2/.
]
Use the "gfsh show missing-disk-stores" command to see all disk stores
that are being waited on by other members.

当最新数据可用时，系统会更新区域，记录消息并继续启动。

[info 2010/04/09 10:52:13.010 PDT CacheRunner <main> tid=0x1]    
   Done waiting for the remote data to be available.

如果成员的磁盘存储区包含从未创建的区域的数据，则数据将保留在磁盘存储区中。

每个成员的持久区域尽可能快地加载并上线，而不是不必要地等待其他成员完成。 出于性能原因，这些操作是异步发生的：

• 一旦从磁盘恢复了每个存储桶的至少一个副本，该区域就可用。 辅助存储桶将异步加载。
• 在考虑条目值之前，从磁盘存储区中的密钥文件加载条目密钥。 加载所有密钥后，Geode将异步加载条目值。 如果在加载之前请求了值，则将立即从磁盘存储中获取该值。

启动程序

要启动具有磁盘存储的系统：

1. 首先使用持久数据同时启动所有成员. 具体如何执行此操作取决于您的成员。 确保启动托管共处区域的成员以及持久网关发件人。

   在他们初始化他们的区域时，成员确定哪些具有最新的区域数据，并使用最新的数据初始化他们的区域。

   对于仅在某些区域的主机成员中定义持久性的复制区域，请在非持久性复制成员之前启动持久性复制成员，以确保从磁盘恢复数据。

   这是一个用于并行启动成员的bash脚本示例。 脚本等待启动完成。 如果其中一个作业失败，它将以错误状态退出。

   #!/bin/bash
   ssh servera "cd /my/directory; gfsh start server --name=servera &
   ssh serverb "cd /my/directory; gfsh start server --name=serverb &
   STATUS=0;
   for job in `jobs -p`
   do
   echo $job
   wait $job;
   JOB_STATUS=$?;
   test $STATUS -eq 0 && STATUS=$JOB_STATUS;
   done
   exit $STATUS;

2. 回应被阻止的成员. 当成员阻止等待来自另一个成员的更新数据时，该成员将无限期地等待而不是使用陈旧数据联机。 使用gfsh show missing-disk-stores命令检查缺少的磁盘存储。 请参阅处理丢失的磁盘存储。

   • 如果没有磁盘存储丢失，由于某些其他原因，缓存初始化必须很慢。 在诊断系统问题中查看有关成员挂起的信息。
   • 如果缺少您认为应该存在的磁盘存储：
     • 确保您已启动该成员。 检查日志中是否有任何失败消息。 请参阅Logging。
     • 确保可以访问磁盘存储文件。 如果已移动成员或磁盘存储文件，则必须更新磁盘存储配置以匹配。
   • 如果缺少您知道丢失的磁盘存储，因为您已删除它们或其文件不可用，请撤消它们以便启动可以继续。

示例启动以说明订购

以下列出了在关闭后启动复制的持久区域的两种可能性。 假设成员A（MA）首先退出，将剩余数据留在磁盘上用于RegionP。 成员B（MB）继续在RegionP上运行操作，RegionP更新其磁盘存储并使MA的磁盘存储处于过时状态。 MB退出，将最新数据保留在RegionP的磁盘上。

• 重启订单1
  1. MB首先启动。 MB标识它具有RegionP的最新磁盘数据并从磁盘初始化该区域。 MB不会阻止。
  2. MA已启动，从磁盘恢复其数据，并根据需要从MB中的数据更新区域数据。
• 重启订单2
  1. MA首先启动。 MA确定它没有最新的磁盘数据和块，等待MB在MA中重新创建RegionP之前启动。
  2. MB已启动。 MB标识它具有RegionP的最新磁盘数据并从磁盘初始化该区域。
  3. MA从磁盘恢复其RegionP数据，并根据需要从MB中的数据更新区域数据。

关闭

如果多个成员承载持久区域或队列，则在重新启动系统时，各个成员关闭的顺序可能很重要。 退出系统或关闭的最后一个成员具有磁盘上最新的数据。 每个成员都知道退出或关闭时哪些其他系统成员在线。 这允许成员在随后的启动时获取最新数据。

对于具有持久性的复制区域，要退出的最后一个成员具有最新数据。

对于分区区域，每个成员都会持有自己的存储桶。 使用gfsh shutdown的关闭会在退出前同步磁盘存储，因此所有磁盘存储都会保存最新的数据。 如果没有有序关闭，某些磁盘存储可能具有比其他磁盘存储更新的存储区数据。

关闭系统的最佳方法是在所有成员运行时调用gfsh shutdown命令。 所有在线数据存储将在关闭之前同步，因此所有数据存储都保留最新的数据副本。 要关闭定位器以外的所有成员：

gfsh>shutdown

To shut down all members, including locators:

gfsh>shutdown --include-locators=true

磁盘存储管理

gfsh命令行工具有许多选项可用于检查和管理磁盘存储。 gfsh工具，cache.xml文件和DiskStore API是在线和离线磁盘存储的管理工具。

有关可用命令的列表，请参阅磁盘存储命令。

• 磁盘存储管理命令和操作

• 验证磁盘存储

• 在磁盘存储日志文件上运行压缩

• 保持磁盘存储与缓存同步

• 配置磁盘可用空间监视

• 处理丢失的磁盘存储

• 当缓冲区刷新到磁盘时更改

  您可以将Geode配置为立即写入磁盘，您可以修改操作系统行为以更频繁地执行缓冲区刷新。

磁盘存储管理命令和操作

您可以使用gfsh命令行工具管理磁盘存储。 有关gfsh命令的更多信息，请参阅gfsh和磁盘存储命令。

注意: 这些命令中的每一个都在联机磁盘存储或脱机磁盘存储上运行，但不能同时运行。

要获得任何gfsh命令的完整命令语法，请在gfsh命令行中运行help <command>。

在线磁盘存储操作

对于在线操作，gfsh必须通过JMX管理器连接到集群，并将操作请求发送给具有磁盘存储的成员。 这些命令不会在脱机磁盘存储上运行。

脱机磁盘存储操作

对于脱机操作，gfsh对指定的磁盘存储及其指定的目录运行命令。 您必须指定磁盘存储的所有目录。 例如：

gfsh>compact offline-disk-store --name=mydiskstore --disk-dirs=MyDirs

脱机操作不会在联机磁盘存储上运行。 该工具在磁盘存储运行时锁定它，因此该成员无法在操作过程中启动。

如果您尝试为联机磁盘存储运行脱机命令，则会收到如下消息：

gfsh>compact offline-disk-store --name=DEFAULT --disk-dirs=s1
This disk store is in use by another process. "compact disk-store" can 
be used to compact a disk store that is currently in use.

验证磁盘存储

validate offline-disk-store命令验证脱机磁盘存储的运行状况，并为您提供有关其中区域的信息，总条目以及压缩存储时将删除的记录数。

在以下时间使用此命令：

• 在压缩脱机磁盘存储之前，以帮助确定它是否值得做。
• 在还原或修改磁盘存储之前。
• 任何时候你想确定磁盘存储器的状态良好。

例子:

gfsh>validate offline-disk-store --name=ds1 --disk-dirs=hostB/bupDirectory

在磁盘存储日志文件上运行压缩

将缓存操作添加到磁盘存储时，同一条目的任何预先存在的操作记录都将过时，Apache Geode会将其标记为垃圾。 例如，当你创建一个条目，创建操作被添加到存储中。 如果稍后更新该条目，则会添加更新操作，并且创建操作将变为垃圾。 Geode不会删除垃圾记录，但它会跟踪每个操作日志中的垃圾百分比，并提供删除垃圾以压缩日志文件的机制。

Geode通过将所有非垃圾记录复制到当前日志并丢弃旧文件来压缩旧操作日志。 与日志记录一样，在压缩期间根据需要滚动oplog以保持在最大oplog设置内。

您可以将系统配置为在垃圾内容达到特定百分比时自动压缩任何已关闭的操作日志。 您还可以手动请求在线和离线磁盘存储的压缩。 对于联机磁盘存储，无论压缩包含多少垃圾，当前操作日志都不可用于压缩。

联机磁盘存储的日志文件压缩

脱机压缩基本上以相同的方式运行，但没有传入的缓存操作。 此外，由于当前没有打开日志，因此压缩会创建一个新的开始日志。

运行在线压缩

当旧日志文件的垃圾内容超过总文件的配置百分比时，它们就有资格进行在线压缩。 当一个记录的操作被同一个对象的更新操作取代时，该记录就是垃圾。 在压缩期间，非垃圾记录将与新的缓存操作一起添加到当前日志中。 在线压缩不会阻止当前的系统操作。

• 自动压缩. 当auto-compact为真时，Geode会在其垃圾内容超过compaction-threshold时自动压缩每个oplog。 这需要从其他操作开始循环，因此您可能希望禁用此操作并仅执行手动压缩，以控制时间。

• 手动压缩. 要运行手动压缩：

  • 将磁盘存储属性allow-force-compaction设置为true。 这会导致Geode维护有关文件的额外数据，以便按需压缩。 默认情况下禁用此选项以节省空间。 您可以在系统运行时随时运行手动在线压缩。 有资格根据compaction-threshold进行压缩的Oplog被压缩到当前的oplog中。

  • 根据需要运行手动压缩。 Geode有两种类型的手动压缩：

    • 使用forceCompaction方法通过API压缩单个在线磁盘存储的日志。 此方法首先滚动oplog，然后压缩它们。 例：

      myCache.getDiskStore("myDiskStore").forceCompaction();

    • 使用gfsh，使用compact disk-store命令压缩磁盘存储。 例子：

      gfsh>compact disk-store --name=Disk1
      gfsh>compact disk-store --name=Disk1 --group=MemberGroup1,MemberGroup2

      注意: 您需要连接到gfsh中的JMX Manager才能运行此命令。

运行脱机压缩

离线压缩是一个手动过程。 无论他们持有多少垃圾，所有日志文件都会尽可能地压缩。 脱机压缩为压缩的日志记录创建新的日志文件。

使用gfsh，使用compact offline-disk-store压缩各个离线磁盘存储命令：

gfsh>compact offline-disk-store --name=Disk2 --disk-dirs=/Disks/Disk2
gfsh>compact offline-disk-store --name=Disk2 --disk-dirs=/Disks/Disk2 
--max-oplog-size=512 -J=-Xmx1024m

注意: Do not perform offline compaction on the baseline directory of an incremental backup.

您必须提供磁盘存储中的所有目录。 如果未指定oplog max size，则Geode使用系统默认值。

离线压缩可能会占用大量内存。 如果在运行时出现“java.lang.OutOfMemory”错误，则可能需要使用-J=-Xmx参数增加堆大小。

手动压实的性能优势

如果禁用自动压缩并在较轻的系统负载期间或停机期间运行您自己的手动压缩，则可以在繁忙时间提高性能。 在应用程序执行大量数据操作后，您可以运行API调用。 当系统使用率很低时，你可以每晚运行compact disk-store命令。

要遵循这样的策略，您需要留出足够的磁盘空间来容纳所有未压缩的磁盘数据。 您可能需要增加系统监视以确保不会超出磁盘空间。 您可能只能运行离线压缩。 如果是这样，您可以将allow-force-compaction设置为false，并避免存储手动在线压缩所需的信息。

目录大小限制

压缩期间达到目录大小限制具有不同的结果，具体取决于您是运行自动压缩还是手动压缩：

• 对于自动压缩，系统会记录警告，但不会停止。
• 对于手动压缩，操作停止并向调用进程返回DiskAccessException，报告系统磁盘空间不足。

示例压缩运行

在这个离线压缩运行列表的例子中，磁盘存储压缩在*_3.*文件中没有任何关系，所以它们是独立的。 *_4.*文件有垃圾记录，因此来自它们的oplog被压缩成新的*_5.*文件。

bash-2.05$ ls -ltra backupDirectory
total 28
-rw-rw-r--   1 user users          3 Apr  7 14:56 BACKUPds1_3.drf
-rw-rw-r--   1 user users         25 Apr  7 14:56 BACKUPds1_3.crf
drwxrwxr-x   3 user users       1024 Apr  7 15:02 ..
-rw-rw-r--   1 user users       7085 Apr  7 15:06 BACKUPds1.if
-rw-rw-r--   1 user users         18 Apr  7 15:07 BACKUPds1_4.drf
-rw-rw-r--   1 user users       1070 Apr  7 15:07 BACKUPds1_4.crf
drwxrwxr-x   2 user users        512 Apr  7 15:07 .
bash-2.05$ gfsh
gfsh>validate offline-disk-store --name=ds1 --disk-dirs=backupDirectory
/root: entryCount=6
/partitioned_region entryCount=1 bucketCount=10
Disk store contains 12 compactable records.
Total number of region entries in this disk store is: 7
gfsh>compact offline-disk-store --name=ds1 --disk-dirs=backupDirectory
Offline compaction removed 12 records.
Total number of region entries in this disk store is: 7
gfsh>exit
bash-2.05$ ls -ltra backupDirectory
total 16
-rw-rw-r--   1 user users          3 Apr  7 14:56 BACKUPds1_3.drf
-rw-rw-r--   1 user users         25 Apr  7 14:56 BACKUPds1_3.crf
drwxrwxr-x   3 user users       1024 Apr  7 15:02 ..
-rw-rw-r--   1 user users          0 Apr  7 15:08 BACKUPds1_5.drf
-rw-rw-r--   1 user users        638 Apr  7 15:08 BACKUPds1_5.crf
-rw-rw-r--   1 user users       2788 Apr  7 15:08 BACKUPds1.if
drwxrwxr-x   2 user users        512 Apr  7 15:09 .
bash-2.05$

保持磁盘存储与缓存同步

当离线数据的配置与在线数据的配置匹配时，从脱机磁盘存储中恢复数据的速度最快。

每当您更改或删除持久区域时(通过修改cache.xml或配置区域的代码)，您应该更改相应的脱机磁盘存储以匹配。 如果不这样做，则下次恢复此磁盘存储时，它将使用旧配置将该区域的所有数据恢复到临时区域。 旧配置仍将使用旧配置的资源(堆内存，堆外内存)。 如果这些资源不再可用(例如，该区域的旧配置是堆外的，但您决定不再在JVM上配置堆外内存)，则磁盘存储恢复将失败。

通常的做法是拥有多个离线磁盘存储，因为集群的每个成员通常都有自己的副本。 确保将相同的alter disk-store命令应用于磁盘存储的每个脱机副本。

更改区域配置

磁盘存储脱机时，可以使用cache.xml和API设置使其区域的配置保持最新。 磁盘存储区保留区域配置属性的子集。 (有关保留属性的列表，请参阅alter disk-store)。 如果配置在启动时不匹配，cache.xml和API将覆盖任何磁盘存储设置，磁盘存储将自动更新以匹配。 因此，您无需修改磁盘存储以保持缓存配置和磁盘存储同步，但如果这样做，您将节省启动时间和内存。

例如，要更改磁盘存储中名为“partitioned_region”的区域的初始容量：

gfsh>alter disk-store --name=myDiskStoreName --region=partitioned_region 
--disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir 
--initialCapacity=20

要列出区域的所有可修改设置及其当前值，请运行不指定任何操作的命令：

gfsh>alter disk-store --name=myDiskStoreName --region=partitioned_region
--disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir

从缓存配置和磁盘存储中取出一个区域

如果您决定重命名区域或将其数据拆分为两个完全不同的区域，则可以从应用程序中删除区域。 任何重要的数据重组都可能导致您退出某些数据区域。

这适用于磁盘存储脱机时删除区域。 您通过API调用或gfsh销毁的区域将自动从在线成员的磁盘存储中删除。

在应用程序开发中，当您停止使用持久区域时，也要从成员的磁盘存储区中删除该区域。

注意: 请谨慎执行以下操作。 您正在永久删除数据。

您可以通过以下两种方式之一从磁盘存储区中删除该区域：

• 删除整个磁盘存储文件集。 您的成员将在下次启动时使用一组空文件进行初始化。 从文件系统中删除文件时请务必小心，因为可以指定多个区域使用相同的磁盘存储目录。

• 使用以下命令从磁盘存储中选择性地删除已停止的区域：

  gfsh>alter disk-store --name=myDiskStoreName --region=partitioned_region
  --disk-dirs=/firstDiskStoreDir,/secondDiskStoreDir,/thirdDiskStoreDir --remove

为防止意外数据丢失，Geode会在磁盘存储区域中维护该区域，直到您手动删除它为止。 磁盘存储中与应用程序中的任何区域无关的区域仍会加载到内存中的临时区域，并在成员的生命周期内保留。 系统无法检测您的API是否会在某个时刻创建缓存区域，因此它可以保持临时区域的加载和可用。

配置磁盘可用空间监视

要修改disk-usage-warning-percentage和disk-usage-critical-percentage阈值，请在执行gfsh create disk-store命令时指定参数。

gfsh>create disk-store --name=serverOverflow --dir=c:\overflow_data#20480 \
--compaction-threshold=40 --auto-compact=false --allow-force-compaction=true \
--max-oplog-size=512 --queue-size=10000 --time-interval=15 --write-buffer-size=65536 \
--disk-usage-warning-percentage=80 --disk-usage-critical-percentage=98

默认情况下，磁盘使用率高于80％会触发警告消息。 磁盘使用率高于99％会生成错误并关闭访问该磁盘存储的成员缓存。 要禁用磁盘存储监视，请将参数设置为0。

要查看为现有磁盘存储设置的当前阈值，请使用gfsh describe disk-store命令：

gfsh>describe disk-store --member=server1 --name=DiskStore1

您还可以使用以下DiskStoreMXBean方法API以编程方式配置和获取这些阈值。

• getDiskUsageCriticalPercentage
• getDiskUsageWarningPercentage
• setDiskUsageCriticalPercentage
• setDiskUsageWarningPercentage

通过访问以下统计信息，可以获取磁盘空间使用情况和磁盘空间监视性能的统计信息：

• diskSpace
• maximumSpace
• volumeSize
• volumeFreeSpace
• volumeFreeSpaceChecks
• volumeFreeSpaceTime

请参阅磁盘空间使用情况(DiskDirStatistics).

处理丢失的磁盘存储

本节适用于为至少一个区域保存最新数据副本的磁盘存储。

显示缺少的磁盘存储

使用gfsh，show missing-disk-stores命令列出所有磁盘存储，其中包含其他成员正在等待的最新数据。

对于复制区域，此命令仅列出阻止其他成员启动的缺少成员。 对于分区区域，此命令还列出所有脱机数据存储，即使该区域的其他数据存储处于联机状态，因为它们的脱机状态可能导致缓存操作中的PartitionOfflineExceptions或阻止系统满足冗余。

例子:

gfsh>show missing-disk-stores
          Disk Store ID              |   Host    |               Directory                                           
------------------------------------ | --------- | -------------------------------------
60399215-532b-406f-b81f-9b5bd8d1b55a | excalibur | /usr/local/gemfire/deploy/disk_store1

注意: 您需要在gfsh中连接到JMX Manager才能运行此命令。

注意: 为缺少的磁盘存储列出的磁盘存储目录可能不是您当前为该成员配置的目录。 该列表是从其他正在运行的成员中检索的 - 即报告缺失成员的成员。 它们具有上次丢失的磁盘存储在线时的信息。 如果移动文件并更改成员的配置，则这些目录位置将过时。

磁盘存储通常会丢失，因为它们的成员无法启动。 该成员可能由于多种原因而无法启动，包括：

• 磁盘存储文件损坏。 您可以通过验证磁盘存储来检查这一点。
• 成员的集群配置不正确
• 网络分区
• 驱动器故障

撤消丢失的磁盘存储

本节适用于满足以下两个条件的磁盘存储：

• 具有一个或多个区域或区域存储桶的最新数据副本的磁盘存储。
• 磁盘存储不可恢复，例如删除它们，或者文件已损坏或磁盘发生灾难性故障时。

如果无法在线提供最新的持久化副本，请使用revoke命令告知其他成员停止等待。 撤消存储后，系统会查找剩余的最新数据副本并使用该数据。

注意: 撤消后，磁盘存储无法重新引入系统。

使用gfsh show missing-disk-stores来正确识别需要撤销的磁盘存储。 revoke命令将磁盘存储区ID作为输入，由该命令列出。

例子:

gfsh>revoke missing-disk-store --id=60399215-532b-406f-b81f-9b5bd8d1b55a
Missing disk store successfully revoked

当缓冲区刷新到磁盘时更改

您可以将Geode配置为立即写入磁盘，您可以修改操作系统行为以更频繁地执行缓冲区刷新。

通常，Geode将磁盘数据写入操作系统的磁盘缓冲区，操作系统会定期将缓冲区刷新到磁盘。 增加写入磁盘的频率会降低应用程序或计算机崩溃导致数据丢失的可能性，但会影响性能。 您可以使用Geode的内存中数据备份的另一个选择是提供更好的性能。 通过将数据存储在多个复制区域或配置有冗余副本的分区区域中来执行此操作。 参见地区类型.

修改操作系统的磁盘刷新

您可以更改定期刷新的操作系统设置。 您还可以从应用程序代码执行显式磁盘刷新。 有关这些选项的信息，请参阅操作系统的文档。 例如，在Linux中，您可以通过修改设置/proc/sys/vm/dirty_expire_centiseconds来更改磁盘刷新间隔。 默认为30秒。 要更改此设置，请参阅dirty_expire_centiseconds的Linux文档。

在磁盘写入上修改Geode以刷新缓冲区

您可以让Geode在每次磁盘写入时刷新磁盘缓冲区。 通过在启动Geode成员时在命令行中将系统属性gemfire.syncWrites设置为true来执行此操作。 您只能在启动成员时修改此设置。 设置此项后，Geode使用带有标记“rwd”的Java“RandomAccessFile”，这会使每个文件更新同步写入存储设备。 如果您的磁盘存储位于本地设备上，则仅保证您的数据。 请参阅Java文档中的java.IO.RandomAccessFile。

要修改Geode应用程序的设置，请在启动成员时将其添加到java命令行：

-Dgemfire.syncWrites=true

要修改缓存服务器的设置，请使用以下语法：

gfsh>start server --name=... --J=-Dgemfire.syncWrites=true

为系统恢复和运营管理创建备份

备份是磁盘存储中持久数据的副本。 备份用于将磁盘存储还原到备份时的状态。 根据集群是联机还是脱机，相应的备份和还原过程会有所不同。 在线系统目前正在运行成员。 离线系统没有任何正在运行的成员。

• 系统在线时进行备份
• What a Full Online Backup Saves
• What an Incremental Online Backup Saves
• Disk Store Backup Directory Structure and Contents
• Offline Members—Manual Catch-Up to an Online Backup
• Restore Using a Backup Made While the System Was Online

系统在线时进行备份

gfsh命令backup disk-store为集群中运行的所有成员创建磁盘存储的备份。 备份通过将命令传递给正在运行的系统成员来工作; 因此，成员需要在线才能使此操作成功。 具有持久数据的每个成员都会创建自己的配置和磁盘存储的备份。 备份不会阻止集群中的任何活动，但它确实使用资源。

注意: 请勿尝试使用操作系统的文件复制命令从正在运行的系统创建备份文件。 这将创建不完整且无法使用的副本。

准备备份

• 在进行备份之前，请考虑压缩磁盘存储。 如果关闭自动压缩，您可能需要进行手动压缩以节省备份通过网络复制的数据量。 有关配置手动压缩的更多信息，请参阅手动压缩.

• 在区域操作静止时进行备份，以避免区域数据与异步事件队列（AEQ）或WAN网关发送方（使用持久队列）之间出现不一致的可能性。 导致持久写入区域的区域操作涉及磁盘操作。 关联的队列操作也会导致磁盘操作。 这两个磁盘操作不是以原子方式进行的，因此如果在两个磁盘操作之间进行备份，则备份表示区域和队列中的数据不一致。

• 在系统中的低活动期间运行备份。 备份不会阻止系统活动，但它会在集群中的所有主机上使用文件系统资源，并且可能会影响性能。

• 通过修改成员的cache.xml文件，为每个成员配置要备份的任何其他文件或目录。 应该包含在备份中的其他项目：

  • 应用程序jar文件
  • 启动时应用程序需要的其他文件，例如设置类路径的文件

  例如，要在备份中包含文件myExtraBackupStuff，数据存储的cache.xml文件规范将包括：

  <backup>./myExtraBackupStuff</backup>

  目录以递归方式复制，其中包含从此用户指定的备份中排除的任何磁盘存储。

• 备份到SAN（推荐）或所有成员都可以访问的目录。 确保该目录存在并具有所有成员写入目录和创建子目录的适当权限。

  为备份指定的目录可以多次使用。 每次进行备份时，都会在指定目录中创建一个新子目录，该新子目录的名称代表日期和时间。

  您可以使用以下两个位置之一进行备份：

  • 单个物理位置，例如网络文件服务器，例如：

    /export/fileServerDirectory/gemfireBackupLocation

  • 系统中所有主机的本地目录，例如：

    ./gemfireBackupLocation

• 确保所有具有持久数据的成员都在系统中运行，因为脱机成员无法备份其磁盘存储。 备份命令的输出不会识别托管已脱机的复制区域的成员。

如何进行完整的在线备份

1. 如果禁用自动压缩，则需要手动压缩：

   gfsh>compact disk-store --name=Disk1

2. 运行gfsh backup disk-store命令，指定备份目录位置。 例如：

   gfsh>backup disk-store --dir=/export/fileServerDirectory/gemfireBackupLocation

   输出将列出已成功备份磁盘存储的每个成员的信息。 表格信息将包含成员的名称，其UUID，备份的目录以及成员的主机名。

   任何未能完成备份的在线成员都会在其最高级别的备份目录中留下名为INCOMPLETE_BACKUP的文件。 此文件的存在标识备份文件仅包含部分备份，并且不能在还原操作中使用。

3. 验证备份以供以后恢复使用。 在命令行上，可以使用诸如以下命令检查每个备份

   cd 2010-04-10-11-35/straw_14871_53406_34322/diskstores/ds1
   gfsh validate offline-disk-store --name=ds1 --disk-dirs=/home/dsmith/dir1

如何进行增量备份

增量备份包含自上次备份以来已更改的项目。

要执行增量备份，请使用--baseline-dir参数指定增量备份所基于的备份目录。 例如：

gfsh>backup disk-store --dir=/export/fileServerDirectory/gemfireBackupLocation
--baseline-dir=/export/fileServerDirectory/gemfireBackupLocation/2012-10-01-12-30

输出将与完整在线备份的输出相同。

任何未能完成增量备份的在线成员都会在其最高级别的备份目录中留下名为“INCOMPLETE_BACKUP”的文件。 此文件的存在标识备份文件仅包含部分备份，并且不能在还原操作中使用。 下次进行备份时，将进行完整备份。

什么是完整的在线备份保存

对于具有持久数据的每个成员，完整备份包括以下内容：

• 包含持久区域数据的所有成员的磁盘存储文件。

• cache.xml配置文件中指定的文件和目录为<backup>元素。 例如：

  <backup>./systemConfig/gf.jar</backup>
  <backup>/users/user/gfSystemInfo/myCustomerConfig.doc</backup>

• 使用gfsh deploy命令部署的已部署JAR文件。

• 成员启动时的配置文件。

  • gemfire.properties, 包括成员启动的属性。
  • cache.xml, 如果使用。

  这些配置文件不会自动恢复，以避免干扰更新的配置。 特别是，如果从masterjar文件中提取这些文件，将单独的文件复制到工作区可以覆盖jar中的文件。 如果要备份和还原这些文件，请将它们添加为自定义<backup>元素。

• 一个还原脚本，在Windows上称为“restore.bat”，在Linux上称为“restore.sh”。 此脚本稍后可用于执行还原。 该脚本将文件复制回原始位置。

增量在线备份保存的内容

增量备份可以保存上次备份与当前数据之间的差异。 增量备份仅复制每个成员的基准目录中尚不存在的操作日志。 对于增量备份，还原脚本包含对一个或多个先前链接的增量备份中的操作日志的显式引用。 从增量备份运行还原脚本时，它还会还原作为备份链一部分的先前增量备份的操作日志。

如果基线目录中缺少成员，因为它们处于脱机状态或在基准备份时不存在，则这些成员会将其所有文件的完整备份放入增量备份目录中。

磁盘存储备份目录结构和内容

$ cd thebackupdir
$ ls -R
./2012-10-18-13-44-53:
dasmith_e6410_server1_8623_v1_33892 dasmith_e6410_server2_8940_v2_45565
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892:
config diskstores README.txt restore.sh user
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892/config:
cache.xml
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892/diskstores:
DEFAULT
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892/diskstores/DEFAULT:
dir0
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892/diskstores/DEFAULT/dir0:
BACKUPDEFAULT_1.crf BACKUPDEFAULT_1.drf BACKUPDEFAULT.if
./2012-10-18-13-44-53/dasmith_e6410_server1_8623_v1_33892/user:

离线成员 - 手动追赶在线备份

如果在联机备份期间必须使成员脱机，则可以手动备份其磁盘存储。 手动将此成员的文件带入在线备份框架，并从另一个成员的脚本的副本开始手动创建还原脚本：

1. 复制此成员的备份成员的目录结构。
2. 根据需要重命名目录以反映此成员的特定备份，包括磁盘存储名称。
3. 清除除还原脚本以外的所有文件。
4. 复制此成员的文件。
5. 修改还原脚本以适用于此成员。

使用系统在线时进行的备份还原

restore.sh或restore.bat脚本将文件复制回原始位置。

1. 缓存成员脱机且系统关闭时，还原磁盘存储。
2. 查看每个还原脚本以查看它们将文件放在何处并确保目标位置准备就绪。 还原脚本将拒绝复制具有相同名称的文件。
3. 在发起备份的主机上运行每个还原脚本。

还原将这些文件复制回原始位置：

• 包含持久区域数据的所有商店的磁盘存储文件。
• 您已配置为在cache.xml`` <backup>元素中备份的任何文件或目录。

缓存和区域快照

快照允许您保存区域数据并在以后重新加载。 典型的用例是将数据从一个环境加载到另一个环境，例如从生产系统捕获数据并将其移动到较小的QA或开发系统中。

实际上，您可以将数据从一个集群加载到另一个集群中。 管理员导出区域或整个缓存（多个区域）的快照，然后使用RegionSnapshotService或CacheSnapshotService接口以及Region.getSnapshotService或Cache.getSnapshotService方法将快照导入另一个区域或集群。

快照文件是一个二进制文件，包含来自特定区域的所有数据。 二进制格式包含序列化的键/值对，并支持PDX类型注册表以允许PDX数据的反序列化。 快照可以直接导入区域或逐个读取，以便进一步处理或转换为其他格式。

注意: 之前的Region.loadSnapshot和Region.saveSnapshot API已被弃用。 以此格式编写的数据与新API不兼容。

• 用法和性能说明

  通过了解缓存和区域快照的执行方式来优化缓存和区域快照功能

• 导出缓存和区域快照

  要将Geode缓存或区域数据保存到稍后可以加载到另一个集群或区域的快照，请使用cache.getSnapshotService.save API，region.getSnapshotService.save API或gfsh命令行界面 （导出数据）。

• 导入缓存和区域快照

  要导入先前导出到另一个集群或区域的Geode缓存或区域数据快照，请使用cache.getSnapshotService.loadAPI，region.getSnapshotService.loadAPI或gfsh命令行界面（import data）。

• 导入或导出期间过滤条目

  您可以通过在导入或导出区域或缓存期间过滤条目来自定义快照。

• 以编程方式读取快照

  您可以逐个条目地读取快照，以便进一步处理或转换为其他格式。

用法和性能说明

通过了解缓存和区域快照的执行方式来优化缓存和区域快照功能

缓存一致性和并发操作

导入和导出区域数据是一种管理操作，某些同时运行时条件可能导致导入或导出操作失败，例如重新平衡分区区域存储桶或遇到网络分区事件时。 此行为是预期的，您应该重试该操作。 重做导出会覆盖不完整的快照文件，并重做导入会更新部分导入的数据。

快照功能不保证一致性。 快照导入或导出期间的并发缓存操作可能导致数据一致性问题。 如果快照一致性很重要，我们建议您在导出和导入之前使应用程序脱机，以提供安静的时间段以确保快照中的数据一致性。

例如，导出期间对区域条目的修改可能会导致快照包含一些但不是所有更新。 如果在导出期间条目{A，B}更新为{A’，B’}，则快照可以包含{A，B’}，具体取决于写入顺序。 此外，导入期间对区域条目的修改可能导致缓存中的更新丢失。 如果区域包含条目{A，B}且快照包含{A’，B’}，则在导入完成后，并发更新{A ，B }可能导致包含{A *，B’}的区域。

默认行为是在调用快照操作的节点上执行所有I/O操作。 如果该区域是分区区域，这将涉及通过网络收集或分散数据。

性能注意事项

使用数据快照功能时，请注意以下性能注意事项：

• 导入和导出缓存或区域快照会导致额外的CPU和网络负载。 您可能需要根据应用程序和基础结构增加CPU容量或网络带宽。 此外，如果导出已配置为溢出到磁盘的区域，则可能需要其他磁盘I/O才能执行导出。
• 导出分区区域数据时，请分配额外的堆内存，以便执行导出的成员可以缓冲从其他缓存成员收集的数据。 除了支持应用程序或缓存所需的任何配置外，还要为每个成员分配至少10MB的堆内存。

导出缓存和区域快照

要将Geode缓存或区域数据保存到稍后可以加载到另一个集群或区域的快照，请使用cache.getSnapshotService.save API，region.getSnapshotService.save API或gfsh命令行界面 (export data)。

如果在导出期间发生错误，则导出将暂停并取消快照操作。 暂停导出的典型错误包括完整磁盘，文件权限问题和网络分区等方案。

导出缓存快照

导出整个缓存时，它会将缓存中的所有区域作为单独的快照文件导出到目录中。 如果未指定目录，则默认为当前目录。 为每个区域创建快照文件，导出操作使用以下约定自动命名每个快照文件名：

snapshot-<region>[-<subregion>]*

当导出操作写入快照文件名时，它会用短划线（’ - ‘）替换区域路径中的每个正斜杠（’/‘）。

使用 Java API:

File mySnapshotDir = ...
Cache cache = ...
cache.getSnapshotService().save(mySnapshotDir, SnapshotFormat.GEMFIRE);

可选,您可以在导出期间在快照条目上设置过滤器。 有关示例，请参阅导入或导出期间的过滤条目。

导出区域快照

您还可以使用以下API或gfsh命令导出特定区域：

Java API:

File mySnapshot = ...
Region<String, MyObject> region = ... 
region.getSnapshotService().save(mySnapshot, SnapshotFormat.GEMFIRE);

gfsh:

打开gfsh提示符。 连接到Geode集群后，在提示符下键入：

gfsh>export data --region=Region --file=FileName.gfd --member=MemberName

其中Region对应于要导出的区域的名称，FileName（必须以.gfd结尾）对应于导出文件的名称，MemberName对应于承载该区域的成员。 例如：

gfsh>export data --region=region1 --file=region1_2012_10_10.gfd --member=server1

快照文件将写在远程成员上的--fileargument指定的位置。 例如，在上面的示例命令中，region1_2012_10_10.gfd文件将写在server1的工作目录中。 有关此命令的更多信息，请参阅导出数据.

使用选项导出示例

这些示例显示如何包含用于导出分区区域的parallel选项。 请注意，parallel选项采用目录而不是文件; 见export data for details.

Java API:

File mySnapshotDir = ...
Region<String, MyObject> region = ... 
SnapshotOptions<Integer, MyObject> options = 
 region.getSnapshotServive.createOptions().setParallelMode(true);
region.getSnapshotService().save(mySnapshotDir, SnapshotFormat.GEMFIRE, options);

gfsh:

上面的Java API示例实现了与以下gfsh命令相同的目的：

gfsh>export data --parallel --region=region1 --dir=region1_2012_10_10 --member=server1

导入缓存和区域快照

要导入先前导出到另一个集群或区域的Geode缓存或区域数据快照，请使用cache.getSnapshotService.loadAPI，region.getSnapshotService.load API或gfsh命令行界面 (import data)。

导入要求

在导入区域快照之前：

• 确保正确配置了缓存。 配置所有已注册的PdxSerializers，DataSerializers和Instantiators; 创建区域; 并确保类路径包含任何必需的类。
• 导入包含PDX类型的快照时，必须等到导出的类型定义导入缓存之后才能插入导致类型冲突的数据。 建议您在插入数据之前等待导入完成。

导入限制

在导入期间，不会调用CacheWriter和CacheListener回调。

如果在导入期间发生错误，则导入将暂停，并且该区域将包含一些但不是所有快照数据。

导入后，缓存客户端的状态不确定。 客户端缓存中的数据可能与导入的数据不一致。 导入期间使客户端脱机，并在导入完成后重新启动它。

导入缓存快照

导入缓存快照时，快照文件将导入到快照导出期间使用的同一区域（由名称确定的匹配）。 导入缓存时，将位于目录中的所有快照文件导入缓存。 API尝试加载指定目录中的所有文件。

Java API:

File mySnapshotDir = ...
Cache cache = ...
cache.getSnapshotService().load(mySnapshotDir, SnapshotFormat.GEMFIRE);

导入区域快照

Java API:

File mySnapshot = ...
Region<String, MyObject> region = ...
region.getSnapshotService().load(mySnapshot, SnapshotFormat.GEMFIRE);

gfsh:

打开gfsh提示符。 连接到Geode集群后，在提示符下键入：

gfsh>import data --region=Region --file=FileName.gfd --member=MemberName

其中 Region 对应于要将数据导入的区域的名称; FileName （必须以.gfd结尾）对应于要导入的文件的名称; 和 MemberName 对应一个托管该区域的成员。 例如：

gfsh>import data --region=region1 --file=region1_2012_10_10.gfd --member=server2

在导入之前，快照文件必须已驻留在--file参数中指定的位置的指定成员上。

有关此命令的更多信息，请参阅导入数据. 有关如何使用其他选项调用此命令的示例，请参阅使用选项导出示例.

导入或导出期间过滤条目

您可以通过在导入或导出区域或缓存期间过滤条目来自定义快照。

例如，使用过滤器将数据导出限制到特定日期范围。 如果在导入或导出缓存时设置过滤器，则过滤器将应用于缓存中的每个区域。

以下示例按偶数键过滤快照数据。

File mySnapshot = ...
Region<Integer, MyObject> region = ...
SnapshotFilter<Integer, MyObject> even = new SnapshotFilter<Integer, MyObject>() {
  @Override
  public boolean accept(Entry<Integer, MyObject> entry) {
    return entry.getKey() % 2 == 0;
  }
};
RegionSnapshotService<Integer, MyObject> snapsrv = region.getSnapshotService();
SnapshotOptions<Integer, MyObject> options = snapsrv.createOptions().setFilter(even);
// only save cache entries with an even key
snapsrv.save(mySnapshot, SnapshotFormat.GEMFIRE, options);

以编程方式读取快照

您可以逐个条目地读取快照，以便进一步处理或转换为其他格式。

以下是处理先前生成的快照文件中的条目的快照阅读器的示例。

File mySnapshot = ...
SnapshotIterator<String, MyObject> iter = SnapshotReader.read(mySnapshot);
try {
  while (iter.hasNext()) {
    Entry<String, MyObject> entry = iter.next();
    String key = entry.getKey();
    MyObject value = entry.getValue();
    System.out.println(key + " = " + value);
  }
} finally {
  iter.close();
}

区域压缩

本节介绍区域压缩，其优点和用法。

减少Geode内存消耗的一种方法是在您的区域中启用压缩。 Geode允许您使用可插拔压缩器（压缩编解码器）压缩内存中的区域值。 Geode包含Snappy压缩器作为内置压缩编解码器; 但是，您可以为每个压缩区域实现和指定不同的压缩器。

怎样得到压缩

在区域中启用压缩时，存储在该区域中的所有值都将在内存中进行压缩。 密钥和索引不会被压缩。 放入内存高速缓存时会压缩新值，并在从高速缓存读取时解压缩所有值。 持久化到磁盘时不会压缩值。 在通过线路发送给其他对等成员或客户端之前，将对值进行解压缩。

启用压缩后，将压缩区域中的每个值，并将每个区域条目压缩为单个单元。 无法压缩条目的各个字段。

您可以在同一缓存中混合使用压缩区域和非压缩区域。

• 使用压缩的指南

  本主题描述在决定是否使用压缩时要考虑的因素。

• 如何在区域中启用压缩

  本主题介绍如何在您所在的区域启用压缩。

• 使用压缩器

  使用区域压缩时，您可以使用Geode附带的默认Snappy压缩器，也可以指定自己的压缩器。

• 压缩和非压缩区域的性能比较

  压缩区域与非压缩区域的比较性能可以根据区域的使用方式以及区域是否托管在内存绑定的JVM中而变化。

使用压缩的指南

本主题描述在决定是否使用压缩时要考虑的因素。

在决定是否在您所在的地区启用压缩时，请查看以下准则：

• 当JVM内存使用率过高时使用压缩. 压缩允许您在内存中存储更多区域数据，并减少昂贵的垃圾收集周期数，以防止JVM在内存使用率较高时耗尽内存。

  要确定JVM内存使用率是否很高，请检查以下统计信息：

  • vmStats>freeMemory
  • vmStats->maxMemory
  • ConcurrentMarkSweep->collectionTime

  如果可用内存量经常降至20％-25％以下或者垃圾收集周期的持续时间通常偏高，那么托管在该JVM上的区域是启用压缩的良好候选者。

• 考虑区域条目中字段的类型和长度. 由于压缩是分别对每个条目执行的（而不是整个区域），因此请考虑单个条目中重复数据的可能性。 重复的字节更容易压缩。 此外，由于区域条目在被压缩之前首先被序列化为字节区域，因此数据可能压缩的程度取决于整个条目中的重复字节的数量和长度，而不仅仅是单个字段。 最后，条目越大，压缩越有可能获得良好的结果，因为重复字节和一系列重复字节的可能性增加。

• 考虑您要压缩的数据类型. 存储的数据类型对数据压缩的程度有很大影响。 字符串数据通常比数字数据压缩得更好，因为字符串字节更有可能重复; 然而，情况可能并非总是如此。 例如，包含两个短的唯一字符串的区域条目在压缩时可能无法提供与另一个包含大量整数值的区域条目相同的内存节省。 简而言之，在评估压缩区域的潜在收益时，请考虑单个序列化区域条目具有重复字节的可能性，更重要的是一系列重复字节的长度。 此外，已经压缩的数据（例如JPEG格式文件）实际上可以使用更多内存。

• 如果要存储大文本值，请压缩. 如果要在Geode中存储大型文本值（如JSON或XML）或Blob，压缩将受益于压缩，这将是有益的。

• 考虑被查询的字段是否已编入索引. 您可以查询压缩区域; 但是，如果您要查询的字段尚未编入索引，则必须先解压缩字段，然后才能将其用于比较。 简而言之，在查询非索引字段时，可能会产生一些查询性能成本。

• 存储在压缩区域中的对象必须是可序列化的. 压缩仅对字节数组进行操作，因此存储在压缩区域中的对象必须是可序列化和可反序列化的。 对象可以实现Serializable接口，也可以使用其他Geode序列化机制（例如PdxSerializable）。 实施者应始终注意，当启用压缩时，放入区域的对象实例在取出时将不是同一个实例。 因此，当将包含对象放入区域并从区域中取出时，瞬态属性将失去其值。

• 压缩区域将默认启用克隆. 设置压缩器然后禁用克隆会导致异常。 这些选项是不兼容的，因为压缩/序列化然后解压缩/反序列化的过程将导致创建的对象的不同实例，并且可能被解释为克隆该对象。