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

[kol1978]

Добавить идентификатор 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]

Попробуйте ядро и systemd сменить.

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

[ChubaDuba]

на какую версию...

из backports

[kol1978]

Есть небольшие улучшения...   Установить пакет 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

умеет ли оно в S1 и S3

Кароче.. - на серверной убунте все сработало

Теоретически, если на 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

Попробуйте ядро и 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]

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

[kol1978]

И так: проверил компиляцией и установкой четыре ядра (с 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]

Использовал настройки (.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]

  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