Apache Ignite 2.17本地部署putAll()写入性能随任务递增急剧下降的优化咨询

从你描述的情况来看，这个性能衰减确实非常棘手——刚开始70秒左右的写入耗时，到后期直接飙升到3000多秒，而且还要处理700个任务，这完全没法支撑业务需求。咱们一步步拆解下可能的问题根源，再结合你的C++瘦客户端、本地单节点的限制，给出针对性的优化方向：

一、先搞懂性能持续恶化的核心诱因 #

从你的数据趋势（耗时随任务数指数级增长）来看，大概率不是单次写入的逻辑问题，而是随着总数据量累积，系统资源瓶颈（尤其是磁盘IO、内存）被逐渐放大，再加上Ignite服务端的一些默认/不合理配置雪上加霜：

1. 持久化层的IO压力过载：启用了Ignite持久化后，所有写入都会先写WAL（Write-Ahead Log），再刷到数据页；当数据量越来越大，WAL归档、Checkpoint（将内存脏页刷到磁盘）的开销会急剧上升，尤其是用机械硬盘的话，随机IO的短板会被无限放大。
2. 内存资源不足导致频繁刷盘：你的Ignite配置里没有设置数据区域的maxSize，如果机器内存有限，Ignite会不断把内存中的数据刷到磁盘，触发大量随机IO，拖慢写入速度。
3. 不必要的事件监听拖垮CPU：你配置里开启了大量缓存事件（比如EVT_CACHE_OBJECT_PUT），每一条写入都会触发事件处理，数据量上去后这部分CPU开销会非常恐怖。
4. 单节点资源竞争：4个计算引擎+Ignite服务端挤在同一台机器上，CPU、内存、磁盘IO的竞争会随着任务数增加越来越激烈。

二、针对性优化方案（贴合你的C++瘦客户端场景） #

因为C++瘦客户端没法用DataStreamer，咱们只能从Ignite服务端配置、客户端写入策略、系统资源调优三个方向入手：

1. Ignite服务端配置紧急调优 #

这部分是见效最快的，先改这几个点：

（1）修正数据区域与持久化参数

你的当前配置没有设置数据区域的最大内存，而且Checkpoint缓冲区太小，直接修改defaultDataRegionConfiguration：

<property name="defaultDataRegionConfiguration">
    <bean class="org.apache.ignite.configuration.DataRegionConfiguration">
        <property name="name" value="Default_Region"/>
        <property name="persistenceEnabled" value="true"/>
        <!-- 根据机器内存设置，比如机器有16G内存，给10G作为数据区域（off-heap内存） -->
        <property name="maxSize" value="#{10 * 1024 * 1024 * 1024}"/>
        <!-- 增大Checkpoint页缓冲区，避免满了阻塞写入，比如改成256M -->
        <property name="checkpointPageBufferSize" value="#{256 * 1024 * 1024}"/>
        <!-- 开启页预加载，提升大内存区域的访问效率 -->
        <property name="pageEvictionMode" value="RANDOM_LRU"/>
        <property name="evictionThreshold" value="0.8"/>
    </bean>
</property>

同时调整WAL相关参数，降低IO压力：

<property name="walMode" value="BACKGROUND"/> <!-- 异步刷WAL到磁盘，比LOG_ONLY快，注意：节点宕机可能丢数据，本地测试可开启 -->
<property name="walSegmentSize" value="#{128 * 1024 * 1024}"/> <!-- 增大WAL段大小，减少段切换开销 -->
<property name="walSegments" value="40"/> <!-- 增加WAL段数量，避免段归档阻塞写入 -->
<!-- 建议把WAL目录和数据目录放在不同的磁盘分区，彻底避免IO竞争 -->
<property name="walPath" value="/path/to/separate/disk/wal"/>
<property name="walArchivePath" value="/path/to/separate/disk/wal/archive"/>

（2）关闭不必要的事件监听

把includeEventTypes整个删掉或者只保留绝对必要的事件——这些事件对业务写入毫无帮助，只会消耗CPU：

<!-- 直接移除这个includeEventTypes配置块，或者注释掉所有缓存相关事件 -->
<!-- <property name="includeEventTypes">
    <list>
        ... 所有事件都删掉 ...
    </list>
</property> -->

（3）调整线程池大小

你设置的publicThreadPoolSize和systemThreadPoolSize都是100，单节点完全用不上这么多线程，反而会导致频繁的上下文切换，改成和CPU核心数匹配的数值（比如8核CPU设为16）：

<property name="publicThreadPoolSize" value="16"/>
<property name="systemThreadPoolSize" value="16"/>

2. C++客户端写入策略优化 #

（1）调整putAll批次大小

你当前用的2500条/批可能太小了，C++瘦客户端的putAll是通过网络传输批次，太小的批次会增加往返次数。可以测试调整到5000、10000条/批（注意不要超过Ignite服务端的clientConnectorConfiguration里的socketSendBufferSize和socketReceiveBufferSize限制，默认是64K，可同步调大到128K或256K）。

（2）复用客户端连接

确保每个计算引擎只初始化一次Ignite客户端连接，不要每个任务都新建连接——连接建立的TCP握手、认证开销累积起来也很可观。

（3）异步写入重叠计算与IO

如果C瘦客户端支持异步putAll（Ignite 2.17的C瘦客户端是有异步API的，比如PutAllAsync），改成异步写入：计算引擎在处理下一个任务的计算逻辑时，后台并行处理上一个任务的写入，这样可以把计算和IO的时间重叠，整体减少任务总耗时。注意控制并发异步请求的数量（比如最多同时发2-3个异步写入），避免把服务端压垮。

3. 系统级资源调优 #

（1）换成SSD硬盘

这是最立竿见影的优化——机械硬盘的随机IO性能只有SSD的1/100，Ignite持久化的WAL、Checkpoint都是随机IO，换成SSD后写入速度至少能提升5-10倍。

（2）优化磁盘与内存参数

• Linux系统下，给Ignite数据目录和WAL目录挂载的磁盘开启noatime和nodiratime，减少文件系统的元数据写入：

  # 临时生效
  mount -o remount,noatime,nodiratime /你的磁盘挂载点
  # 永久生效，修改/etc/fstab
  UUID=xxx /mountpoint ext4 defaults,noatime,nodiratime 0 0
  

• 确保Ignite服务端的JVM堆内存不要太大（因为用了off-heap数据区域），比如设置-Xms2g -Xmx4g即可，剩下的内存留给off-heap数据区域和系统。

（3）隔离资源竞争

如果机器CPU核心足够，给Ignite服务端和4个计算引擎设置CPU亲和性，让它们绑定到不同的核心组，避免CPU调度的竞争。比如用taskset命令：

# 把Ignite绑定到0-3核心
taskset -c 0-3 ./ignite.sh your-config.xml
# 每个计算引擎绑定到不同的核心组，比如引擎1绑定4-5，引擎2绑定6-7，以此类推
taskset -c 4-5 ./your-compute-engine

4. 额外排查方向 #

• 监控Ignite运行状态：用Ignite的ignitevisorcmd.sh工具连接到节点，查看：
  • cache -m：查看缓存的写入延迟、排队请求数
  • top：查看节点的CPU、内存、磁盘IO使用率
  • checkpoint -s：查看Checkpoint的频率和耗时，如果每次Checkpoint都要几十秒，说明磁盘IO瓶颈严重
• 设置数据过期时间：如果旧任务的数据不需要长期保留，给缓存设置TTL，让Ignite自动清理旧数据，释放内存和磁盘空间：

  <!-- 在缓存配置里添加（如果是通过XML配置缓存的话） -->
  <bean class="org.apache.ignite.configuration.CacheConfiguration">
      <property name="name" value="your-cache-name"/>
      <!-- 设置每条数据的过期时间为2小时 -->
      <property name="expiryPolicyFactory">
          <bean class="org.apache.ignite.cache.expiry.CreatedExpiryPolicyFactory">
              <constructor-arg>
                  <bean class="javax.cache.expiry.Duration">
                      <constructor-arg value="HOURS"/>
                      <constructor-arg value="2"/>
                  </bean>
              </constructor-arg>
          </bean>
      </property>
  </bean>
  

三、总结优化优先级 #

先做见效快、改动小的操作：

1. 关闭Ignite的事件监听配置
2. 调整数据区域的maxSize和Checkpoint缓冲区大小
3. 测试增大putAll的批次大小
4. 换成SSD硬盘（如果还没换的话）

这些操作应该能快速把性能拉回可接受的水平，之后再通过监控工具定位剩余的瓶颈，逐步优化。

内容来源于stack exchange