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

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

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

Моя проблема в том, что я не нахожу, что это за «что-то» вызывает эти проблемы. Но после того, как произошло это странное событие, оно не только влияет на загрузку сигнатур ClamD, можно только очень хорошо увидеть проблему в этом сценарии, но, похоже, оно влияет на все, что связано с процессором. У меня такое ощущение, что на процессоры действует какой-то ручной тормоз: всякий раз, когда происходит что-то, связанное с процессором, все другие процессы, похоже, также накапливаются, создавая очень высокую нагрузку на систему, делая ее медленной, вплоть до который не может использовать простую навигацию с помощью курсорных клавиш, например, Полуночный командир (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 с той же версией, настройками и подписями в трех других виртуальных машинах с той же ОС и т. Д., Но с другой нагрузкой, программным обеспечением и т. Д., И в них проблема не возникает, хотя ClamD перезагружается почти каждый час в те, так что это можно было бы гораздо легче заметить в журналах. Кроме того, когда виртуальная машина работает медленно, нет большой нагрузки ввода-вывода (iostat), никаких тяжелых переключений контекста (mpstat), сама ВМ-хост не истощает ресурсы и проблема не решена пересозданием ВМ с нуля и установкой новой ОС. Я почти уверен, что это не просто узкое место в производительности, потому что 1. проблема начинается только после некоторого события, все происходит быстро раньше, и 2. я попытался воспроизвести проблему, используя виртуальную машину с гораздо меньшими ресурсами, и она не произошло.

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

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