Режим гибернации

kol1978 · 06 октября 2024, 18:13:16

Цитата: dzhoser от 02 октября 2024, 09:56:56Добавить идентификатор swap, который uuid

В общем проблема не решена!!! но похоже определил "главную" причину (см. ниже)!

Все верно были проблемы с настройкой : 1 файл подкачки не может использоваться для "глубокого" сна - исключаем , используем только раздел 2 раздел диска подкачки указан буквой /dev/sda1? что приводит к проблемам - исключаем, используем № uuid 3 после внесения указанных изменений необходимо обновить загрузчик : обязательно две команды

Цитироватьsudo update-grub обновить конфигурацию системного загрузчика
sudo update-initramfs -u

Проверяем :

Цитироватьroot@kol:/home/kol# sudo blkid /dev/sda1 │
/dev/sda1: UUID="db590285-84aa-4da5-b85a-7f8d22e5e2f6" TYPE="swap" PARTUUID="7990e05b-6ff5-4a4d-bcfa-4f2adf3a0346"

UUID=db590285-84aa-4da5-b85a-7f8d22e5e2f6
sudo nano /etc/fstab
UUID=db590285-84aa-4da5-b85a-7f8d22e5e2f6 none swap sw 0 0
sudo nano /etc/initramfs-tools/conf.d/resume
RESUME=UUID=db590285-84aa-4da5-b85a-7f8d22e5e2f6
sudo nano /etc/default/grub
GRUB_CMDLINE_LINUX_DEFAULT=resume=UUID="UUID=db590285-84aa-4da5-b85a-7f8d22e5e2f6"

06 октября 2024, 18:17:12
В итоге гибернация работает (заработала) , но только без нагрузки!

И так : под подкачку выделил целиком диск 2Т :

Цитироватьroot@kol:/home/kol# lsblk │
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS │
sda 8:0 0 1,8T 0 disk │
└─sda1 8:1 0 1,8T 0 part [SWAP] │
sdb 8:16 0 2,7T 0 disk │
├─sdb1 8:17 0 186,3G 0 part │
└─sdb2 8:18 0 2,5T 0 part /var │
sdc 8:32 0 7,3T 0 disk │
├─sdc1 8:33 0 1M 0 part │
├─sdc2 8:34 0 27,9G 0 part / │
├─sdc3 8:35 0 977M 0 part │
└─sdc4 8:36 0 7,2T 0 part /home

Задаю нагрузку (пробную) системе :

Цитироватьkol@kol:~$ stress-ng --vm 1 --vm-bytes 50% --vm-method all --verify -t 10m

06 октября 2024, 18:24:15
И! при нагрузке в 50% гибернация работает на все 100%! Но! стоит увеличить нагрузку за счет увеличения количества потоков :

Цитироватьstress-ng --vm 15 --vm-bytes 90% --vm-method all --verify -t 10m

то гибернация на отрез отказывается выполняться!

Но при нагрузке :

Цитироватьstress-ng --vm 4 --vm-bytes 90% --vm-method all --verify -t 10m

- при нагрузке в четверть от возможной гибернация все еще работает , даже при использовании 99% ОЗУ, но если увеличить количество потоков то работать перестаёт!

Что с этим можно сделать!? в каком направлении двигаться?

06 октября 2024, 18:37:11
максимальная нагрузка при которой гибернация все еще работает :

Цитироватьol@kol:~$ stress-ng --vm 4 --vm-bytes 99% --vm-method all --verify -t 10m
stress-ng: info: [4993] setting to a 600 second (10 mins, 0.00 secs) run per stressor
stress-ng: info: [4993] dispatching hogs: 4 vm

Broadcast message from root@kol on pts/12 (Sun 2024-10-06 23:34:53 +08):

The system will hibernate now!

────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

0[||||||||||||||||||| 46.4%] 4[||||||||||||||||||||||||||||||||| 81.9%] 8[||||||||| 20.8%] 12[|| 4.5%]
1[|||||||| 19.2%] 5[||||||||||||||||||||||||| 59.5%] 9[||||||||||||||||||||||| 56.2%] 13[|||||||||||| 28.6%]
2[||||||||||||| 29.0%] 6[|||| 7.8%] 10[||||||||||||||||||||||||||||||||| 79.9%] 14[|| 1.9%]
3[||||||| 14.3%] 7[||||| 11.7%] 11[|||||||||||||||||||||||||||||||||||86.5%] 15[| 2.0%]
Mem[|||||||||||||||||||||||||||||||||||||||||||||||||||||| 113G/189G] Tasks: 91, 503 thr, 249 kthr; 6 running
Swp[|| 694M/1.82T] Load average: 6.23 4.46 4.82
Uptime: 02:29:17

[Main] [I/O]
PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command
5001 kol 20 0 46.6G 43.4G 892 R 101.3 22.5 1:34.43 stress-ng-vm [run]
4998 kol 20 0 46.6G 21.4G 892 R 100.6 11.1 1:34.42 stress-ng-vm [run]
4999 kol 20 0 46.6G 46.5G 892 R 100.6 24.1 1:34.41 stress-ng-vm [run]
5000 kol 20 0 46.6G 2311M 892 R 100.6 1.2 1:34.42 stress-ng-vm [run]
980 kol 20 0 3149M 48100 33596 S 13.6 0.0 6:46.31 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --xwayl
2810 kol 20 0 2980M 27948 20796 R 5.2 0.0 5:14.31 /usr/bin/konsole
4992 kol 20 0 8840 4944 3160 R 3.9 0.0 0:04.40 htop
2287 root 20 0 8788 3444 2028 S 3.2 0.0 1:40.34 htop
2898 root 20 0 8740 3412 2024 S 3.2 0.0 1:26.44 htop
993 kol 20 0 3149M 48100 33596 S 1.3 0.0 0:28.31 /usr/bin/kwin_wayland --wayland-fd 7 --socket wayland-0 --xwayland-fd 8 --xwayland-fd 9 --xwayland-display :1 --

Очень нужна помощь! Режим гибернации крайне важен и максимальная нагрузка в том числе. Что делать?

kol1978 · 15 октября 2024, 13:28:11

Цитата: ChubaDuba от 23 июля 2024, 18:14:25Попробуйте ядро и systemd сменить.

Посоветуй на что менять? на какую версию...старше? младше? на данный момент подготавливаю компиляцию - на что нужно сделать упор?

ChubaDuba · 15 октября 2024, 22:58:14

Цитата: kol1978 от 15 октября 2024, 13:28:11на какую версию...

из backports

kol1978 · 16 октября 2024, 05:54:42

Есть небольшие улучшения...

Установить пакет initramfs-tools deb:
# sudo apt-get install initramfs-tools
А так же ядро :

Цитироватьroot@servdebian12:/home/kol# sudo blkid /dev/sdc2
/dev/sdc2: UUID="1cfe3d6e-4f23-43f4-83d3-e74c4c25602a"

root@servdebian12:/home/kol# sudo update-grub
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-6.1.0-18-amd64
Found initrd image: /boot/initrd.img-6.1.0-18-amd64
Warning: os-prober will be executed to detect other bootable partitions.
Its output will be used to detect bootable binaries on them and create new boot entries.
Found Ubuntu 24.04.1 LTS (24.04) on /dev/mapper/ubuntu--vg-ubuntu--lv
done

root@servdebian12:/home/kol# sudo update-initramfs -u
update-initramfs: Generating /boot/initrd.img-6.1.0-18-amd64

Без нагрузки гибернация не имеет проблем...сейчас тестирую под нагрузкой

Цитироватьsudo sysctl vm.swappiness=1

Цитироватьstress-ng --vm 16 --vm-bytes 99% --vm-method all --verify -t 10m

stress-ng - может не самый хороший вариант, зато простой и понятный

Даже если получиться хочется разобраться в деталях...:

ЦитироватьОбратите внимание, что службы systemd-suspend.service, systemd-hibernate.service, systemd-hybrid-sleep.service и systemd-suspend-then-hibernate.service никогда не следует запускать напрямую. Вместо этого переведите систему в спящий режим с помощью таких команд, как systemctl suspend или systemctl hibernate.

по чему и в чем разница?
так

Цитироватьsudo systemctl start systemd-hibernate.service

или так

Цитироватьsudo systemctl start hibernate

16 октября 2024, 05:58:24

Цитата: Лия от 19 сентября 2024, 10:42:58
Цитата: dzhoser от 19 сентября 2024, 08:35:20умеет ли оно в S1 и S3
Цитата: kol1978 от 23 июля 2024, 18:37:13Кароче.. - на серверной убунте все сработало
Теоретически, если на Ubuntu работает, должно и на Debian с ядром из бэкпортов

Не понял пока как проверить но режимы нашел такие :

ЦитироватьSuspend to RAM (ждущий режим, сон)
Состояние S3 по определению ACPI. Отключает питание большинства устройств компьютера, кроме оперативной памяти, которая продолжает хранить в себе состояние компьютера для его восстановления при пробуждении. Из-за большой экономии энергии рекомендуется, чтобы ноутбуки автоматически входили в этот режим при работе от батареи и закрытой крышке (или когда пользователь неактивен в течение некоторого времени).
Suspend to disk (спящий режим, гибернация)
Состояние S4 по определению ACPI. Сохраняет состояние машины в подкачку и полностью выключает её. При включении питания состояние восстанавливается. До этого момента энергопотребление равно нулю.
Hybrid suspend (гибридный спящий режим)
Гибрид ждущего и спящего режимов, иногда называется suspend to both. Сохраняет состояние машины в подкачку, но не выключает её. Вместо этого выполняется переход в обычный ждущий режим. Поэтому, если батарея не разряжена, система может возобновить работу мгновенно. Если батарея разряжена, система может восстановить своё состояние с диска, что намного медленнее, чем возобновление работы из ОЗУ, но состояние не будет потеряно.

16 октября 2024, 06:01:18
К стати разница в том что убунта работает без этого :

Цитировать-------------------------------------------------------------------sudo nano /etc/initramfs-tools/conf.d/resume
echo "resume=UUID="fd28df29-5c68-46dd-93d3-131c6a56e1c3" | sudo tee /etc/initramfs-tools/conf.d/resume

но ей обязательно нужно это - sudo apt-get install initramfs-tools

16 октября 2024, 06:07:27

Цитата: ChubaDuba от 23 июля 2024, 18:14:25Попробуйте ядро и systemd сменить.

вот так как Лия предлагает :

Цитироватьsudo apt update
sudo apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64

Проверка прошла успешно! Но время выключения (гибернации) составило 1,5 часа

Проверял с помощью fio - что бы сохранить 200G на моём диске нужно всего 2 минуты!... $:-\$

17 октября 2024, 05:47:00
Попробовал ядра из бакпорта : 1

Цитироватьsudo apt-get -t bookworm-backports install linux-headers-6.9.10+bpo-amd64 linux-image-6.9.10+bpo-amd64

2

Цитироватьsudo apt install -t bookworm-backports linux-image-amd64 linux-headers-amd64

нормально работают но изменений (улучшений) в плане работы гибернации сравнительно с 6,1,-18 (но это ядро работает лучше чем при стандартной установке - бывает что переходит в гибернацию при загрузке 8 ядер...но все равно при максимальной нагрузке - 16 ядер, не может перейти в гибернацию).
Все то же самое: гибернация работает если загрузка ЦП только одного потока и (или) менее 50% возможной.
Пробую "поковырять" компиляцию ядра...появились вопросики - создам отдельную тему. PS попробовал старые ядра и дист.: Oracle Linux 9, openSUSE Tumbleweed - они не работают на моём железе вообще...Oracle даже диски не видит...(может позже попробую все же Oracle с установкой на флешку...слишком медленно , не хватило терпения; на виртуалке у него, Oracle, приятный вид

)

kol1978 · 17 октября 2024, 06:00:34

Помогите советом как дальше с этим "разбираться"? спросите у ИИ кто умеет вот сюда - duck.ai. $:-\$ или по другому???

kol1978 · 19 октября 2024, 06:12:56

И так: проверил компиляцией и установкой четыре ядра (с 6.1 по 6.10.11).. проверил настройки ядра (CONFIG_ARCH_HIBERNATION_HEADER=y) по умолчанию все включено... :

Цитировать-----------------------------
# Power management and ACPI options
#
CONFIG_ARCH_HIBERNATION_HEADER=y
CONFIG_SUSPEND=y
CONFIG_SUSPEND_FREEZER=y
CONFIG_HIBERNATE_CALLBACKS=y
CONFIG_HIBERNATION=y
CONFIG_HIBERNATION_SNAPSHOT_DEV=y
CONFIG_PM_STD_PARTITION=""
CONFIG_PM_SLEEP=y
CONFIG_PM_SLEEP_SMP=y
# CONFIG_PM_AUTOSLEEP is not set
# CONFIG_PM_USERSPACE_AUTOSLEEP is not set
# CONFIG_PM_WAKELOCKS is not set
CONFIG_PM=y
CONFIG_PM_DEBUG=y
# CONFIG_PM_ADVANCED_DEBUG is not set
# CONFIG_PM_TEST_SUSPEND is not set
CONFIG_PM_SLEEP_DEBUG=y
CONFIG_PM_TRACE=y
CONFIG_PM_TRACE_RTC=y
# CONFIG_WQ_POWER_EFFICIENT_DEFAULT is not set
# CONFIG_ENERGY_MODEL is not set
CONFIG_ARCH_SUPPORTS_ACPI=y
CONFIG_ACPI=y
CONFIG_ACPI_LEGACY_TABLES_LOOKUP=y
CONFIG_ARCH_MIGHT_HAVE_ACPI_PDC=y
CONFIG_ACPI_SYSTEM_POWER_STATES_SUPPORT=y
# CONFIG_ACPI_DEBUGGER is not set
CONFIG_ACPI_SPCR_TABLE=y
# CONFIG_ACPI_FPDT is not set
CONFIG_ACPI_LPIT=y
CONFIG_ACPI_SLEEP=y
CONFIG_ACPI_REV_OVERRIDE_POSSIBLE=y
# CONFIG_ACPI_EC_DEBUGFS is not set
CONFIG_ACPI_AC=y
CONFIG_ACPI_BATTERY=y
CONFIG_ACPI_BUTTON=y
CONFIG_ACPI_VIDEO=y
CONFIG_ACPI_FAN=y
# CONFIG_ACPI_TAD is not set
CONFIG_ACPI_DOCK=y
CONFIG_ACPI_CPU_FREQ_PSS=y
CONFIG_ACPI_PROCESSOR_CSTATE=y
CONFIG_ACPI_PROCESSOR_IDLE=y
CONFIG_ACPI_CPPC_LIB=y
CONFIG_ACPI_PROCESSOR=y
CONFIG_ACPI_HOTPLUG_CPU=y
# CONFIG_ACPI_PROCESSOR_AGGREGATOR is not set
CONFIG_ACPI_THERMAL=y
CONFIG_ARCH_HAS_ACPI_TABLE_UPGRADE=y
CONFIG_ACPI_TABLE_UPGRADE=y
# CONFIG_ACPI_DEBUG is not set
# CONFIG_ACPI_PCI_SLOT is not set
CONFIG_ACPI_CONTAINER=y
CONFIG_ACPI_HOTPLUG_IOAPIC=y
# CONFIG_ACPI_SBS is not set
# CONFIG_ACPI_HED is not set
# CONFIG_ACPI_CUSTOM_METHOD is not set
CONFIG_ACPI_BGRT=y
# CONFIG_ACPI_NFIT is not set
CONFIG_ACPI_NUMA=y
# CONFIG_ACPI_HMAT is not set
CONFIG_HAVE_ACPI_APEI=y
CONFIG_HAVE_ACPI_APEI_NMI=y
# CONFIG_ACPI_APEI is not set
# CONFIG_ACPI_DPTF is not set
# CONFIG_ACPI_CONFIGFS is not set
# CONFIG_ACPI_PFRUT is not set
CONFIG_ACPI_PCC=y
# CONFIG_PMIC_OPREGION is not set
CONFIG_ACPI_PRMT=y
CONFIG_X86_PM_TIMER=y

-----------------------------------

Дело не в этом... но попробую отсюда : git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git

PS жду комментариев...

19 октября 2024, 07:33:06
эх...

. 6.12.0-rc3 не захотел работать

kol1978 · 20 октября 2024, 06:28:32

Использовал настройки (.config) этого ядра linux image: /boot/vmlinuz-6.1.0-18-amd64 (поставляемого с установщиком) но компиляцию выполнил в окружении предназначенном для компиляции ядра stable-backports 6.10.11-1~bpo12+1, и получилось
linux-libc-dev_6.1.112-1_amd64.deb, которое после установки "разжаловала" ---:/usr/src/linux-config-6.1$ dpkg: предупреждение: снижение версии linux-libc-dev с 6.10.11-1~bpo12+1 до 6.1.112-1... но! только после установки, а до этого компиляция выполнялась в среде 6.10.11!
В результате такой "странной" процедуры появилось положительное явление : теперь гибернация происходит при загрузке всех ядер! но только при использовании 50% ОЗУ...

Цитироватьkol@servdebian12:~$ stress-ng --vm 16 --vm-bytes 50% --vm-method all --verify -t 30m
stress-ng: info: [2134] setting to a 1800 second (30 mins, 0.00 secs) run per stressor
stress-ng: info: [2134] dispatching hogs: 16 vm

Tasks: 267 total, 15 running, 252 sleeping, 0 stopped, 0 zombie
%Cpu(s): 28,7 us, 60,5 sy, 0,0 ni, 1,0 id, 9,6 wa, 0,0 hi, 0,2 si, 0,0 st
MiB Mem : 193410,2 total, 124317,2 free, 69788,5 used, 331,6 buff/cache
MiB Swap: 190734,0 total, 186572,4 free, 4161,6 used. 123621,7 avail Mem

PID USER PR NI VIRT RES SHR S %CPU %MEM TIME+ COMMAND
2151 kol 20 0 6188924 5,0g 1108 R 100,0 2,6 3:17.20 stress-ng-vm
2154 kol 20 0 6188924 5,0g 1108 R 100,0 2,6 3:17.46 stress-ng-vm
2157 kol 20 0 6188924 1,4g 1108 R 100,0 0,8 2:51.31 stress-ng-vm
2158 kol 20 0 6188924 3,0g 1108 R 100,0 1,6 3:17.35 stress-ng-vm
2159 kol 20 0 6188924 1,8g 1108 R 100,0 1,0 3:17.52 stress-ng-vm
2163 kol 20 0 6188924 5,9g 1108 R 100,0 3,1 3:17.61 stress-ng-vm
2164 kol 20 0 6188924 4,0g 1108 R 100,0 2,1 3:17.46 stress-ng-vm
2152 kol 20 0 6188924 354824 1108 R 99,7 0,2 3:17.24 stress-ng-vm
2153 kol 20 0 6188924 5,9g 1108 R 99,7 3,1 3:17.42 stress-ng-vm
2156 kol 20 0 6188924 5,1g 1108 R 99,7 2,7 3:17.44 stress-ng-vm
2160 kol 20 0 6188924 4,5g 1108 R 99,7 2,4 3:17.49 stress-ng-vm
2162 kol 20 0 6188924 4,6g 1108 R 99,7 2,5 3:17.47 stress-ng-vm
2165 kol 20 0 6188924 5,9g 1108 R 99,7 3,1 3:17.63 stress-ng-vm
2166 kol 20 0 6188924 1,1g 1108 R 99,7 0,6 3:17.41 stress-ng-vm
2155 kol 20 0 6188924 3,3g 1108 D 12,5 1,7 2:56.69 stress-ng-vm
2161 kol 20 0 6188924 5,3g 1108 D 12,5 2,8 3:06.67 stress-ng-vm
796 root 20 0 2470044 19220 12340 S 2,3 0,0 0:08.87 Xorg

И ! есть подозрение из за чего:
image_size

ЦитироватьЭтот файл управляет размером образов гибернации.
В него можно записать строку, представляющую собой неотрицательное целое число, которое будет использоваться в качестве максимально возможного верхнего предела размера образа в байтах. Ядро гибернации сделает всё возможное, чтобы размер образа не превышал это число, но если это окажется невозможным, образ гибернации всё равно будет создан, и его размер будет максимально небольшим. В частности, запись «0» в этот файл приводит к тому, что размер образов гибернации будет минимальным.
При чтении из него возвращается текущий предел размера изображения, который по умолчанию составляет примерно 2/5 от доступного объёма оперативной памяти.

Подсистема управления питанием предоставляет пользовательскому пространству единый sysfs интерфейс для перехода системы в спящий режим независимо от базовой архитектуры или платформы.
Этот интерфейс находится в каталоге /sys/power/ (при условии, что sysfs смонтирован в /sys) и состоит из следующих атрибутов (файлов):
--
root@debian:/sys/power# ls -l
итого 0
-rw-r--r-- 1 root root 4096 окт 18 13:26 disk
-rw-r--r-- 1 root root 4096 окт 18 14:19 image_size
-rw-r--r-- 1 root root 4096 окт 18 14:19 mem_sleep
-rw-r--r-- 1 root root 4096 окт 18 14:19 pm_async
-rw-r--r-- 1 root root 4096 окт 18 14:19 pm_debug_messages
-rw-r--r-- 1 root root 4096 окт 18 14:19 pm_freeze_timeout
-rw-r--r-- 1 root root 4096 окт 18 14:19 pm_print_times
-rw-r--r-- 1 root root 4096 окт 18 14:19 pm_test
-r--r--r-- 1 root root 4096 окт 18 14:19 pm_wakeup_irq
-rw-r--r-- 1 root root 4096 окт 18 14:19 reserved_size
-rw-r--r-- 1 root root 4096 окт 18 13:26 resume
-rw-r--r-- 1 root root 4096 окт 18 13:26 resume_offset
-rw-r--r-- 1 root root 4096 окт 18 13:26 state
drwxr-xr-x 2 root root 0 окт 18 14:19 suspend_stats
-rw-r--r-- 1 root root 4096 окт 18 14:19 sync_on_suspend
-rw-r--r-- 1 root root 4096 окт 18 14:19 wakeup_count
root@debian:/sys/power#

20 октября 2024, 06:28:42
PS жду комментариев...

20 октября 2024, 13:44:24
Устал...

kol@servdebian12:~$ sudo cat /sys/power/image_size
81094598656 -> 75,53Gb
должен быть :

Цитироватьol@servdebian12:~$ sudo swapon --show
[sudo] пароль для kol:
NAME TYPE SIZE USED PRIO
/dev/sdc1 partition 186,3G 4M -2
kol@servdebian12:~$ free -h
total used free shared buff/cache available
Mem: 188Gi 3,0Gi 182Gi 36Mi 4,7Gi 185Gi
Swap: 186Gi 4,0Mi 186Gi
kol@servdebian12:~$

nano /sys/power/image_size -> 202 937 204 736 Байт (B)
(двести два миллиарда девятьсот тридцать семь миллионов двести четыре тысячи семьсот тридцать шесть).
Если изменить файл image_size то после перезагрузки он возвращается в исходное состояние...

PS жду комментариев...

Полученное Ядро если кому может будет интересно...:
20 октября 2024, 13:47:12
https://cloud.mail.ru/public/cz3u/Cp4eSQtGxhttps://cloud.mail.ru/public/cz3u/Cp4eSQtGx

kol1978 · 21 октября 2024, 14:55:03

AAAAAAAAAAAAAAAAAAAAAAAA!!!!!!!!!!!!!!!!!!!!!!!!

ЦитироватьО: Мы используем обычные пути ввода-вывода. Однако мы не можем восстановить данные
в исходное местоположение при их загрузке. Это создало бы несогласованное состояние ядра, которое, несомненно, привело бы к сбою.
Вместо этого мы загружаем изображение в неиспользуемую память, а затем атомарно копируем его обратно в исходное местоположение.
Это, конечно, подразумевает максимальный размер изображения, равный половине объёма памяти!

!!!!!!!!!!!

22 октября 2024, 06:27:27
Это хорошо бы если при использовании 75 гигабайт ОЗУ и всех 16 потоков гибернация все еще работала...но на деле только так :

Цитировать0[||||||||||||||||||||||||||||||100.0%] 4[||||||||||||||||||||||||||||||100.0%] 8[||||||||||||||||||||||||||||||100.0%] 12[||||||||||||||||||||||||||||||100.0%]
1[||||||||||||||||||||||||||||||100.0%] 5[||||||||||||||||||||||||||||||100.0%] 9[||||||||||||||||||||||||||||||100.0%] 13[||||||||||||||||||||||||||||||100.0%]
2[||||||||||||||||||||||||||||||100.0%] 6[||||||||||||||||||||||||||||||100.0%] 10[||||||||||||||||||||||||||||||100.0%] 14[||||||||||||||||||||||||||||||100.0%]
3[||||||||||||||||||||||||||||||100.0%] 7[||||||||||||||||||||||||||||||100.0%] 11[||||||||||||||||||||||||||||||100.0%] 15[||||||||||||||||||||||||||||||100.0%]
Mem[||||| 3.25G/189G] Tasks: 104, 66 thr, 201 kthr; 16 running
Swp[|| 4.84M/386G] Load average: 11.43 3.56 1.25
Uptime: 00:48:42

[Main] [I/O]
PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command
1620 root 20 0 174M 121M 864 R 101.0 0.1 0:27.93 stress-ng-vm [run]
1628 root 20 0 174M 120M 864 R 101.0 0.1 1:17.21 stress-ng-vm [run]
1621 root 20 0 174M 121M 1028 R 100.4 0.1 0:37.48 stress-ng-vm [run]
1622 root 20 0 174M 121M 1112 R 100.4 0.1 1:17.31 stress-ng-vm [run]
1623 root 20 0 174M 121M 924 R 100.4 0.1 0:25.72 stress-ng-vm [run]
1625 root 20 0 174M 121M 896 R 100.4 0.1 0:35.79 stress-ng-vm [run]
1626 root 20 0 174M 121M 1056 R 100.4 0.1 0:37.55 stress-ng-vm [run]
.....................................................................................

22 октября 2024, 06:30:28
продолжаю тестировать другие ядра...но уже увидел неприятную тенденцию : при возобновлении работы после гибенации не все
процессы "стартуют" (продолжают работать как в начале) и мало того возникают проблемы с их остановкой :

Цитироватьstress-ng: warn: [4312] cannot terminate process 4330, gave up after 120 seconds
stress-ng: warn: [4315] cannot terminate process 4328, gave up after 120 seconds
stress-ng: warn: [4300] cannot terminate process 4314, gave up after 120 seconds
stress-ng: warn: [4301] cannot terminate process 4317, gave up after 120 seconds
stress-ng: warn: [4304] cannot terminate process 4321, gave up after 120 seconds
stress-ng: warn: [4306] cannot terminate process 4324, gave up after 120 seconds
stress-ng: warn: [4316] cannot terminate process 4329, gave up after 120 seconds
stress-ng: warn: [4305] cannot terminate process 4322, gave up after 120 seconds
stress-ng: info: [4299] skipped: 0

kol1978 · 25 октября 2024, 08:14:37

Тестирую другие дистрибутивы вмести с другими ядрами... Что получается на данный момент:
Дистрибутив "РЕД ОС" (https://redos.red-soft.ru/base/redos-7_3/7_3-administation/7_3-images-os/7_3-dracut/?nocache=1729831698391) с ядром 6.1 показало себя лучшим образом - происходит гибернация при загрузке всех ядер и ОЗУ на 50% (70 Гигов) и указанные выше проблемы гибернации (процессы не пробуждаются) только при 99%-100% загрузке (при этом гибернация и просыпание происходит, но не все процессы продолжают работать дальше в нормальном режиме) :

Цитировать0[|||||||||||||||||||100.0%] 4[|||||||||||||||||||100.0%] 8[|||||||||||||||||||100.0%] 12[|||||||||||||||||||100.0%]
1[|||||||||||||||||||100.0%] 5[|||||||||||||||||||100.0%] 9[|||||||||||||||||||100.0%] 13[|||||||||||||||||||100.0%]
2[|||||||||||||||||||100.0%] 6[|||||||||||||||||||100.0%] 10[|||||||||||||||||||100.0%] 14[|||||||||||||||||||100.0%]
3[|||||||||||||||||||100.0%] 7[|||||||||||||||||||100.0%] 11[|||||||||||||||||||100.0%] 15[||||||||||||||||||||99.4%]
Mem[||||||||||||||||||||||||||||||||||||||||||||||180G/189G] Tasks: 169, 358 thr, 215 kthr; 0 running
Swp[ 0K/204G] Load average: 15.43 7.79 3.21
Uptime: 00:05:26

[Main] [I/O]
PID USER PRI NI VIRT RES SHR S CPU%▽MEM% TIME+ Command
3528 root 20 0 11.5G 11.5G 2024 R 98.8 6.1 2:17.83 stress-ng-vm [run]
3529 root 20 0 11.5G 11.5G 2092 R 98.8 6.1 2:16.78 stress-ng-vm [run]
3530 root 20 0 11.5G 11.5G 2092 R 98.8 6.1 2:16.22 stress-ng-vm [run]
3531 root 20 0 11.5G 11.5G 2092 R 98.8 6.1 2:15.01 stress-ng-vm [run]
......................................................................

Использую нагрузку

Цитироватьstress-ng --cpu 8 --io 4 --vm 16 --vm-bytes 180G --timeout 30m --metrics-brief
stress-ng --sequential 0 --class io --timeout 30m --metrics-brief

в замен

Цитироватьstress-ng --vm 16 --vm-bytes 99% --vm-method all --verify -t 30m

так как выяснил что это более стабильная нагрузка и больше приближенна к реальной (добавил дисковую подсистему).

Так что и железо и ОС принципиально могут выполнять гибернацию при полной загрузке ЦП и загрузке ОЗУ на 50%.
Дело в настройках ОС и ядра... какие еще настройки нужно смотреть и что в ядре?

dzhoser · 25 октября 2024, 10:02:12

Попробуйте создать баг репорт.
https://www.debian.org/Bugs/Reporting.ru.html

kol1978 · 05 ноября 2024, 07:00:34

Цитата: dzhoser от 25 октября 2024, 10:02:12Попробуйте создать баг репорт.
https://www.debian.org/Bugs/Reporting.ru.html

Чтобы создавать подобные (предлагаемые) сообщения, необходимо отделить (уже на данном этапе) "мух от котлет" : что является отсутствием настройки, а что ошибкой? ошибкой кода? ошибкой настройки по умолчанию? и т.д.

1.Поэтому на данном этапе необходимо знать - функция гибернации должна работать для дистрибутива "из коробки" при условии что в процессе установки в обязательном порядке выделен раздел для(под) swap (и ни каких дополнительных настроек и установки пакетов не нужно)?

05 ноября 2024, 12:15:26
2. После проверки настроек, убеждаемся что все настроено как "нужно" :

Цитироватьhttps://blog.ivansmirnov.name/how-to-set-up-hibernate-on-ubuntu-20-04/

; как мною выяснено для debian не нужно это :

Цитироватьecho RESUME=UUID=2ae674d7-6b75-4680-93c5-6d11c7bfb9b2 | sudo tee /etc/initramfs-tools/conf.d/resume

или как минимум эта настройка ничего не меняет, и в том числе установлены доп. пакеты

Цитироватьsudo apt-get install hibernate -> E: Для пакета «hibernate» не найден кандидат на установку

sudo apt-get install pm-utils

в таком случае, гибернация должна работать? при следующей нагрузке:

Цитировать$cat /sys/power/image_size
4000000000
4000000000 Байт = 3.7253 Gibibytes
4000000000 Байт = 4 Гигабайт

16384 Mebibytes = 16 Gibibytes объем ОЗУ

16*(2/5)=6,4 Gibibytes около 2/5 ОЗУ

stress-ng --cpu 8 --io 4 --vm 16 --vm-bytes 6.4G --timeout 1m --metrics-brief
stress-ng --cpu 8 --io 4 --vm 16 --vm-bytes 4000000000 --timeout 1m --metrics-brief

Указанная "нагрузка" будет говорить о том - возможна ли гибернация при условии необходимости создания для неё образа гибернации более 2/5 от размера ОЗУ? Пример взял с виртуальной машины, но проверять нужно разумеется только на реальном железе...

05 ноября 2024, 07:28:41
В процессы своей проверки выяснил что гибернация работает "из коробки" только при нагрузке менее указанной выше ( --vm-bytes 4000000000) - это ошибка?

ЦитироватьПеревести систему в спящий режим:
echo platform > /sys/power/disk; echo disk > /sys/power/state
или :
sudo systemctl hibernate

Вопрос гибернации не такой простой... как может показаться :

ЦитироватьS4 приостановка с сохранением на диск («гибернация», в настоящее время не поддерживается в NetBSD)

, на данный момент проверил похоже все дистрибутивы на то как дело с гибернацией обстоит там (не только у подделок но и у реальных Unix)

Создам наверное отдельную тему...

05 ноября 2024, 07:37:55
PS

ЦитироватьЧасто задаваемые вопросы
==========================

Вопрос: на мой взгляд, приостанавливать работу сервера — это действительно глупая затея,
но... (Диего Зуккато):

Ответ: вы купили новый ИБП для своего сервера. Как его установить, не выключая
машину? Приостановите работу на диске, переставьте кабели питания,
возобновите работу.

Ваш сервер подключен к ИБП. Питание отключилось, и ИБП показывает, что до сбоя осталось 30
секунд. Что вы делаете? Приостановите работу на диске.

В: Возможно, я что-то упускаю, но почему не работают обычные пути ввода-вывода?

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

Есть два решения этой проблемы:

* во время приостановки требуется, чтобы половина памяти была свободна. Таким образом, вы можете
считывать «новые» данные в свободные ячейки, а затем копировать

kol1978 · **Вчера** в 07:36:30

и так ! заканчивая этот пост...:
Лидером в тестах дистрибутивов на гибернацию оказался - openSUSE Tumbleweed

его показатели: при нагрузке процессами ОЗУ до 1/2 гибернация происходит без нареканий, при нагрузке более 1/2 ОЗУ гибернация происходит но не все процессы после этого продолжают работу... и только при нагрузке в 120% ОЗУ - когда после заполнения оперативной памяти активно задействуется Swap виртуальной памяти...только в этом случае система отказывается выполнять гибернацию!
при этом мои параметры :

Цитироватьlocalhost:/home/kol # free -m
total used free shared buff/cache available
Mem: 193409 2200 191806 39 554 191208
Swap: 215039 1104 213935

нагрузка :

Цитироватьlocalhost:/home/kol # stress-ng --cpu 8 --io 4 --vm 16 --vm-bytes 250G --timeout 40m --metrics-brief

сообщения :

Цитироватьноя 05 22:44:00 localhost.localdomain NetworkManager[1276]: <info> [1730817840.7211] manager: sleep: sleep requested (sleeping: no enabled: yes)
ноя 05 22:44:00 localhost.localdomain NetworkManager[1276]: <info> [1730817840.7287] manager: NetworkManager state is now ASLEEP
ноя 05 22:44:03 localhost.localdomain systemd-sleep[9030]: INFO: running /usr/lib/systemd/system-sleep/grub2.sleep for hibernate
ноя 05 22:44:03 localhost.localdomain systemd-sleep[9030]: INFO: Running prepare-grub ..
ноя 05 22:44:15 localhost.localdomain systemd[1]: Starting PackageKit Daemon...
ноя 05 22:44:16 localhost.localdomain PackageKit[9076]: daemon start
ноя 05 22:44:25 localhost.localdomain systemd-sleep[9030]: running kernel is grub menu entry openSUSE Tumbleweed (vmlinuz-6.11.5-1-default)
ноя 05 22:44:25 localhost.localdomain systemd-sleep[9030]: preparing boot-loader: selecting entry openSUSE Tumbleweed, kernel /boot/6.11.5-1-default
ноя 05 22:44:26 localhost.localdomain systemd-sleep[9030]: running /usr/sbin/grub2-once "openSUSE Tumbleweed"
client_loop: send disconnect: Broken pipe
kol@kol-VirtualBox:~$ ps

Вчера в 07:39:26
особенно удивляет это :

Цитироватьноя 05 22:44:00 localhost.localdomain systemd-sleep[9028]: This is a temporary downstream workaround for https://github.com/systemd/systemd/issues/33083.

Посмотрел

Цитироватьhttps://github.com/systemd/systemd/issues/33083

...
Заинтересовало это :

ЦитироватьНа мой взгляд, такое поведение характерно для зависания из-за нехватки памяти.
Ситуация кажется достаточно напряжённой: одновременная компиляция программного обеспечения и декодирование видео.
Если у вас всё ещё есть логи этой загрузки, попробуйте посмотреть, сработало ли ядро OOM-убийца и завершило ли какой-либо процесс (это будет записано в журнал).

И! по идеи команды :

Цитироватьcat /sys/power/suspend_stats/success
cat /sys/power/suspend_stats/fail
cat /sys/power/suspend_stats/failed_prepare

должны хотя бы намекать на происходящее при неудачных попытках гибернации...Но! нет :

Цитироватьkol@localhost:~> cat /sys/power/suspend_stats/failed_prepare
0
kol@localhost:~> cat /sys/power/suspend_stats/success
0
kol@localhost:~> sudo systemctl hibernate

Broadcast message from root@localhost on pts/7 (Wed 2024-11-06 12:10:10 +08):

The system will hibernate now!

kol@localhost:~> cat /sys/power/suspend_stats/fail
0
kol@localhost:~> cat /sys/power/suspend_stats/success
0
kol@localhost:~> sudo systemctl hibernate

Broadcast message from root@localhost on pts/7 (Wed 2024-11-06 12:11:21 +08):

The system will hibernate now!

kol@localhost:~> cat /sys/power/suspend_stats/success
0
kol@localhost:~> sudo systemctl hibernate

Broadcast message from root@localhost on pts/7 (Wed 2024-11-06 12:13:29 +08):

The system will hibernate now!

kol@localhost:~>
kol@localhost:~> cat /sys/power/suspend_stats/success
0
kol@localhost:~> cat /sys/power/suspend_stats/fail

0
kol@localhost:~>
kol@localhost:~> cat /sys/power/suspend_stats/failed_prepare
0
kol@localhost:~>

Вчера в 07:42:21
И ! смотрим журнал (как умеем..) :

Цитировать-----------------
kol@localhost:~> dmesg | grep -Ei "fail|error"
[ 0.752502] [ T1] pci 0000:01:00.0: VF BAR 3 [mem size 0x00020000 64bit]: failed to assign
[ 0.752507] [ T1] pci 0000:01:00.1: VF BAR 0 [mem size 0x00020000 64bit]: failed to assign
[ 0.752512] [ T1] pci 0000:01:00.1: VF BAR 3 [mem size 0x00020000 64bit]: failed to assign
[ 1.694059] [ T1] RAS: Correctable Errors collector initialized.
[ 902.559505] [ T4768] Freezing user space processes failed after 20.003 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1102.577715] [ T5491] Freezing user space processes failed after 20.011 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1178.186467] [ T6199] Freezing user space processes failed after 20.000 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1245.295521] [ T1521] mce: [Hardware Error]: Machine check events logged
[ 1412.668958] [ T1521] mce: [Hardware Error]: Machine check events logged
[ 1426.393228] [ T1521] mce: [Hardware Error]: Machine check events logged
[ 1426.393246] [ T1521] EDAC MC1: 2 CE error on CPU#1Channel#0_DIMM#0 (channel:0 slot:0 page:0x0 offset:0x0 grain:8 syndrome:0x0)
[ 1426.462954] [ T1521] EDAC MC1: 1 CE error on CPU#1Channel#0_DIMM#0 (channel:0 slot:0 page:0x0 offset:0x0 grain:8 syndrome:0x0)
[ 1567.020171] [ T6901] Freezing user space processes failed after 20.006 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1636.077127] [ T7634] Freezing user space processes failed after 20.001 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1706.705500] [ T8218] Freezing user space processes failed after 20.001 seconds (1 tasks refusing to freeze, wq_busy=0):
[ 1834.478647] [ T8933] Freezing user space processes failed after 20.007 seconds (1 tasks refusing to freeze, wq_busy=0):
kol@localhost:~>
-------------------------------------
kol@localhost:~> journalctl -b | grep -Ei "fail|error"
Hint: You are currently not seeing messages from other users and the system.
Users in the 'systemd-journal' group can see all messages. Pass -q to
turn off this notice.
ноя 06 11:44:05 localhost.localdomain kded6[2135]: org.kde.libkbolt: Failed to connect to Bolt manager DBus interface:
ноя 06 11:44:10 localhost.localdomain kded6[2135]: kf.bluezqt: PendingCall Error: "Could not activate remote peer 'org.bluez': unit failed"
ноя 06 11:44:10 localhost.localdomain kscreen_backend_launcher[2288]: kscreen.xcb.helper: Event Error: 147
ноя 06 11:44:13 localhost.localdomain org_kde_powerdevil[2338]: Failed to create wl_display (No such file or directory)
ноя 06 11:44:14 localhost.localdomain org_kde_powerdevil[2338]: org.kde.powerdevil: [DDCutilDetector]: Failed to initialize callback
ноя 06 11:44:16 localhost.localdomain org_kde_powerdevil[2338]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "Charge thresholds are not supported by the kernel for this hardware"
ноя 06 11:44:16 localhost.localdomain org_kde_powerdevil[2338]: org.kde.powerdevil: org.kde.powerdevil.backlighthelper.brightness failed
ноя 06 11:44:17 localhost.localdomain org_kde_powerdevil[2338]: org.kde.powerdevil: org.kde.powerdevil.chargethresholdhelper.getthreshold failed "Charge thresholds are not supported by the kernel for this hardware"
ноя 06 11:44:17 localhost.localdomain kwin_x11[2013]: kf.config.core: "\"fsrestore1\" - conversion of \"0,0,0,0\" to QRect failed"
ноя 06 11:44:17 localhost.localdomain kwin_x11[2013]: kf.config.core: "\"fsrestore2\" - conversion of \"0,0,0,0\" to QRect failed"
ноя 06 11:44:17 localhost.localdomain kwin_x11[2013]: kf.config.core: "\"fsrestore3\" - conversion of \"0,0,0,0\" to QRect failed"
ноя 06 11:44:25 localhost.localdomain plasmashell[2282]: error getting max keyboard brightness via dbus QDBusError("org.freedesktop.DBus.Error.UnknownObject", "No such object path '/org/kde/Solid/PowerManagement/Actions/KeyboardBrightnessControl'")
ноя 06 11:44:32 localhost.localdomain opensuse-welcome[3478]: [3478:7:1106/114432.036496:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
ноя 06 11:44:32 localhost.localdomain opensuse-welcome[3482]: [3482:7:1106/114432.066040:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
ноя 06 11:44:32 localhost.localdomain opensuse-welcome[3481]: [3481:7:1106/114432.069236:ERROR:command_buffer_proxy_impl.cc(141)] ContextResult::kTransientFailure: Failed to send GpuChannelMsg_CreateCommandBuffer.
ноя 06 12:14:12 localhost.localdomain systemd[1697]: drkonqi-coredump-pickup.service: Failed with result 'timeout'.
kol@localhost:~>

Нужны рекомендации (команды) для просмотра журнала (" ядро OOM-убийца") при моделировании ситуации?

это для следующего поста...