事实：当群集内存空间不足时，Ignite的处理方式

如果存储空间即将用完，Ignite可以水平扩展以存储更多由应用程序和服务生成的数据。这是Ignite的基本功能之一，因此增加资源是最简单的处理方法。但是实际上，在大多数情况下，群集无法立即扩展。它通常是一个Ignite群集，具有用于应用程序的固定内存容量。添加更多资源可能是一项艰巨而持续的任务。

下面将介绍几个功能，以便即使在内存成为稀缺资源时也可以保持群集的稳定运行。

配置Ignite退出策略以避免内存不足问题

数据出口是一种经​​典的机制，可以防止过多的内存使用。它监视正在使用的内存空间，并在内存使用率超过阈值时删除多余的数据，从而避免出现内存不足的问题。

Ignite支持多种策略。当达到最大数据区域大小时，这些策略将最终从内存中清除最近最少使用的页面。以下代码段显示了如何为自定义数据区域启用DataPageEvictionMode.RANDOM_2_LRU策略：

DataStorageConfiguration storageCfg = new DataStorageConfiguration();
DataRegionConfiguration regionCfg = new DataRegionConfiguration();
regionCfg.setName("20GB_Region");
// 500 MB initial region size (RAM).
regionCfg.setInitialSize(500L * 1024 * 1024);
// 20 GB maximum region size (RAM).
regionCfg.setMaxSize(20L * 1024 * 1024 * 1024);
// Enabling RANDOM_2_LRU eviction for this region.
regionCfg.setPageEvictionMode(DataPageEvictionMode.RANDOM_2_LRU);

可以为纯内存群集和在外部（例如Oracle或MySQL）中存储数据的群集配置退出策略。启用Ignite本机持久性的群集将忽略退出策略配置，并使用页面替换算法来控制它。使用内存空间。

如果将Ignite退出策略用作低内存方案的预防措施，则Ignite仅在以下情况下才会自动还原已退出的数据：a）通过CacheStore接口连接的外部具有该数据的副本， b）应用程序使用Ignite的键值API读取数据。在其他情况下，开发人员需要自己重新加载数据。

使用Ignite的本机持久性仅读取磁盘上的数据

Ignite的多层存储可以将本机持久性配置为磁盘层。启用本机持久性后，它将在磁盘上存储所有数据（包括索引），然后开发人员可以决定要在内存中缓存多少数据。即使数据不在内存中，应用程序也可以访问仅存储在磁盘上的数据。

本机持久性的配置非常简单。当DataRegionConfiguration.persistenceEnabled属性配置为true时，Ignite会将与该数据区域相关的所有数据保存在磁盘上：

DataStorageConfiguration storageCfg = new DataStorageConfiguration();
DataRegionConfiguration regionCfg = new DataRegionConfiguration();
regionCfg.setName("20GB_Region");
// 500 MB initial region size (RAM).
regionCfg.setInitialSize(500L * 1024 * 1024);
// 20 GB maximum region size (RAM).
regionCfg.setMaxSize(20L * 1024 * 1024 * 1024);
// Enable Ignite Native Persistence for all the data from this data region.
regionCfg.setPersistenceEnabled(true);

因为在数据区域上配置了持久性，所以只需要为可能溢出的缓存和表设置持久性。一般来说，应该为所有数据区域打开持久性，然后决定是否为一个或多个数据子集关闭持久性。

凭借本机持久性，Ignite不会对群集施加API限制。相反，如果在内存中未找到任何记录，则所有Ignite API（包括SQL和ScanQueries）都可以从磁盘中查找记录。此功能消除了由于应用程序退出而导致的重新加载数据的负担，并且Ignite还可以避免过多的内存空间消耗。尽管该算法会自动从内存中删除记录，但它不会触及磁盘上的副本，只要应用程序需要它，就可以将其拉回到内存层。

使用更大的堆和非暂停的垃圾收集器来消除Java堆问题

Ignite将所有数据（包括索引）存储在其中。该内存通常称为页面内存（由于其组织和管理）。像现代操作系统一样，Ignite将空间分成固定大小的页面并将数据存储在这些页面中。如前所述，如果可以耗尽堆外内存，则可以使用退出策略和本机持久性。

同时，与任何Java中间件一样，Ignite使用Java堆作为应用程序请求的对象和数据的临时存储。例如，当通过键值或SQL调用检索数据时，将在Java堆中维护请求的堆外数据的副本，并将基于堆的结果集收集到的垃圾传输到应用程序。

如果Java堆空间开始用尽，JVM可能不会生成内存溢出异常，该异常会导致集群节点发生故障，但是会在集群节点上观察到很长时间的垃圾回收暂停。暂停将影响群集的性能，并可能导致无响应的节点发生故障。

解决此问题的常规方法是分配足够大的Java堆来处理生产负载下应用程序的所有请求。堆大小取决于场景，每个群集节点可以小至3GB或大至30GB。

高吞吐量和低延迟的应用程序通常需要更大的Java堆。对于此类应用程序，您还可以考虑使用不会暂停的Java垃圾收集器，例如Azul Zing JVM的，无论堆大小如何，该垃圾收集器都将显示可靠且一致的性能结果。

使用SQL内存配额使Java堆使用情况可预测

SQL查询是Ignite中最消耗Java的堆操作之一。一个查询可以扫描数千个表记录，对内存中的数百条记录进行分组和排序，并关联存储在多个表中的数据。下图显示了查询执行过程的所有步骤，计算阶段使用了最多的Java堆：

通常来说，在许多Ignite环境中，最终Java堆大小受基于SQL的操作的要求影响，并且上一节中有关较大Java堆的建议也适用于SQL。但是，您也可以配置内存配额，以更好地管理Java堆空间的使用。

内存配额是为SQL设计的，可以在GridGain社区版和其他版本的GridGain中使用。以下配置示例显示了如何为每个群集节点设置配额：

// Creating Ignite configuration.
IgniteConfiguration cfg = new IgniteConfiguration();
// Defining SQL configuration.
SqlConfiguration sqlCfg = new SqlConfiguration();
// Setting the global quota per cluster node.
// All the running SQL queries combined cannot use more memory as set here.
sqlCfg.setSqlGlobalMemoryQuota("500M");
// Setting per query quota per cluster node.
// A single running SQL query cannot use more memory as set below.
sqlCfg.setSqlQueryMemoryQuota("40MB");
// If any of the quotas is exceeded, Ignite will start offloading result sets to disk.
sqlCfg.setSqlOffloadingEnabled(true);
cfg.setSqlConfiguration(sqlCfg);

使用此配置，单个Ignite群集节点可以使用不超过500MB的堆空间来满足运行SQL查询的需求。另外，SqlConfiguration.setSqlQueryMemoryQuota指定Ignite不允许任何单个SQL查询消耗超过40MB的堆。最后，如果超出了每个查询或全局配额，则在禁用磁盘卸载功能的情况下，Ignite开始将查询的结果集卸载到磁盘层（例如，与任何关系一样，启用SqlConfiguration.setSqlOffloadingEnabled参数），超出配额。查询将终止并引发异常。

因此，建议使用磁盘卸载功能来启用配额，尤其是在应用程序需要对数据执行排序（SORT BY）或分组（DISTINCT，GROUP BY）或使用子查询或关联来运行时，尤其如此复杂的查询。

摘要

本文讨论的所有技术要点都可以解决内存消耗过多的问题，但是应该注意，一旦触发这些功能，它将影响应用程序的性能。群集将更积极地使用磁盘（用于页面替换的本地持久性，以及将SQL结果集卸载到磁盘上），或者从群集中删除记录以使记录不可用（退出策略）。

本文来自电脑杂谈，转载请注明本文网址：
http://www.pc-fly.com/a/shoujiruanjian/article-318980-1.html