R语言shinyapps.io部署报SIGKILL(code137)内存溢出问题咨询

静态文件/数据体积远小于1G仍触发OOM的原因 #

你统计的是数据的磁盘存储大小和源代码文件大小，和R运行时的实际内存占用有本质差异，常见诱因如下：

• R对象内存膨胀：磁盘上的CSV、数据库导出数据是压缩存储的，加载到R环境后内存占用通常会放大3~10倍：字符型向量每个元素有额外的指针开销，时间、因子类型也有存储额外开销，你13M左右的磁盘数据加载到R中可能已占用数百M内存，叠加其他开销很容易触碰1G阈值。
• 临时对象未清理：数据拉取、清洗、计算、绘图过程中产生的临时对象（比如拉取后的原始副本、合并计算的中间表）如果没有及时清理，会一直占用内存，哪怕最终你只用到很小的结果集。
• 全局对象累积残留：如果把拉取的数据、计算结果存在global.R或者全局环境，单次访问后对象不会自动释放，多次运行或者多用户访问时内存会持续累积直到溢出。
• 基础开销占比：shinyapps.io免费层的1G内存包含R运行时本身、依赖包加载、系统进程的全部开销，仅加载tidyverse全套包就会占用近200M内存，可留给数据使用的空间本身就小于1G。
• 额外内存拷贝：上传CSV文件时shiny会先将文件缓存到内存再做处理，相当于同一份数据同时存在上传缓存、读取后的对象两份副本，进一步拉高内存占用。
• 内存泄漏：部分旧版本的数据库连接包、绘图包存在已知内存泄漏问题，调用后不会主动释放内存，多次运行后内存会逐步累积到阈值。
• 并发访问：shinyapps.io免费层仅提供单实例运行，多个用户同时访问时，每个会话的对象会叠加占用内存，很容易触发上限。

内存占用过高排查方法 #

• 本地逐行测试内存占用：用pryr包的函数逐步骤统计内存变化，定位内存跳升的代码段：

library(pryr)
# 统计单步代码内存增量
mem_before <- mem_used()
# 替换为你要测试的拉取/清洗/计算代码
raw_data <- aws_api_pull_function()
mem_after <- mem_used()
print(paste("本步骤内存增量：", mem_after - mem_before))
# 查看单个对象的实际内存占用
print(object_size(raw_data))

• 全链路内存 profiling：用profvis包运行应用，可视化展示每段代码的CPU和内存占用，直接定位高消耗节点：

library(profvis)
profvis(runApp())

• 检查全局环境残留：在server函数末尾添加print(ls(.GlobalEnv))，确认是否有不需要的大对象残留在全局环境未释放。

降低应用运行内存的优化方案 #

• 上游提前处理数据：拉取数据时优先在AWS侧完成过滤、聚合计算，仅返回最终需要的结果集到R中，不要拉取全量数据到本地再处理。
• 优化数据读取逻辑：读入数据时用col_types参数指定每列的存储类型，将低基数的字符列转为因子，优先用data.table::fread()读取数据，内存占用比base R、readr低30%~50%。
• 及时清理临时对象：处理完成的临时对象立刻用rm()删除，随后调用gc()强制触发垃圾回收：

# 清理不需要的中间对象
rm(raw_pull_data, temp_merge_df, temp_calculate_result)
gc()

• 优化对象存储逻辑：不要把大对象存到全局环境，尽量放在server函数内部，会话结束后会自动释放；多会话共用的静态数据抽成全局唯一的reactiveVal，避免每个会话重复拉取生成副本。
• 优化reactive逻辑：把重复用到的计算、数据拉取逻辑抽成单独的reactive，确保同一份数据仅计算/拉取一次，不要在多个输出函数里重复处理同一份数据。
• 精简依赖：不要加载未使用的包，比如不要直接加载整个tidyverse，仅加载实际用到的dplyr、ggplot2等单个包，降低基础内存开销。
• 优化上传逻辑：上传CSV时优先写入本地临时磁盘再读取处理，处理完成后立刻删除临时文件，避免同一份数据在内存中存在多份副本。

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