After updating the laptop OS from Kubuntu 20.04 to 22.04 i started experiencing RAM issue i didn't have before on 20.04. The laptop has 8GB Ram and my normal workload is using PyCharm, Vivaldi, Alacritty, Typora, Obsidian. All of them consume less then 8GB. On 22.04 when i run Vivaldi and PyCharm all the memory is swallowed up by them, i have no idea why, but OS functioning became unstable and sometimes i even press hard reboot.
Unfortunately, there are no slots for extending memory and the default swap volume size is around 1GB after standard Ubuntu installation that is used in the case when no free memory is available. All the swap size is also occupied by the two applications and not released. The other point is that OS started cachhing data more aggressively i guess, i failed to release memory by a few approaches
I play Dota 2 from time to time and to run it all the other apps must be closed due to the RAM issue, what an inconvenience. After finishing a couple of games the cache was overfilled and OS gets frozen, that's a total crap. Do you feel my pain now?
According to impossibility of just plugging in one more memory bar a solution to get OS functioning back to stable is only to resize the swap. But it turned out that such the operation is complicated due to LVM based swap as Ubuntu manages volumes with it since 20.04 and i had no free disk space in an LVM pool to add it to the swap volume quickly.
In order to solve the problem a few long and unsafe operations had to be done:
- Learn how to shrink the space of a file system
- Shrink it on the laptop disk
- Extend the swap file size
- Test OS stability
Display initial disk states to compare to the ones at the end.
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgkubuntu-root 467G 305G 138G 69% / /dev/mapper/vgstoragebox-home--backup 290G 161G 114G 59% /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 1.8T 0 disk └─luks-4b0ed59d-059f-4f09-b204-1de0e18646ac 253:3 0 1.8T 0 crypt ├─vgstoragebox-home--backup 253:4 0 295G 0 lvm /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243 nvme0n1 259:0 0 476.9G 0 disk └─nvme0n1p3 259:3 0 475.7G 0 part └─nvme0n1p3_crypt 253:0 0 475.7G 0 crypt ├─vgkubuntu-root 253:1 0 474.8G 0 lvm / └─vgkubuntu-swap_1 253:2 0 980M 0 lvm
By default, when Kubuntu is installed on a LUKS fully encrypted disk LVM management split all the space into two LVM volumes
$ sudo lvs vgkubuntu LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root vgkubuntu -wi-ao---- 474.75g swap_1 vgkubuntu -wi-a----- 980.00m
Therefore, having no space
VFree 0 blocks me from easily extending the swap.
$ sudo vgs vgkubuntu VG #PV #LV #SN Attr VSize VFree vgkubuntu 1 2 0 wz--n- <475.71g 0
The first thing have to be done is releasing some space from
root which will be added to the
swap_1 volume after.
The important notice, releasing file system space is not equal to releasing LVM space. The both have to be done. If to reduce an lvm volume only there is potential to corrupt your data.
Operations on modifying disk space are unsafe and irreversible, due to that, i prefer to make it on an external HDD as a test attempt for further reproducing it on the laptop disk.
There is already the existent backup volume
vgstoragebox-home--backup on the HDD that i'm going to shrink it to see how it works, what problems will appear, and how to solve them.
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS sda 8:0 0 1.8T 0 disk └─luks-4b0ed59d-059f-4f09-b204-1de0e18646ac 253:3 0 1.8T 0 crypt ├─vgstoragebox-home--backup 253:4 0 295G 0 lvm /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243
The recommendation in the article says to make a file system reduction a bit bigger than an LVM volume one with further extending the file system to all available space of a produced gap. It guarantees that you won't accidentally touch your stored data.
In the current case, the file system size is going to be
292GB and LVM volume size
295GB. For dealing with a file system resizing the system package
e2fsprogs is taken.
$ sudo resize2fs /dev/vgstoragebox/home-backup 292G [sudo] password for vol: resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/vgstoragebox/home-backup is mounted on /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243; on-line resizing required resize2fs: On-line shrinking not supported
From here and further for many operations the file system and volumes have to stay unmounted. My preference here is
udiskcie system package.
$ udisksctl unmount --block-device /dev/mapper/vgstoragebox-home--backup Unmounted /dev/dm-4.
$ sudo resize2fs /dev/vgstoragebox/home-backup 292G resize2fs 1.46.5 (30-Dec-2021) Please run 'e2fsck -f /dev/vgstoragebox/home-backup' first.
After unmounting the warning says to run
e2fsck -f before shrinking to check the file system state. The flags
-f is for forceful running and
-y for answering "yes" to the subsequent questions.
$ sudo e2fsck -f -y /dev/vgstoragebox/home-backup e2fsck 1.46.5 (30-Dec-2021) Pass 1: Checking inodes, blocks, and sizes Pass 2: Checking directory structure Pass 3: Checking directory connectivity Pass 4: Checking reference counts Pass 5: Checking group summary information /dev/vgstoragebox/home-backup: 511643/19333120 files (0.2% non-contiguous), 43577986/77332480 blocks
$ sudo resize2fs /dev/vgstoragebox/home-backup 292G resize2fs 1.46.5 (30-Dec-2021) Resizing the filesystem on /dev/vgstoragebox/home-backup to 76546048 (4k) blocks. The filesystem on /dev/vgstoragebox/home-backup is now 76546048 (4k) blocks long.
All goes wll. Display the resize change.
$ udisksctl mount --block-device /dev/mapper/vgstoragebox-home--backup Mounted /dev/dm-4 at /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgstoragebox-home--backup 287G 161G 112G 60% /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243
As you see the file system works with a slightly different space of
287GB, that's normal.
$ udisksctl unmount --block-device /dev/mapper/vgstoragebox-home--backup
The next step is to reduce the LVM volume size.
$ sudo lvchange --activate n vgstoragebox/home-backup
$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home-bckup vgstoragebox -wi------- 295.00g
$ sudo lvreduce -L 294G /dev/mapper/vgstoragebox-home--backup Size of logical volume vgstoragebox/home-backup changed from 295.00 GiB (75520 extents) to 294.00 GiB (75264 extents). Logical volume vgstoragebox/home-backup successfully resized.
$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert home-backup vgstoragebox -wi------- 294.00g
The final step here is to occupy all the available space by the file system.
$ sudo lvchange --activate y vgstoragebox/home-backup
$ sudo resize2fs /dev/vgstoragebox/home-backup resize2fs 1.46.5 (30-Dec-2021) Filesystem at /dev/vgstoragebox/home-backup is mounted on /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243; on-line resizing required old_desc_blocks = 37, new_desc_blocks = 37 The filesystem on /dev/vgstoragebox/home-backup is now 77070336 (4k) blocks long.
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgstoragebox-home--backup 289G 161G 114G 59% /media/vol/d4b01a30-f6eb-4b16-9451-1c9fb8366243
It's done. The file system now is
289G thats equals to
294GB on a lower level. The experimental attempt succeeded, time to move on to the laptop disk.
To modify the
root volume the OS has to be off. Boot up on a flash drive with a live OS
Open the encrypted laptop disk.
sudo cryptsetup open /dev/nvme0n1p3 laptop-drive
Check that LVM can see the decrypted volumes and the FS is mounted
$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root vgkubuntu -wi-ao---- 474.75g swap_1 vgkubuntu -wi-a----- 980.00m
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgkubuntu-root 467G 305G 138G 69% /media/kubuntu/bd15f678-7f4d-4638-96e5-e0ea9d967ec7
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT nvme0n1 259:0 0 477G 0 disk └─nvme0n1p3 259:3 0 475.7G 0 part └─laptop-drive 253:0 0 475.7G 0 crypt ├─vgkubuntu-root 253:1 0 474.8G 0 lvm /media/kubuntu/bd15f678-7f4d-4638-96e5-e0ea9d967ec7 └─vgkubuntu-swap_1 253:2 0 980M 0 lvm
List the file system attributes to compute a proper size to shrink to.
$ sudo dumpe2fs -h /dev/vgkubuntu/root dumpe2fs 1.45.5 (07-Jan-2020) Block count: 124452864 Block size: 4096
Unmount the file system and resize to
464Gb. We compute the size based on
Block count, the command
df -h output doesn't fit to working with blocks. The current size we have to subtract space from is
Block count * Block size / 1024 / 1024 / 0124. In this case, it's
474.75GB - 10GB.
$ udisksctl unmount --block-device /dev/vgkubuntu/root Unmounted /dev/dm-1.
sudo e2fsck -f -y /dev/vgkubuntu/root /dev/vgkubuntu/root: 2592737/31113216 files (0.3% non-contiguous), 82062147/124452864 blocks
$ sudo resize2fs /dev/vgkubuntu/root 464G resize2fs 1.45.5 (07-Jan-2020) The filesystem on /dev/vgkubuntu/root is now 121634816 (4k) blocks long
Reduce the lvm volume to
465GB due to the precaution of keeping stored data untouched.
$ sudo lvchange --activate n vgkubuntu/root
$ sudo lvs LV VG Attr LSize Pool Origin Data% Meta% Move Log Cpy%Sync Convert root vgkubuntu -wi------- 474.75g swap_1 vgkubuntu -wi-a----- 980.00m
$ sudo lvreduce -L 465G /dev/vgkubuntu/root Size of logical volume vgkubuntu/root changed from 474.75 GiB (121536 extents) to 465.00 GiB (119040 extents). Logical volume vgkubuntu/root successfully resized.
$ sudo lvchange --activate y vgkubuntu/root
Now extend the shrunk file system occupying all the available space.
$ sudo resize2fs /dev/vgkubuntu/root resize2fs 1.45.5 (07-Jan-2020) Resizing the filesystem on /dev/vgkubuntu/root to 121896960 (4k) blocks. The filesystem on /dev/vgkubuntu/root is now 121896960 (4k) blocks long.
$ udisksctl mount --block-device /dev/vgkubuntu/root Mounted /dev/dm-1 at /media/kubuntu/bd15f678-7f4d-4638-96e5-e0ea9d967ec7.
See the final disk state.
$ df -h Filesystem Size Used Avail Use% Mounted on /dev/mapper/vgkubuntu-root 457G 305G 129G 71% /media/kubuntu/bd15f678-7f4d-4638-96e5-e0ea9d967ec7
$ sudo vgs VG #PV #LV #SN Attr VSize VFree vgkubuntu 1 2 0 wz--n- <475.71g 9.75g
VFree space has increased to
I don't know how big i really need the swap volume to be. For now, i'm adding
3GB and leave some space for a few other purposes. Similiar experience of people who had the same issue i found in the article . The main idea is:
- Turn the swap off.
- Add some space to an LVM SWAP volume.
- Make a new swap.
- Turn it on.
$ swapon --show NAME TYPE SIZE USED PRIO /dev/dm-2 partition 980M 0B -2
$ swapoff -a
$ sudo lvextend --size +3G vgkubuntu/swap_1 Size of logical volume vgkubuntu/swap_1 changed from 980.00 MiB (245 extents) to <3.96 GiB (1013 extents). Logical volume vgkubuntu/swap_1 successfully resized.
$ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS └─nvme0n1p3 259:3 0 475.7G 0 part └─nvme0n1p3_crypt 253:0 0 475.7G 0 crypt ├─vgkubuntu-root 253:1 0 465G 0 lvm / └─vgkubuntu-swap_1 253:2 0 4G 0 lvm
$ sudo mkswap /dev/dm-2 mkswap: /dev/dm-2: warning: wiping old swap signature. Setting up swapspace version 1, size = 4 GiB (4248825856 bytes) no label, UUID=ff6f4623-fdb9-4337-9986-e515c8d0b111
$ sudo swapon -a
$ swapon --show NAME TYPE SIZE USED PRIO /dev/dm-2 partition 4G 0B -2
Fine, the swap grew up to
4GB. Time to exploitate it and figure out whether the OS issues are gone.
To check that a bigger swap makes OS stable i'm playing Dota 2 and experiencing no spikes or other issues anymore. Even when i run many applications it's working much smoother now. And i'm seeing that not all RAM is acquired and the swap stays unfilled completely in comparison to when the size was
In conclusion, i'd like to understand why the standard Ubuntu installation suggests such a small swap size? For thin and lightweight laptops, the problem of lacking RAM isn't gone.