通过iFrame调用ShinyProxy部署的Shiny应用时触发ShinyProxy崩溃求助

问题根因 #

你遇到的问题本质是Linux系统OOM（内存溢出）杀手进程将ShinyProxy主进程强制杀死，你贴的服务状态中Main PID: 3200 (code=killed, signal=KILL)就是进程被系统强制终止的典型特征，和你观察到的内存占用接近100%的情况完全吻合。

iFrame访问和直接访问的差异原因 #

直接访问时请求链路正常，不会触发重复请求；而iFrame嵌入时如果没有配置允许跨域嵌入的响应头，浏览器会拦截ShinyProxy的响应，前端逻辑往往会自动重试请求，短时间内触发ShinyProxy批量启动新的Shiny Docker容器，瞬间打满8G内存。OOM Killer会优先终止占用内存最高的Java进程（也就是ShinyProxy），此时残留的Shiny容器依然占用大量内存，单独重启Nginx和ShinyProxy无法释放这部分内存，因此必须重启整机才能恢复服务。

排查与解决方案 #

第一步：确认OOM触发记录 #

执行以下命令验证根因：

dmesg | grep -i oom

如果输出中存在java或shinyproxy进程被OOM Killer杀死的日志，即可完全确认是内存不足导致的问题。

第二步：修复iFrame重复请求问题 #

在Nginx配置对应的location块，或者ShinyProxy的application.yml配置文件中添加允许嵌入的响应头，避免浏览器拦截导致反复重试：

# Nginx配置示例
add_header X-Frame-Options "ALLOW-FROM 你的嵌入页面所属域名";
add_header Content-Security-Policy "frame-ancestors 你的嵌入页面所属域名";

第三步：限制资源占用避免内存打满 #

• 限制ShinyProxy的Java堆内存：修改/etc/systemd/system/shinyproxy.service中的ExecStart参数，添加JVM内存限制，示例如下：

  ExecStart=/usr/bin/java -Xmx2g -Xms1g -jar /opt/shinyproxy/shinyproxy.jar
  

  上述配置表示Java进程最大堆内存为2G，初始堆内存为1G，避免Java进程无限制占用内存。
• 限制单个Shiny容器的内存上限：在ShinyProxy的application.yml配置中，为每个应用添加容器内存限制，同时配置闲置容器自动销毁：

  proxy:
    max-instances: 3 # 同时运行的最大容器数，根据内存情况调整
    container-memory-limit: 1g # 单个容器最多占用1G内存
    container-max-lifetime: 1800 # 容器闲置30分钟后自动销毁
  

第四步：应急恢复方案 #

后续再出现服务崩溃的情况，不需要重启整机，执行以下命令即可恢复：

# 杀掉所有运行中的Shiny容器释放内存
docker ps -q | xargs docker kill
# 重启ShinyProxy服务
systemctl restart shinyproxy

长期优化建议 #

• 临时缓解可以给服务器添加2-4G的swap交换分区，物理内存打满时可以用交换分区兜底，避免直接杀掉核心进程
• 如果你的Shiny应用本身计算量较大，单容器启动就占用2G以上内存，8G物理内存确实不足以支撑多会话访问，建议升级VPS配置到16G内存
• 优化Shiny应用代码，减少不必要的内存占用，比如大数据量场景使用分页加载、及时释放无用变量等

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