Виртуальная машина становится медленной после нескольких дней работы с 48 ГБ ОЗУ, а не с 6 ГБ

Я имею дело с проблемой в течение нескольких недель, которая приводит к очень медленному гостю VM после того, как VM побежала в течение нескольких дней.

"Медленный" означает, что связанные с процессором операции занимают больше времени, чем раньше, а также, по-видимому, эти операции накапливаются со временем. Например, перезагрузка ClamD-сигнатур обычно занимает ~35 секунд и 100 % на одном ядре, что увеличивается до 1 минуты и более без какой-либо другой нагрузки, но может легко занять 10 или 15 минут с некоторой другой загрузкой. Эта другая нагрузка может быть запросами к базе данных каким-либо веб-приложением, что уже создает 100 % -ную нагрузку на ядро. Кажется, что без проблем обе операции просто обрабатываются настолько быстро, насколько способен ЦП, в то время как с проблемой обе задачи, связанные с ЦП, становятся медленнее сами по себе и в то же время увеличивают общую нагрузку на систему. Любая другая маленькая операция, как htop или такое создает ненормально высокую нагрузку, а затем. Кроме того, такие процессы, как ClamD со 100 % нагрузкой на одно ядро, обычно отображаются как создающие нагрузку 150 % и более. Что в теории, и, как сказали ClamAV-люди, невозможно для перезагрузки подписей, потому что это просто не многопоточность. Таким образом, кажется, что вводятся некоторые накладные расходы, которые сильно снижают общую производительность системы. В то же время ни сама виртуальная машина, ни другие виртуальные машины на том же хосте не страдают от проблем с производительностью.

Это произошло с гостевой ОС UB 14.04 LTS в прошлом, а также с 16.04 LTS после новой новой установки, включая воссоздание виртуальной машины и тому подобное. Я думаю, что мне удалось отследить это с одной разницей: если виртуальная машина используется с 48 ГБ ОЗУ, проблема возникает после нескольких дней работы, если она используется только с 6 ГБ ОЗУ, это не так. Я очень уверен, что объем оперативной памяти - единственное различие в обоих случаях, тестируемая рабочая нагрузка одинакова и обеспечивается некоторыми автоматически выполняющимися тестами с использованием Jenkins и обновлений сигнатур ClamD. Вполне вероятно, что проблема не возникает по крайней мере с 8 ГБ ОЗУ, потому что у меня есть другая виртуальная машина с такой памятью, которая не показывает проблему, но в настоящее время я не знаю, каков верхний предел ОЗУ до проблема возникает. Проверка этого довольно трудоемкая, потому что проблема не существует с самого начала, она начинает происходить через некоторое время.

Мой сервер - HP DL380 G7 с двумя процессорами Intel Xeon X5675 @ 3,07 ГГц и 144 ГБ ОЗУ, равномерно распределенный по всем разъемам и слотам ОЗУ. Он работает под управлением UB 16.04 LTS, размещает виртуальные машины на ZFS, и протестированная виртуальная машина имеет 8 виртуальных ЦП и 48 ГБ ОЗУ или 6 назначенных. Ресурсов сервера должно быть более чем достаточно для моих нужд, бывший использованный G6 был немного медленнее с немного меньшей оперативной памятью и не показывал этих проблем. И без проблем, возникающих с 48 ГБ оперативной памяти, виртуальная машина ведет себя так, как ожидалось. Я почти уверен, что в хосте нет перестановки или перегрузки памяти:

top - 11:49:38 up 28 days, 13:54,  1 user,  load average: 0.26, 0.33, 0.35
Tasks: 904 total,   1 running, 899 sleeping,   0 stopped,   4 zombie
%Cpu(s):  0.1 us,  0.5 sy,  0.0 ni, 99.4 id,  0.0 wa,  0.0 hi,  0.0 si,  0.0 st
KiB Mem : 14853158+total,  5032192 free, 13115475+used, 12344644 buff/cache
KiB Swap:  5852156 total,  5852144 free,       12 used. 11533812 avail Mem

В настоящее время я смотрю на NUMA против "Чередования узлов", но я несколько уверен, что NUMA включен. Кроме того, из того, что я прочитал, влияние на производительность может составить около 20 % или даже 40 %, но не так сильно, как некоторые процессы, такие как подключение к базе данных, полностью прекращают работу. Я также читал, что в большинстве случаев нужно просто вообще не иметь дело со спецификой NUMA, а оставить по умолчанию настройки ОС и позволить ядру решать, где планировать какой поток и т. Д. Мне все равно не нужен последний бит производительности Только сейчас через некоторое время все становится неприемлемо медленным.

$ numactl --hardware
available: 2 nodes (0-1)
node 0 cpus: 0 2 4 6 8 10 12 14 16 18 20 22
node 0 size: 72477 MB
node 0 free: 14758 MB
node 1 cpus: 1 3 5 7 9 11 13 15 17 19 21 23
node 1 size: 72572 MB
node 1 free: 11046 MB
node distances:
node  0   1
      0:  10  20
      1:  20  10
$ dmesg | grep -i numa
[    0.000000] NUMA: Node 0 [mem 0x00000000-0xdfffffff] + [mem 0x100000000-0x121fffffff] -> [mem 0x00000000-0x121fffffff]
[    0.000000] mempolicy: Enabling automatic NUMA balancing. Configure with numa_balancing= or the kernel.numa_balancing sysctl
$ sysctl -a | grep numa_
kernel.numa_balancing = 1
kernel.numa_balancing_scan_delay_ms = 1000
kernel.numa_balancing_scan_period_max_ms = 60000
kernel.numa_balancing_scan_period_min_ms = 1000
kernel.numa_balancing_scan_size_mb = 256

Помимо NUMA, я читал об огромных страницах в Linux и больших страницах VirtualBox, но, насколько я понимаю, отказ от использования того и другого должен оказать такое драматическое негативное влияние, как я вижу. VirtualBox говорит о ~5 % -ном выигрыше в производительности за счет использования больших страниц, и хотя огромные страницы не установлены явно на моем хосте, они используются и доступны с использованием "прозрачных огромных страниц" из того, что я вижу в /proc/vmstat,

Меня удивляет то, что 48 ГБ ОЗУ совсем не так много, я читал, что другие пользователи сталкиваются с проблемами только после того, как было назначено более 128 ГБ, и разработчики говорят, что они успешно протестировали с 1 ТБ ОЗУ. Кроме того, также работают объемы (до) 24 ГБ, которые ранее использовались проблемной виртуальной машиной без каких-либо проблем, и на момент написания этой статьи снова.

У вас есть идеи, что может создать проблему здесь?