Azure Durable Function App内存工作集持续增长（疑似泄漏）排查求助

我有一套Azure基础设施，包含基于Node.js 14 LTS的Durable Function App，涵盖HTTP触发器、编排器函数及若干活动函数，部署在Elastic Premium 1（EP1）应用服务计划中，Linux实例配置为4个始终就绪实例+4个预预热实例。

观察到以下现象：

• HTTP日均/周均流量稳定，但系统性能逐日下降，函数响应时间持续变长
• 应用服务计划CPU使用率持续上升
• Durable Function App的平均内存工作集呈近乎持续增长趋势
• 每次重新部署后，系统性能恢复正常，内存工作集降至约200MB的最低水平，但随时间推移性能又会逐日恶化

1. 调试内存泄漏问题 #

• 启用Azure Functions的应用程序日志和诊断日志，收集函数执行全链路日志，重点排查长时间运行的编排实例、高频调用的活动函数，检查是否存在未释放的资源（如未关闭的数据库连接池、长期存活的外部API客户端实例、未清除的定时器/事件监听器等）。
• 开启Node.js远程调试：在App Service的应用设置中添加WEBSITE_NODE_DEFAULT_VERSION指定Node.js 14版本，并设置NODE_OPTIONS="--inspect=0.0.0.0:9229"，通过Azure门户的远程调试功能连接到运行实例，利用Chrome DevTools的Memory面板抓取不同时间点的堆快照，对比分析持续增长的对象类型（如未清理的闭包、全局变量缓存池、未销毁的EventEmitter实例等）。
• 借助Azure Monitor的进程级资源监控，跟踪单个实例的内存变化曲线，确认内存增长是全实例普遍现象还是特定实例异常，缩小问题范围到特定函数逻辑。
• 针对Durable Functions特性排查：检查编排函数是否存在无限循环逻辑、未正确完成的持久任务（如未调用context.done()或未resolve终结Promise），活动函数是否存在未处理的异步操作泄漏（如Promise未被捕获，导致对象无法被GC回收）。
• 逐步隔离测试：临时禁用部分活动函数或修改HTTP触发器路由，验证内存增长是否与特定函数相关，快速定位问题代码块。
• 本地压力测试：使用autocannon等工具模拟生产流量，结合clinic.js heap-profiler对函数代码进行本地性能分析，提前复现内存泄漏场景并定位根源。

2. 为何private bytes、Gen 0/1/2垃圾回收等指标为空 #

• 这些指标是**.NET CLR专属性能指标**，仅适用于基于.NET运行时的Azure Functions。你的函数基于Node.js运行时，Azure Monitor不会为Node.js环境采集这类CLR相关的GC和私有字节指标，因此显示为空。
• Node.js环境下应重点关注的内存指标包括：内存工作集（Working Set）、堆使用量（Heap Usage）、堆大小（Heap Size）及垃圾回收频率，这些指标可以有效反映Node.js进程的内存占用与回收状态。

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