我有一个运行 NodeJS 代码的 AWS Lambda 函数，可以将文件从 S3 流式传输到在 EC2 实例上运行的 ClamAV。
通常（大约 75% 的时间）系统可以工作，但通常（尤其是从不同的 Lambda 容器扫描多个文件时）clamd线程会卡在INSTREAM.
一旦线程进入INSTREAM25-30 秒，它似乎就无法恢复。当它已经QUEUEDSINCE350 秒时，它被杀死。我无法弄清楚这些数字中的任何一个与我的配置中的任何值有何关系。
我很难在日志中找到任何错误迹象 - INSTREAM 请求的数量与完整扫描的数量相匹配：
$ sudo grep -c "got command INSTREAM" /var/log/clamav/clamav.log
129
$ sudo grep -c "Chunks complete" /var/log/clamav/clamav.log
129
$ sudo grep -c "Scanthread: connection shut down" /var/log/clamav/clamav.log
129
...好吧，现在我对日志进行了更深入的研究，扫描一些日志只需要更长的时间。当我处理一批 16 个文件时，Lambda 并发限制为 7 个，前 7 个文件在几秒钟内被扫描。下一个文件很快开始扫描，在一秒钟内到达“块完成”，但在“扫描线程：连接关闭”之前需要 23 秒。从这里开始变得更糟 - 1:24、1:45……然后第三批 7 个文件需要 3 多分钟才能扫描。
如果我给系统几分钟的时间来安定下来，所有的线程都会死掉，同样的文件需要 3 分钟以上，现在大约需要 5-7 秒。
如果我在更快的机器上运行相同的测试，性能会提高，但问题仍然存在：
当线程卡住时，INSTREAM我可以看到文件仍然存在：
$ ls -al /tmp
drwx------ 2 clamav clamav 4096 Aug 29 16:52 clamav-493bdf893ce4d8d7763c00fee22d9d69.tmp
-rwx------ 1 clamav clamav 25683921 Aug 29 16:52 clamav-5cdefd83d5531a03c7cf22fda37d133f.tmp