How to investigate delay from hibernate to shutdown?

[Gary1]

Recently (past two weeks or so) it has begun to take about a literal 10-15 minutes for my desktop to turn off after selecting hibernate. After clicking the hibernate button, the screen goes black for a few seconds and then comes back on displaying the screen with the menu open and the mouse pointer on the hibernate button, but mouse movement is not detected. That seems normal but it stays like that for the rest of the time.

And the last few days it also takes about the same time to start from hibernation; for it stays on the message about the hibernation image most of that time. However, after it completes, everything appears to work fine.

When I shutdown and restart, it starts much quicker; but, after working a while, will be slow to hibernate. I think it hibernates quickly if I do so immediately after reboot, just to test.

I’m using stable branch, 6.15 kernel, and KDE.

Any idea where I might begin to look to try and identify why this started?

Thank you.

[megavolt]

@Gary1

Any idea where I might begin to look to try and identify why this started?

Is there more RAM usage recently? That might add time for creating the hibernation image, also a slow disk can slow it down.

[Gary1]

Thanks. I don’t think so. I keep System Monitor open always and usually memory is under 5GiB; total is 32. It has SSD and I haven’t noticed anything running slow once it starts.

[megavolt]

@Gary1

I keep System Monitor open always and usually memory is under 5GiB

Well, cache and buffer of RAM also increases the hibernation image. System monitors don’t count it as used RAM. See:

free -h 

Of course, it is possible that 5 GB is used, but 20 GB is used as a cache/buffer. This happens after a while.

You can also investigate the journal. For example:

journalctl --boot -1 | sed -n -r "/Starting.+Hibernate/,/Finished.+Hibernate/p"

[Gary1]

Thank you. When should free -h be checked–any time or just before hibernation? It shows 3.6 GiB for buf/fcache now just after starting up.

[megavolt]

@Gary1

When should free -h be checked–any time or just before hibernation?

Don’t you think it makes sense to check it before hibernation?

@Gary1

It shows 3.6 GiB for buf/fcache now just after starting up.

It is quite normal to have cache here. Even if you drop the cache. It will be filled up again after time. The cache is used to reduce I/O and improved responsiveness.

sudo bash -c 'sync; echo 3 > /proc/sys/vm/drop_caches'

[Gary1]

Thanks. I didn’t know if this cache was an ever-growing item or an allocated space.

In your example of 5GiB with 20GiB cached, how does that relate to the swap size? Is that disk space where the data from hibernate is written. What happens if the cache exceeds the swap? I set the swap at 16GiB when installing Manjaro.

Well, I’ll have to see what the cache is after I finish working. I use SQLite and Tcl in the CLI a lot. Perhaps I need to exit the CLI session for them before hibernating, since SQLite caches many things also; but I don’t know where SQLite caches them–in RAM or a temporary on-disk file.

If I free -h and see a large cache and then close any Konsole sessions running SQLite, I suppose that memory will be released and another free -h will show that before hibernating.

[megavolt]

@Gary1

In your example of 5GiB with 20GiB cached, how does that relate to the swap size?

Cache/Buffer will never be dropped to a swap disk/file. It will be freed up, when more RAM gets allocated.

@Gary1

I set the swap at 16GiB when installing Manjaro.

Well, you have 32GB RAM and 16GB SWAP. After time, you will not be able to hibernate, since there have to be written a full image. If Linux decides to drop RAM pages to the SWAP, then this will add up to the image.

32GB + swapped space (e.g. 2GB) = 34GB. You would at least theoretically need 36GB of swap space, since it writes an entire image of the 34GB, not just 32GB, because the swapped 2GB count as “inactive” RAM. You can drop cache plus deactivate and activate swap to mitigate the problem, but more swap space would be the easy solution.

Since you can possibly have a lot of RAM usage, 64GB swap would be very well-equipped. But at least 1.5x32GB = 48GB, if Hibernation is really what you need.

I would recommend reading this to improve the swap problem:

[HowTo] Install and configure zram using zram-generator

Install and Configure ZRAM using zram-generator Note that zram is not compatible with hibernation unless combined with a swap device. If you are here just to have a quick install method you may skip to this section. Install zram-generator Execute: sudo pacman -Syu zram-generator Configure zram-generator Create file /etc/systemd/zram-generator.conf with contents: [zram0] zram-size = ram * 2 compression-algorithm = zstd swap-priority = 100 fs-ty…

[HowTo] Add a backing SWAP device to zram (and enable hibernation)

Introduction What is zram? How to use it? Please see this related guide: One of the main drawbacks to zram is its incompatibility with hibernation. For this and other reasons zram users may wish to create an additional ‘backing’ SWAP device. For quick-install steps skip to this section. Creating a swap file SWAP is a subject all its own, so for our purposes we will focus on the example of a swap file. The ArchWiki has a handy introduction here: https://wiki.archlinux.org/title/Swap#Swap…

[wpeckham]

IT appears to be the kernel. I ave discovered that kernels 6.12, 6.13, and 6.14 hibernate in about 18 seconds on my machine. With exactly the same apps, same desktop, same everything other than kernel the 6.15 and 6.16 kernels take 2 minutes and 11 seconds. It appears from the logs that they save off many more pages of memory, but I see no reason WHY and I am unsure that would explain the difference.

[Gary1]

Thank you. Thay may be the case; for I have not experienced this before started using kernel 6.15 and have not changed the applications I use or the way I’ve been using them.

I’ll have to try and compare the two. I booted under kernel 6.12 for yesterday’s work and when I hibernated the system and restarted about eight hours later netiher had the delay I posted. However, I didn’t do quite as much database work; so, it’s not exactly a fair comparison if that has an impact.

[wpeckham]

We will not KNOW if that makes a difference unless we run tests to VERIFY the difference. I will be interested to learn what you discover!

[Gary1]

I haven’t had time (and likely don’t have the ability) to identify the underlying issue if there is one; however, since booting under kernel 6.12 instead of 6.15 (on stable branch), I have not experienced a single delay hibernating/awaking these past three weeks.

[wpeckham]

My experience has been that hibernation delay appears on kernel 6.17, 6.16, and 6.15. No unusual delay appears on 6.14, 6.13, 6.12, or earlier available kernels. I think this one might be for the kernel team.