Azure Function应用突发延迟及关联Airflow作业故障排查求助

问题背景 #

4月16日周三17:00左右，部署在Azure Function中的API突然出现明显性能变慢。架构逻辑为：Airflow运行Python脚本向Azure SQL Server写入数据，Azure Function的API从该数据库读取数据。

已确认无变更项 #

• 未修改任何API代码
• 未修改Airflow执行的Python脚本
• 未修改Azure SQL Server中的表结构

Airflow调度作业错误日志 #

错误1：弹性池存储达上限

'life_cycle_state': 'TERMINATED', 'result_state': 'FAILED', 'state_message': 'Workload failed, see run output for details'} and with the errors [{'task_key': 'upload_to_tmp_tables', 'run_id': 672367321749800, 'error': 'org.apache.spark.SparkException: Job aborted due to stage failure: Task 3 in stage 77.0 failed 4 times, most recent failure: Lost task 3.3 in stage 77.0 (TID 132) (10.148.6.142 executor 1): com.microsoft.sqlserver.jdbc.SQLServerException: The elastic pool has reached its storage limit. The storage usage for the elastic pool cannot exceed (256000) MBs.'}]

错误2：进程终止信号

[2025-04-21, 23:24:40 EEST] {taskinstance.py:3093} ERROR - Received SIGTERM. Terminating subprocesses

错误3：数据库连接中断

{'life_cycle_state': 'TERMINATED', 'result_state': 'FAILED', 'state_message': 'Workload failed, see run output for details'} and with the errors [{'task_key': 'upload_to_tmp_tables', 'run_id': 401438450064268, 'error': "OperationalError: (20047, b'DB-Lib error message 20047, severity 9:\nDBPROCESS is dead or not enabled\n')"}]

当前资源使用情况 #

• 目标Azure数据库已占用187GB空间（总容量600GB）
• 所属弹性池已占用188GB空间（总容量250GB）
• 过去3个月该数据库数据量基本稳定（波动±100MB），弹性池中其他数据库空间占用无变化
• 待写入的最大表为370MB，带有聚集列存储索引和非唯一非聚集索引

排查与解决方案建议 #

1. 弹性池异常存储占用排查
   • 用sp_spaceused或Azure Portal的存储分析工具，逐库拆解空间占用明细，重点检查事务日志文件大小、临时表/临时空间占用、备份文件残留情况。
   • 确认是否存在未提交的长事务：长事务会导致事务日志无法截断，持续占用空间。
2. API性能下降关联验证
   • 弹性池存储接近阈值时，Azure SQL会触发IO节流等资源限制措施，直接导致查询响应变慢，这是API性能下降的核心诱因。可查看Azure SQL的性能指标（CPU使用率、IO等待时间、日志写入延迟）确认瓶颈。
3. Airflow写入失败根因定位
   • 第一个错误明确指向弹性池存储超限，后续的连接中断错误是存储不足引发的次生问题。
   • 检查upload_to_tmp_tables任务逻辑：是否每次执行后未清理临时表，导致空间累积？是否存在重复写入数据的情况？
4. 短期应急处理
   • 若需快速恢复作业，可临时扩容弹性池存储容量；待业务恢复后再进行空间清理。
   • 若数据库为完整恢复模式，执行日志备份操作可释放事务日志占用的空间。

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