Мягкая блокировка ЦП Linux, сбой ядра, зависание системы
Я часто использую aptitudeдля навигации по зависимостям. Попробуйте обновить несколько пакетов за раз.
Проверьте также локальные установленные пакеты, которые часто являются программами, недоступными в Debian. Попробуйте удалить их.
В моем наборе инструментов есть следующие команды:
dpkg --configure --pending, часто с опцией--abort-after=2000. Значение по умолчанию 50 не работает.перейдите в
/var/cache/apt/archivesиdpkg -i --force-depends package_version.dpkg(файл в таком каталоге ). В этом случае я принудительно устанавливаю пакет (и с помощью-rудаляю пакет, но в данном случае имя пакета, а не имя файла ).--force-override— еще одна полезная опция. Это иногда необходимо, когда есть некоторые сломанные зависимости. Обычно с именами пакетов очевидно, что замена всей серии пакетов новой версией серии пакетов является правильным способом продолжения (мы надеемся, что новые пакеты имеют правильные зависимости друг от друга, просто неверный путь обновления ).
В любом случае доделываю немногими dpkg --configure --pendingи новыми apt update, чтобы окончательно зафиксировать правильные зависимости.
Но вы должны делать это с должной осторожностью. Вы действительно можете сломать свою систему. :При принудительной установке попробуйте заблокировать в одном каталоге все пакеты одной версии и попытаться установить их вместе. Связанные пакеты из одного источника имеют одну и ту же версию, а большие серии часто имеют уникальные номера версий (, редко вы увидите их в версии 2.0 ). Старайтесь не форсировать libc/glibc и фундаментальные пакеты, необходимые для экстренного спасения системы.
Форматирование «цитата» вместо «кода» — это беспорядок, но здесь я спас часть, которая, вероятно, наиболее полезна:
Sep 27 10:21:20 hadoop-9 kernel: BUG: soft lockup - CPU#2 stuck for 22s!
...
Sep 27 10:21:20 hadoop-9 kernel: Call Trace:
Sep 27 10:21:20 hadoop-9 kernel:
Sep 27 10:21:20 hadoop-9 kernel:
Sep 27 10:21:20 hadoop-9 kernel: [] __do_softirq+0xef/0x280
Sep 27 10:21:20 hadoop-9 kernel: [] call_softirq+0x1c/0x30
Sep 27 10:21:20 hadoop-9 kernel: [] do_softirq+0x65/0xa0
Sep 27 10:21:20 hadoop-9 kernel: [] irq_exit+0x115/0x120
Sep 27 10:21:20 hadoop-9 kernel: [] smp_apic_timer_interrupt+0x45/0x60
Sep 27 10:21:20 hadoop-9 kernel: [] apic_timer_interrupt+0x6d/0x80
Sep 27 10:21:20 hadoop-9 kernel:
Sep 27 10:21:20 hadoop-9 kernel:
Sep 27 10:21:20 hadoop-9 kernel: [] ? vmballoon_work+0x2b3/0x720 [vmw_balloon]
Sep 27 10:21:20 hadoop-9 kernel: [] process_one_work+0x17b/0x470
Sep 27 10:21:20 hadoop-9 kernel: [] worker_thread+0x11b/0x400
Sep 27 10:21:20 hadoop-9 kernel: [] ? rescuer_thread+0x400/0x400
Sep 27 10:21:20 hadoop-9 kernel: [] kthread+0xcf/0xe0
Sep 27 10:21:20 hadoop-9 kernel: [] ? kthread_create_on_node+0x140/0x140
Sep 27 10:21:20 hadoop-9 kernel: [] ret_from_fork+0x58/0x90
Sep 27 10:21:20 hadoop-9 kernel: [] ? kthread_create_on_node+0x140/0x140
Верхняя часть трассировки вызовов выглядит как довольно общая трассировка срабатывания прерывания по таймеру. Это, вероятно, то, что обнаружило мягкую блокировку.
Нижняя часть, похоже, заключается в том, что система была в драйвере vmw_balloon. Этот драйвер используется с VMware и позволяет базовому узлу виртуализации сообщать виртуальной машине, что она временно не может использовать весь объем выделенной ей оперативной памяти. Если я правильно понял, он делает непрерывное, невыгружаемое выделение памяти в операционной системе виртуальной машины, а затем сообщает о своем местонахождении хосту виртуализации :«эта часть оперативной памяти, назначенная этой виртуальной машине, теперь заблокирована, вы можете теперь повторно используйте его в другом месте».
Тот факт, что ЦП #2 был занят в течение 22 секунд в этом единственном драйвере, наводит меня на мысль, что может быть некоторая нехватка ОЗУ :либо виртуальной машине потребуется память, которая была увеличена, а узел виртуализации не может вернуть ее вовремя, или узлу виртуализации требуется больше оперативной памяти в другом месте, и он отчаянно пытается получить больше от виртуальных машин.
Вам следует поговорить с администраторами хоста виртуализации и попросить их проверить статистику памяти хоста. Можно перераспределить выделение ОЗУ (, т. е. сделать так, чтобы сумма выделений ОЗУ для ВМ была больше, чем фактически доступная система ), на некоторую величину, если ожидается, что одни ВМ почти всегда будут бездействовать, когда другие заняты; но если слишком много чрезмерных обязательств, это разрушит общую производительность системы. Эта ошибка может быть побочным эффектом того, что хост виртуализации обещает слишком много оперативной памяти и не может ее предоставить.
Если статистика показывает, что узлу виртуализации не хватает оперативной памяти,тогда быстрое исправление может заключаться в переносе одной или нескольких виртуальных машин на другой хост с достаточным количеством свободной оперативной памяти. Если это невозможно, то в хост-систему необходимо добавить больше физической оперативной памяти, что может потребовать простоя.