У меня есть функция AWS Lambda, выполняющая код NodeJS для потоковой передачи файлов из S3 в ClamAV, запущенный на экземпляре EC2.
Обычно (примерно в 75% случаев) система работает, но часто (особенно при сканировании нескольких файлов из разных контейнеров Lambda) clamd потоки зависают на INSTREAM.
Как только поток находится в INSTREAM в течение 25-30 секунд, он, похоже, не сможет восстановиться. По прошествии QUEUEDSINCE 350 секунд его убивают. Я не могу понять, какое из этих чисел относится к какому-либо значению в моей конфигурации.
Я изо всех сил пытаюсь найти какие-либо признаки ошибки в журналах - количество запросов 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 файлов сканируются в течение нескольких секунд. Следующий файл начинает сканирование вскоре после этого, доходит до «Чанки завершены» в течение секунды, но до «Scanthread: отключение соединения» требуется 23 секунды. С этого момента становится только хуже - 1:24, 1:45 ... а затем 3-й пакет из 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