我正在尝试Apache Ignite的本地持久性。我的设置目前是本地的单节点集群。我通过在我的数据区域
中添加这个属性来启用它<property name="persistenceEnabled" value="true"/>
我的完整数据区域配置如下
<bean class="org.apache.ignite.configuration.DataRegionConfiguration">
<property name="name" value="dr.local.input.trade"/>
<property name="persistenceEnabled" value="true"/>
<property name="metricsEnabled" value="true"/>
<property name="initialSize" value="#{200 * 1024 * 1024}"/>
<property name="maxSize" value="#{500 * 1024 * 1024}"/>
<property name="pageEvictionMode" value="RANDOM_2_LRU"/>
</bean>
现在条目正在被持久化，即如果我关闭Ignite并重新启动它，那么我的数据就会回到缓存内。
我看到显著的性能下降。与非持久化数据区域相比，put操作延迟增加了约35%。我已经参考了Ignite持久性调优页面。从中我挑选出以下属性及其属性
| 属性 | 值 | 细胞膜模式 | LOG_ONLY |
|---|---|
| walCompactionLevel | 3 |
| walCompationEnabled | 对 |
| writeThrottlingEnabled | 对 |
| checkpointBufferSize | 512 mb |
| checkpointFrequency | 5分钟 |
说到写操作时可能出现的性能下降
与纯内存模式相比，更新时发生以下磁盘交互:
除了在RAM中修改页面之外，Ignite还需要根据您的WAL模式提供一致性保证，但除非它没有被禁用，否则每次更新都必须写入WAL文件。尚未在磁盘上刷新数据;修改只发生在内存+ WAL记录被写入。
一旦RAM中有太多脏页，或者发生超时，Ignite启动检查点进程，将磁盘上的脏页刷新到磁盘上的分区文件。
如果WAL变得太大，Ignite可能会通过将它们复制到WAL存档来执行段旋转，以释放新的WAL更新的空间。
正如您所看到的，至少有3个主要的磁盘相关操作，这意味着为/wal、/walarchive和/db挂载的文件夹拥有真正快速的磁盘是至关重要的。同样，这完全取决于您的用例，但通常强烈建议为与wall相关的活动使用最快的可用磁盘。
读取时可能出现的性能下降。
同样，这取决于场景，但是如果您可以将所有数据放在内存中(就像在启用持久性之前一样)，则不会看到任何性能差异。
应该注意的是，重启后，在启动时RAM中不会有数据，Ignite必须先预加载它们，即做一个预热。
但是，如果数据多于配置的数据区域大小，则会发生页替换，在磁盘之间来回轮换数据。更糟糕的情况是:假设您有一个10 GB RAM数据区域和11 GB数据集。并且您希望按字母顺序扫描数据两次。
内存中没有数据;想象一下你重新开始。Ignite开始从磁盘读取数据，并在内存中填充数据页。想象一下，在字母W之后，我们的内存数据集变得满了，并且需要页面旋转来加载剩余的W- z数据。在这种情况下，需要清除最旧的页面——这意味着，例如，A-D块需要转到磁盘来加载W-Z数据。你的内存数据集现在是W-Z E-V之类的。如果我们要进行相同的扫描查询，整个数据集需要以类似的方式替换。
启用持久性度量。
检查您的数据区域配置中是否有以下属性，这里有更多详细信息。
<property name="metricsEnabled" value="true"/>
同样，也不需要
<property name="pageEvictionMode" value="RANDOM_2_LRU"/>
仅用于非持久区域。