AWS EC2部署的Artifactory升级内存重启后报Service Unavailable如何解决

故障根因 #

从报错日志可定位核心问题：Artifactory启动过程中初始化binaryServiceImpl二进制存储服务时触发java.io.EOFException错误，错误信息No content to map to Object due to end of input说明相关元数据/索引文件被截断或损坏，连锁导致Spring依赖注入链路全部失败，最终服务无法正常启动返回Service Unavailable。该故障是此前内存占满、实例强制重启过程中Artifactory未正常落盘文件导致的。

可行解决步骤 #

按优先级从高到低执行以下操作：

• 步骤1：停止所有Artifactory进程，避免写入操作加剧文件损坏

  # 停止服务
  systemctl stop artifactory
  # 确认无残留进程
  ps aux | grep artifactory | grep -v grep
  # 如有残留进程强制杀死
  kill -9 <残留进程PID>
  

• 步骤2：修复数据目录权限，内存溢出强制重启极易导致文件所有者错乱

  chown -R artifactory:artifactory /opt/jfrog/artifactory/var/
  

• 步骤3：重建损坏的二进制存储索引
  1. 进入默认数据目录：cd /opt/jfrog/artifactory/var/data/artifactory/
  2. 备份当前损坏的索引文件：mv binarystore.index binarystore.index.bak
  3. 修改/opt/jfrog/artifactory/var/etc/system.yaml添加重建索引配置：

  artifactory:
    rebuildIndex: true
  

  注意：索引重建时长取决于存储的制品总量，制品较多时可能需要数十分钟到数小时，期间不要中断服务
• 步骤4：校验配置文件完整性
  检查/opt/jfrog/artifactory/var/etc/目录下所有yaml、properties配置文件，确认文件大小不为0、内容没有被截断，如有损坏用历史备份替换；无备份则提取同版本Artifactory干净安装包的默认配置，手动填入自定义参数（如数据库连接、存储路径、域名配置等）。
• 步骤5：同步调整JVM内存配置
  升级实例内存后需要同步调整Artifactory的堆内存上限，修改/opt/jfrog/artifactory/var/etc/artifactory/default中的JAVA_OPTIONS参数，堆内存建议设置为实例可用内存的50%~70%，例如8G实例配置为：

  JAVA_OPTIONS="-Xms4g -Xmx4g"
  

  避免再次出现内存溢出问题。
• 步骤6：启动服务验证

  systemctl start artifactory
  # 实时观察启动日志
  tail -f /opt/jfrog/artifactory/var/log/artifactory-service.log
  

  服务启动成功后，务必删除步骤3中添加的rebuildIndex: true配置，避免每次启动都重复重建索引影响性能。

极端情况降级方案 #

如果确认元数据损坏严重且无有效备份，可重新部署同版本Artifactory实例，挂载原有filestore二进制存储目录，配置原有数据库连接信息后启动，服务会自动重建大部分元数据，只要二进制存储文件未损坏，原有制品不会丢失。

内容的提问来源于stack exchange，提问作者Anukriti Mishra