Почему моя виртуальная машина становится медленнее во время выполнения задач с большим количеством ресурсов процессора после нескольких дней работы?

В течение некоторого времени я имею дело с какой-то странной проблемой: после нескольких дней работы одна из моих виртуальных машин начинает работать медленнее в задачах с большой нагрузкой на процессор. Одним из примеров, где это происходит, является чтение баз данных сигнатур вирусов в ClamD, либо просто перезапустив демон, отправив сигнал USR2 для повторного считывания подписей или по истечении установленного времени ожидания проверки подписи.

После перезапуска виртуальной машины считывание вирусных баз - это быстрая операция, которая занимает около 35 секунд и при постоянном повторении остается постоянной. После нескольких дней работы "что-то" происходит, что делает загрузку этих сигнатур очень медленной операцией, вплоть до того момента, когда виртуальная машина дополнительно обрабатывает то, что ей обычно нужно делать в дневное время, до 15 или даже 20 минут (!). Ночью это немного быстрее, может быть, в половине случаев, но это все еще много минут, а без того, что "что-то" случилось, это всегда намного меньше минуты.

Моя проблема в том, что я не понимаю, что это за "что-то" вызывает эти проблемы. Но после того, как произошло это странное событие, оно не только влияет на загрузку сигнатуры ClamD, можно только увидеть проблему очень хорошо с этим сценарием, но, кажется, влияет на все, что связано с процессором. У меня такое ощущение, что на процессорах действует какой-то ручной тормоз: всякий раз, когда происходит процесс, связанный с процессором, все другие процессы также накапливаются, создавая очень высокую нагрузку на систему, делая ее медленной, вплоть до точки какой из них не может использовать простую навигацию по клавишам курсора, например, Midnight Commander (mc) больше. Перезапуск Apache Tomcat, обслуживающий несколько различных веб-приложений, запускает этот эффект и после того, как "что-то" произошло, перезапуск занимает больше времени, чем раньше.

Эти эффекты легко увидеть в htop:

Такая высокая нагрузка вызвана только процессом ClamD, обычно он не такой высокий, особенно потому, что запросы к Tomcat обычно обрабатываются довольно быстро. После завершения ClamD общая нагрузка снова становится намного ниже. Кроме того, следует признать, что ClamD использует>100% ЦП, что обычно не так, поскольку чтение сигнатур выполняется только одним ЦП. Интересна и следующая картина:

После того, как предыдущие запросы были обработаны Tomcat, нагрузка на все процессоры падает, ClamD возвращается к тому, что выглядит нормально с ~100%. Но это не так, ClamD занимает слишком много времени, он уже работал в течение нескольких минут, а другие топовые процессы, такие как htop само по себе не должно создавать такую ​​высокую нагрузку. Без запуска ClamD это ~2-3%.

Таким образом, кажется, что вещи, которые не обрабатываются слишком медленно, становятся медленнее, но остаются "достаточно быстрыми", в то время как все, что потребляет много ресурсов ЦП, например ClamD или Tomcat, становится очень медленным и замедляет другие процессы. Это даже можно увидеть в логах ClamD, он начинает быстро перезагружаться и становится медленнее:

Tue May  1 11:56:26 2018 -> Reading databases from /var/lib/clamav
Tue May  1 11:57:01 2018 -> Database correctly reloaded (10566159 signatures)
Tue May  1 19:11:07 2018 -> Reading databases from /var/lib/clamav
Tue May  1 19:11:47 2018 -> Database correctly reloaded (10566159 signatures)
Wed May  2 00:51:15 2018 -> Reading databases from /var/lib/clamav
Wed May  2 00:51:53 2018 -> Database correctly reloaded (10578504 signatures)
Wed May  2 03:41:56 2018 -> Reading databases from /var/lib/clamav
Wed May  2 03:42:31 2018 -> Database correctly reloaded (10579770 signatures)
Wed May  2 20:45:32 2018 -> Reading databases from /var/lib/clamav
Wed May  2 20:46:07 2018 -> Database correctly reloaded (10579770 signatures)
Thu May  3 00:52:29 2018 -> Reading databases from /var/lib/clamav
Thu May  3 00:53:08 2018 -> Database correctly reloaded (10584928 signatures)
Thu May  3 03:42:07 2018 -> Reading databases from /var/lib/clamav
Thu May  3 03:42:46 2018 -> Database correctly reloaded (10586235 signatures)
Thu May  3 08:52:18 2018 -> Reading databases from /var/lib/clamav
Thu May  3 08:53:06 2018 -> Database correctly reloaded (10586235 signatures)
Fri May  4 01:00:30 2018 -> Reading databases from /var/lib/clamav
Fri May  4 01:01:53 2018 -> Database correctly reloaded (10586721 signatures)
Fri May  4 03:42:43 2018 -> Reading databases from /var/lib/clamav
Fri May  4 03:44:01 2018 -> Database correctly reloaded (10588026 signatures)
[...]
Sat May  5 00:56:17 2018 -> Reading databases from /var/lib/clamav
Sat May  5 00:59:48 2018 -> Database correctly reloaded (10589668 signatures)
Sat May  5 03:47:01 2018 -> Reading databases from /var/lib/clamav
Sat May  5 03:53:47 2018 -> Database correctly reloaded (10590874 signatures)
Sat May  5 13:40:49 2018 -> Reading databases from /var/lib/clamav
Sat May  5 13:56:33 2018 -> Database correctly reloaded (10590874 signatures)
Sun May  6 01:00:20 2018 -> Reading databases from /var/lib/clamav
Sun May  6 01:09:27 2018 -> Database correctly reloaded (10597394 signatures)
Sun May  6 03:51:45 2018 -> Reading databases from /var/lib/clamav
Sun May  6 03:59:11 2018 -> Database correctly reloaded (10598555 signatures)

Что еще хуже, я не смог воспроизвести проблемы на очень похожей виртуальной машине с почти такими же аппаратными и программными настройками. Я использую ClamD с той же версией, настройками и подписями в 3 других виртуальных машинах с той же ОС и т. Д., Но с разной загрузкой, программным обеспечением и т. Д., И проблема в них не возникает, даже если ClamD перезагружается почти каждый час. те, так что это можно было заметить в журналах гораздо проще. Кроме того, когда виртуальная машина работает медленно, нет большой нагрузки ввода-вывода (iostat), без тяжелых переключений контекста (mpstat), сам VM-хост не истощает ресурсы, и проблема не была решена путем воссоздания виртуальной машины с нуля и установки новой ОС. Я почти уверен, что это не просто узкое место в производительности, потому что: 1. проблема начинает возникать только после некоторого события, все происходит быстро, и 2. я пытался воспроизвести проблему, используя виртуальную машину с гораздо меньшими ресурсами и не произошло

Сама виртуальная машина - Ubuntu 16.04, 8 виртуальных ЦП, 48 ГБ ОЗУ. В качестве виртуального хоста используется Ubuntu 16.04 с 2-мя процессорами Intel(X) Xeon®, X5675 @ 3,07 ГГц, с поддержкой Hyperthreading, то есть всего 24 логических ЦП и 148 ГБ ОЗУ. Обычно таких ресурсов достаточно для быстрого обслуживания моих приложений. Используемый гипервизор - VirtualBox 5.2.10.

Есть еще идеи, как отладить это, что может быть "чем-то", создающим проблему? Спасибо!