升级650GB大型Solr索引时IndexUpgrader触发Java堆内存不足错误

我完全理解处理这么大的Solr索引升级时遇到内存问题有多头疼——650GB的索引规模加上跨大版本（8.6.0→9.8.0）的格式转换，确实会给JVM堆内存带来极大压力，你遇到的错误本质是IndexUpgrader执行forceMerge操作时，堆内存不足以支撑大段数据的重写与合并。下面是针对性的解决方案：

一、紧急调整JVM内存参数（最直接的修复） #

你当前设置的-Xmx8G对于650GB的索引来说远远不够，优先尝试以下调整：

1. 大幅提升堆内存上限 #

建议直接将堆内存提升至32G~64G（前提是服务器物理内存充足，堆内存不要超过物理内存的70%，避免触发swap导致性能骤降）。修改后的命令：

java -Xmx32G -cp lucene-core-9.8.0.jar:lucene-backward-codecs-9.8.0.jar \
org.apache.lucene.index.IndexUpgrader \
-delete-prior-commits -verbose /mnt/solr/gcp_data/data/index

注意：这里我替换成了9.8.0版本的Lucene依赖包，你之前用8.11.4的包会先把索引升级到8.11.4格式，之后还要再升级一次到9.8.0，多了不必要的中间步骤，直接用目标版本的Jar包能减少内存开销。

2. 搭配高效垃圾收集器 #

添加-XX:+UseG1GC参数，G1垃圾收集器在处理大内存堆时，内存回收效率和碎片控制都远优于默认的ParallelGC，能有效减少内存堆积：

java -Xmx32G -XX:+UseG1GC -cp lucene-core-9.8.0.jar:lucene-backward-codecs-9.8.0.jar \
org.apache.lucene.index.IndexUpgrader \
-delete-prior-commits -verbose /mnt/solr/gcp_data/data/index

二、拆分合并压力（堆内存无法大幅提升时的备选） #

如果服务器物理内存有限，没法给到32G以上的堆内存，可以通过拆分合并步骤来降低单次内存消耗：

1. 先升级格式，再单独执行合并 #

IndexUpgrader默认会把索引合并到1个段，这是内存压力最大的环节。你可以先跳过强制合并，只完成格式升级，之后再通过Solr API单独执行合并：

# 先升级索引格式，不强制合并到1个段
java -Xmx16G -XX:+UseG1GC -cp lucene-core-9.8.0.jar:lucene-backward-codecs-9.8.0.jar \
org.apache.lucene.index.IndexUpgrader \
-delete-prior-commits -verbose -merge-segments 10 /mnt/solr/gcp_data/data/index

启动Solr 9.8.0后，通过API执行低内存压力的合并：

curl -X POST "http://your-solr-host:8983/solr/your-core/update?optimize=true&maxSegments=1&waitFlush=true&waitSearcher=true"

2. 分批次处理索引 #

如果上述方法仍有压力，可以把650GB的大索引拆分成多个小索引（比如按时间范围、业务分区），分别升级后再合并，不过这个操作需要额外脚本辅助，适合有一定Solr运维经验的场景。

三、辅助优化与注意事项 #

1. 确保磁盘资源充足：IndexUpgrader升级时会生成临时文件，需要至少和原索引大小相当的空闲磁盘空间（650GB以上），避免磁盘空间不足导致写入失败。
2. 关闭其他内存占用进程：升级前务必停止Solr服务及其他占用内存的进程，把所有资源留给IndexUpgrader。
3. 强制备份索引：升级是原地修改操作，一旦失败可能导致索引损坏，务必先做完整备份：

   rsync -avz /mnt/solr/gcp_data/data/index /mnt/backup/solr_index_backup_2024XXXX
   

4. 使用本地SSD磁盘：如果是云主机，尽量切换到本地SSD存储，网络存储的IO瓶颈会拖慢升级过程，甚至导致内存堆积超时。

内容来源于stack exchange