AWS Lambda中调用scipy读取wav文件转样本列表触发超时是什么原因

核心原因分析 #

• 首先纠正认知误区：getsizeof(source)返回56无法证明音频数据已完整加载。scipy读取wav文件返回的是(采样率, numpy数组)结构的元组，getsizeof仅统计元组本身的内存占用，numpy数组的实际数据存储在堆区，不会纳入元组的大小统计，可通过source[1].nbytes查看音频数据的实际占用空间，多数情况下该数值远高于预期。
• 最常见诱因是numpy数组转Python列表的内存膨胀问题：numpy数组的数值为紧凑存储，比如16位整型音频样本每个仅占2字节，但转成Python原生int对象后，单个int的内存占用至少为28字节，整体内存占用直接膨胀14倍以上。如果音频是长时长、高采样率、多声道规格，512MB的Lambda内存完全不足以承载转换后的列表，会触发内存超限，进而导致进程冻结、频繁IO交换最终超时，本地环境内存充足所以不会触发该问题。
• 其次可能是依赖兼容性问题：Lambda中使用的scipy/numpy多为第三方预编译的Lambda Layer，若Layer的编译架构（x86_64/arm64）和Lambda函数的运行架构不匹配，或者依赖版本存在已知BUG，会在处理数组转换操作时触发死锁，导致无限挂起。
• 少数情况为隐式内存映射问题：如果wav文件存在格式异常，或者scipy的mmap参数被隐式设置为True，数组会以内存映射的方式直接关联磁盘文件，Lambda的/tmp目录IO性能极低，大文件的映射读取操作会被拖慢到远超超时阈值。

修复方案 #

• 优先避免全量转换numpy数组为Python列表：如果后续处理逻辑支持直接操作numpy数组，直接省略tolist()步骤，内存占用会降低一个数量级。
• 若必须使用Python列表，先对音频做切片、降采样或者转单声道处理，降低数组总大小后再执行转换。
• 确认Lambda运行架构和scipy/numpy Layer的编译架构一致，也可尝试将Lambda内存提升到2GB以上，匹配转换后的内存需求。
• 读取wav时显式指定mmap=False，规避内存映射问题：source = scipy.io.wavfile.read('/tmp/letov.wav', mmap=False)
• 提前校验/tmp目录下的wav文件大小和源文件大小是否一致，排除文件下载不完整的问题。

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