Рейтинг:0

Openstack nova завершает гостевую виртуальную машину с помощью oom_kill

флаг it

Я запускаю Викторию с открытым стеком с развертыванием Kolla, все компоненты контейнеризированы.

Вычислительный узел (oom_kill) убивает гостя, когда память исчерпана, есть ли способ избежать этого, как в других гипервизорах, он отлично работает без этой проблемы. Я использую Centos 8.3. Пожалуйста, дайте мне знать, если есть способ избежать этого.

Ошибки:

** 27 февраля, 12:18:15, ядро ​​server1: нейтрон-openvsw вызвал oom-killer: gfp_mask=0x6200ca(GFP_HIGHUSER_MOVABLE), порядок=0, oom_score_adj=0
27 февраля, 12:18:15 Ядро server1: oom_kill_process.cold.28+0xb/0x10
27 февраля, 12:18:15, ядро ​​server1: [pid] uid tgid total_vm rss pgtables_bytes swapents oom_score_adj name
27 февраля 12:18:15 Сервер1 Ядра: OOM-Kill: Constraint = constraint_none, nodemask = (null), cpuset = 395bde13c7e0570ef36df008bc028d8701fd76c1b56e2a56faf254fd53d0043, memsmememe-in.10-nember. -qemu, задача = qemu-kvm, pid = 2301214, uid = 42436
27 февраля, 12:18:17 ядро ​​​​сервера 1: oom_reaper: собран процесс 2301214 (qemu-kvm), теперь anon-rss: 0kB, файл-rss: 516kB, shmem-rss: 0kB**

использование памяти sar

===================================
10:10:05 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty
12:00:05 877228 0 393690660 99,78 0 500284 2254123104 542,46 374227828 12705256 0
12:10:04 866416 0 393701472 99,78 0 501844 2254259520 542,49 374233440 12704360 0
12:20:04 301182096 300028052 93385792 23,67 0 705140 1938778932 466,57 83794716 5028804 8
12:30:04 301085624 299970968 93482264 23,69 0 779220 1939000988    
флаг us
Это звучит как [эта ветка](http://lists.openstack.org/pipermail/openstack-discuss/2022-February/027350.html) в списке рассылки openstack-discuss.
Рейтинг:0
флаг it

Отвечая на мой собственный вопрос, я нашел решение.

Убийства oom происходили даже тогда, когда бесплатная статистика выглядела хорошо, например, на 256 ГБ ОЗУ использовалось только 140 ГБ, и все же около 100 ГБ отображались как свободные.

[root@serverxx ~]# бесплатно -g общее количество использованных бесплатных общих баффов/доступных кешей Мем: 251 140 108 0 2 108 Обмен: 19 6 13

Убийства oom были вызваны высоким %commit в статистике sar, когда ядро ​​​​начинает нацеливаться на экземпляры с большим объемом памяти, чтобы освободить .

Чтобы избежать oom kills для гостевых экземпляров с большим объемом памяти, я установил следующее. vm.oom_kill_allocating_task=1

Когда я сделал sar -r, процент фиксации был намного выше, чем система может выделить, и я понял из ps, что это был контейнер cinder-backup, который был создан по умолчанию из развертываний kolla-ansible, но не был настроен.

Статистика службы резервного копирования Cinder, которую я не настраивал, и она просто работала, оказалось, что ненастроенный контейнер занимает всю память сверхурочно, как видно из вывода команды ps в файле vsz.

ps -eo args,comm,pid,ppid,rss,vsz --sort столбец vsz

ВСЗ чрезвычайно высок

КОМАНДА Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â Â КОМАНДА Â Â Â Â Â Â Â Â Â Â PID Â Â Â PPID Â RSS VS Z Â /usr/libexec/qemu-kvm -name qemu-kvm 1916998 47324 8094744 13747664 /var/lib/kolla/venv/bin/pyt cinder-backup 43689 43544 170999912 870274784

Статистика Sar для % фиксации возвращается к норме после того, как контейнер резервного копирования был остановлен, и теперь все возвращается к норме. %commit выделен из от 1083,46 до 14,21 после изменений.

14:00:37 kbmemfree kbavail kbmemused %memused kbbuffers kbcached kbcommit %commit kbactive kbinact kbdirty 15:00:37 48843576 49998184 82890508 62,92 9576 5949348 1427280428 1083.46 75646888 2797388 324 15:10:37 48829248 49991284 82904836 62,93 9576 5956544 1427343664 1083.50 75653556 2804592 116 15:20:22 120198612 121445516 11535472 8,76 9576 6042892 18733688 14.22 4887688 2854704 80 15:30:37 120189464 121444176 11544620 8,76 9576 6050200 18725820 14.21 4887752 2862248 88

Ответить или комментировать

Большинство людей не понимают, что склонность к познанию нового открывает путь к обучению и улучшает межличностные связи. В исследованиях Элисон, например, хотя люди могли точно вспомнить, сколько вопросов было задано в их разговорах, они не чувствовали интуитивно связи между вопросами и симпатиями. В четырех исследованиях, в которых участники сами участвовали в разговорах или читали стенограммы чужих разговоров, люди, как правило, не осознавали, что задаваемый вопрос повлияет — или повлиял — на уровень дружбы между собеседниками.