ASP.NET Core 5.0 Web API部署Ubuntu 18偶发重启耗时过长问题

结论 #

静态文件就是导致重启耗时过长的直接原因，该问题的本质是Linux系统页缓存机制与ASP.NET Core静态文件中间件的初始化逻辑共同作用的结果。

原因分析 #

• Linux系统的页缓存特性完全匹配你观测到的时间规律：首次读取磁盘上的海量小文件时，磁盘IO耗时极高，读取完成后文件内容与元数据会暂存在内存缓存中，后续访问直接走内存速度会提升10~100倍；一般服务器会定时清理缓存、或夜间内存回收时释放缓存，因此次日首次启动又会出现慢启动问题。
• ASP.NET Core的PhysicalFileProvider初始化时会默认全量扫描指定目录的所有文件，构建内部索引用于后续静态文件请求的快速响应，你的/Resources目录存储大量图片，启动阶段的全目录扫描会触发海量磁盘IO，直接导致启动阻塞。
• 你做的对照测试已经完全验证了该逻辑：/Resources为空时无扫描开销，启动耗时始终稳定在几秒级别，和大文件量版本的表现形成明确差异。

优化方案 #

• 优先推荐把静态文件托管交给Nginx处理：不要通过ASP.NET Core中间件托管静态资源，Nginx处理静态文件的性能远高于应用程序，也完全规避了应用启动阶段的目录扫描开销。
• 调整PhysicalFileProvider逻辑：关闭启动时的全量预扫描，改用按需加载的文件提供器实现，仅在收到对应静态文件请求时才读取对应目录的文件信息。
• 优化静态文件目录结构：不要将所有图片都存放在单级根目录下，按业务、日期维度拆分多级子目录，降低单次目录扫描的文件量级。
• 配置预缓存定时任务：每日低峰期执行find /var/app/Resources -type f > /dev/null命令，提前将目录下的文件加载到系统页缓存，规避白天首次启动的高耗时问题。
• 升级存储硬件：将机械硬盘替换为SSD，海量小文件的随机读取性能会有量级提升。

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