+7 (495) 320-70-49
- Назад
- Телефоны
- +7 (495) 320-70-49
- Заказать звонок
info@proxmox.su
Москва, Бакунинская улица, 69с1
Пн-Пт: 09-00 до 18-00
Сб-Вс: выходной

Proxmox зависает при низкой загрузке процессора., Proxmox Виртуальная Среда

simon098

Guest

08.01.2025 22:31:00

Привет! Уже некоторое время мучаюсь с этой проблемой. Когда нагрузка на ЦП низкая (например, менее 1-2%), Proxmox случайным образом зависает. Journalctl ничего полезного не показывает. Если я держу ЦП в высоком состоянии простоя, например, >3%, всё работает днями без проблем. OpnSense обычно работает постоянно, хотя ЦП она и не нагружает достаточно. Думаю, что проблема не в оборудовании, например, в RAM или блоке питания, так как при более высоких нагрузках ЦП это проявлялось бы сильнее.

* **ЦП:** Ryzen 9 6900HX
* **Память:** 32 ГБ DDR5
* **Хранилище:** SSD (Proxmox) + nVME (хранилище VM)

**Proxmox Version:** 8.3.2
**Kernel Version:** Linux 6.8.12-5-pve

Вот последние логи с момента зависания:

```
Jan 08 01:17:01 pve CRON[32326]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Jan 08 01:17:01 pve CRON[32327]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jan 08 01:17:01 pve CRON[32326]: pam_unix(cron:session): session closed for user root
Jan 08 01:25:15 pve pvedaemon[1350]: <root@pam> successful auth for user 'simon@pve'
Jan 08 01:27:55 pve pveproxy[23068]: worker exit
Jan 08 01:27:55 pve pveproxy[1357]: worker 23068 finished
Jan 08 01:27:55 pve pveproxy[1357]: starting 1 worker(s)
Jan 08 01:27:55 pve pveproxy[1357]: worker 35146 started
Jan 08 01:40:15 pve pvedaemon[1349]: <root@pam> successful auth for user 'simon@pve'
Jan 08 01:49:44 pve smartd[924]: Device: /dev/sda [SAT], SMART Usage Attribute: 194 Temperature_Celsius changed from 71 to 72
Jan 08 01:50:11 pve pveproxy[21244]: worker exit
Jan 08 01:50:11 pve pveproxy[1357]: worker 21244 finished
Jan 08 01:50:11 pve pveproxy[1357]: starting 1 worker(s)
Jan 08 01:50:11 pve pveproxy[1357]: worker 40956 started
Jan 08 01:55:16 pve pvedaemon[1350]: <root@pam> successful auth for user 'simon@pve'
Jan 08 02:02:21 pve systemd[1]: Starting pve-daily-update.service - Daily PVE download activities...
Jan 08 02:02:22 pve pveupdate[44121]: <root@pam> starting task UPID:pve:0000AC5E:000EE6B9:677DDCAE:aptupdate::root@pam:
Jan 08 02:02:23 pve pveupdate[44126]: update new package list: /var/lib/pve-manager/pkgupdates
Jan 08 02:02:24 pve pveupdate[44121]: <root@pam> end task UPID:pve:0000AC5E:000EE6B9:677DDCAE:aptupdate::root@pam: OK
Jan 08 02:02:24 pve systemd[1]: pve-daily-update.service: Deactivated successfully.
Jan 08 02:02:24 pve systemd[1]: Finished pve-daily-update.service - Daily PVE download activities.
Jan 08 02:02:24 pve systemd[1]: pve-daily-update.service: Consumed 2.261s CPU time.
Jan 08 02:10:47 pve pvedaemon[1351]: <root@pam> successful auth for user 'simon@pve'
Jan 08 02:13:26 pve pveproxy[25464]: worker exit
Jan 08 02:13:26 pve pveproxy[1357]: worker 25464 finished
Jan 08 02:13:26 pve pveproxy[1357]: starting 1 worker(s)
Jan 08 02:13:26 pve pveproxy[1357]: worker 47405 started
Jan 08 02:17:01 pve CRON[48323]: pam_unix(cron:session): session opened for user root(uid=0) by (uid=0)
Jan 08 02:17:01 pve CRON[48324]: (root) CMD (cd / && run-parts --report /etc/cron.hourly)
Jan 08 02:17:01 pve CRON[48323]: pam_unix(cron:session): session closed for user root
-- Boot 2e8e62781a5d4069a5670f524c44ad2d --
Jan 08 09:32:18 pve kernel: Linux version 6.8.12-5-pve (build@proxmox) (gcc (Debian 12.2.0-14) 12.2.0, GNU ld (GNU Binutils for Debian) 2.40) #1 SMP PREEMPT_DYNAMIC PMX 6.8.12-5 (2024-12-03T10:26Z) ()
Jan 08 09:32:18 pve kernel: Command line: BOOT_IMAGE=/boot/vmlinuz-6.8.12-5-pve root=/dev/mapper/pve-root ro quiet

У кого-нибудь есть какие-нибудь идеи? Я думал, может быть, это связано с C-States, но я не вижу, чтобы они были включены в BIOS, хотя там довольно ограничено, что показывает BIOS для этой машины...

Fantu Guest	#2 0 08.01.2025 22:41:00 Если не получается отключить C-state в BIOS/UEFI, можно попробовать сделать это через параметры ядра: https://gist.github.com/dlqqq/876d74d030f80dc899fc58a244b72df0

simon098 Guest	#3 0 08.01.2025 23:07:00 Спасибо, я только что это реализовал, сообщу, как продвигается.

simon098

Guest

10.01.2025 00:04:00

Пока что всё хорошо. Обычно я оставлял её на 4-5 часов, и она бы зависла. А сейчас она работает уже больше 24 часа и не зависла. Я нашёл в BIOS опцию отключения Global C states. Я её тоже отключил. Но я оставлю это на несколько дней и посмотрю, не вылетит ли, если нет — включу обратно в BIOS и проверю, сработает ли GRUB process.max_cstate=1. P.S. Кстати, интересно... с тех пор как я отключил C-States, не только кажется, что она стала более стабильной, но и, кажется, потребляет меньше энергии!

guruevi

Guest

10.01.2025 02:40:00

Проблемы с C-States на оборудовании AMD — это боль. Честно говоря, это сломано в Linux, и ни AMD, ни производители их материнских плат не хотят нормально это исправлять, перекладывая вину друг на друга. Сломано это и в Windows, хотя во многих случаях Microsoft заставляла AMD выпускать исправления через Windows Update. Могут быть какие-то обходные пути, но нужен скоординированный фикс между вашим CPU и прошивкой материнской платы, что не всегда доступно. AMD просто плевать на Linux. На серверах – да, а вот на десктопах – нет.

fba Guest	#6 0 10.01.2025 05:39:00 Посмотри на охлаждение твоего сервера. 72 градуса – это довольно жарко для диска.

simon098 Guest	#7 0 15.01.2025 10:58:00 Я покопался в этом, показания SMART не показывают фактическую температуру диска. Диски на самом деле около 40°C.

simon098

Guest

15.01.2025 11:01:00

Итак, небольшой промежуточный отчёт. Я уже пять дней работаю с отключенными Global C-States в BIOS и GRUB process.max_cstate=1. Это значительно больше, чем обычные 3-4 часа до зависания. Похоже, это решило мою проблему. Вчера я сбросил BIOS к заводским настройкам (снова включив Global C-States в BIOS), и всё ещё не зависло. Пока что GRUB process.max_cstate=1 кажется эффективным. Я ещё через несколько дней напишу, чтобы помочь другим несчастным, которые столкнулись с этими проблемами.

simon098

Guest

20.01.2025 23:57:00

Финальное обновление: я оставил BIOS с настройками по умолчанию и тестировал с `GRUB process.max_cstate=1` последние 5-6 дней, и ни разу не зависал. Интересно, что много людей жаловались, что это может помешать Turbo / динамическим частотам... лично я этого не заметил. А энергопотребление не хуже, чем было до изменения настроек mac C-State. Уверен, что отключение глобальных c-states тоже сработает так же. Но для тех, у кого есть такие проблемы, по крайней мере, теперь это задокументировано. Надеюсь, это поможет другим. Спасибо @Fantu.

matheeeew Guest	#10 0 20.03.2025 07:40:00 К слову, могу подтвердить, что отключение C-states решило проблему с зависанием моего Proxmox сервера каждый день без каких-либо логов в syslog или journalctl. AMD Ryzen 5 3600 и материнская плата ASRock.

simon098 Guest	#11 0 20.03.2025 10:05:00 Всегда приятно, когда больше людей подтверждают. Мой работает как часы с тех пор, а это уже больше шести недель назад.

matheeeew

Guest

#12

22.04.2025 19:06:00

Сказал как всегда слишком рано, через три недели проблема вернулась, теперь зависает каждый день — не могу описать, насколько я устал от этого дерьма. Это был конец моего пути по решению проблем, я сделал:
- Поменял SSD и SATA-кабель для диска Proxmox.
- Прогнал тест памяти, который показал зелёный результат.
- Очистил весь сервер.
- Убедился, что система не перегревается.

Куплю б/у i7 8700k и проверю, так же ли будет с Intel, если да, то я просто не знаю, что сказать по поводу этого дерьма.

drthrax232 Guest	#13 0 22.04.2025 22:18:00 Та же проблема здесь https://forum.proxmox.com/threads/random-crashes-of-the-node-in-cluster.165359/#post-765616 И на всех моих узлах на Ryzen… Похоже, обновление ядра решило проблему – стабильно работает уже 24 часа.

Читают тему

Главная Каталог 0 Корзина 0 Избранные Кабинет 0 Сравнение Акции Контакты Услуги Бренды Отзывы Компания Лицензии Документы Реквизиты Поиск Блог Обзоры