Hello,
I have a brand new DELL Vostro 3578 with i5 , 8 GB RAM, SSD disk 256GB. I installed Tumbleweed first and downgraded to LEAP. In both environmet I experience freezes when system runs out of memory and starts to swap. Load is around 28 and I can not switch to terminal or anything else. Usually it happens when I start Virtual Box.
I run memory test in BIOS and all is good.
Swap is on and it 8GB.
My fstab:
UUID=e9fad824-686d-425a-b86d-457351bee1ac / btrfs defaults 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /boot/grub2/x86_64-efi btrfs subvol=/@/boot/grub2/x86_64-efi 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /boot/grub2/i386-pc btrfs subvol=/@/boot/grub2/i386-pc 0 0
UUID=1C3B-A9B6 /boot/efi vfat defaults 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /.snapshots btrfs subvol=/@/.snapshots 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /var btrfs subvol=/@/var 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /usr/local btrfs subvol=/@/usr/local 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /tmp btrfs subvol=/@/tmp 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /srv btrfs subvol=/@/srv 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /root btrfs subvol=/@/root 0 0
UUID=e9fad824-686d-425a-b86d-457351bee1ac /opt btrfs subvol=/@/opt 0 0
UUID=8effb7f0-f2b0-454e-a12d-938769251be9 /home xfs defaults 0 0
UUID=1f89aa44-0b48-4262-9130-1c47f8034c99 swap swap defaults 0 0
And uname -a:
Linux linux-wbx3 4.18.15-1-default #1 SMP PREEMPT Thu Oct 18 08:56:17 UTC 2018 (5a53676) x86_64 x86_64 x86_64 GNU/Linux
I took a screenshot during the freeze with my phone. Put on onedrive and try to paste a link here. It does not work or it seems.
Thank you for any tips !!!
Radovan https://1drv.ms/u/s!Ag-9zeCDUfYygoU5OrSTd7PBGweAEA
Hi,
Thank you for all suggestions.
My virtual machine has 4 GB RAM assigned to the guest OS.
As per openSUSE recommendation I change swappiness to 1.
I was also hit by dreaded bug “i2c_hid_get_input: incomplete report” and added acpi_oss= to GRUB.
It seems to improve tthings. I have not had a freeze so far but was not using the laptop really.
Keeping fingers crossed.
Radovan
I’ve have experienced lock ups due to swap as well.
Same as here, only 8GB RAM available, 2GB swap default.
Difference: I’m only running basic programs, Firefox (with a bunch of tabs), LibreOffice and Mendeley. I’ve been playing around with swappiness as well, from 10 to 30, but whatever I do, at some point the system locks up and swaps. The only work around I have found so far, is t reboot the system frequently.
I wonder why RAM management is so bad? Because in Windows this won’t happen. Even if it swaps, it recovers within maybe 15 minutes, but in OpenSuse I let the system swap for 2 hours and it remained completely locked up. If I reset all unsaved documents are gone
Hello,
I still have the issue. Testing now with swapoff. (swapoff -a). Getting the freeze even without Virtualbox running.
Nothing suspicious is in /var/log/messages. Only occasionally following messages:
2018-11-13T11:43:43.430999+01:00 linux-wbx3 krunner[1983]: QSqlDatabasePrivate::removeDatabase: connection ‘/home/rb…default/places.sqlite’ is still in use, all queries will cease to work.
2018-11-13T11:43:43.431870+01:00 linux-wbx3 krunner[1983]: QSqlDatabasePrivate::addDatabase: duplicate connection name ‘/home/rb…default/places.sqlite’, old connection removed.
2018-11-13T11:43:43.438043+01:00 linux-wbx3 krunner[1983]: QSqlDatabasePrivate::removeDatabase: connection ‘/home/rb…default/favicons.sqlite’ is still in use, all queries will cease to work.
2018-11-13T11:43:43.438312+01:00 linux-wbx3 krunner[1983]: QSqlDatabasePrivate::addDatabase: duplicate connection name ‘/home/rbi…default/favicons.sqlite’, old connection removed.
2018-11-13T11:43:43.441883+01:00 linux-wbx3 krunner[1983]: no appstream for you
2018-11-13T11:43:44.240013+01:00 linux-wbx3 krunner[1983]: message repeated 3 times: no appstream for you]
Years ago, the rule of thumb was you made swap larger than ram. The old intel memory routines pre-allocated ram in the swap space. That is how it was in System V like AT&T Unixware and NCR MPRAS and most other AT&T based Unix. At one time stage 3 loader built the memory blocks and swapon/swapoff had no effect. I am too lazy to see if that is still the case with OpenSUSE Leap. I was AT&T/NCR Unix for 20 years and came up with many quick and dirty fixes to get customers past Unix bugs and “Panics”. Panics were unfinished kernel sections that were not ever supposed to be called and no recovery logic had been agreed upon on how to recover from it yet. I think there are still a few Panic points in the Unix Kernel and probably in the Linux Kernel as well. I fixed bugs as best I could - mostly at 2 in the morning with customers breathing down my neck. I am glad that I am retired. Support has gone downhill.
I wonder if your lockups are because there are no more swap blocks available in your systems - swap does not have to in use at all to have the blocks allocated - they are pre-allocated so that if swapping is needed - it knows what disk address to swap your memory into and out of.
Great Quote
“A feature is just a bug with seniority”
Thank you. I tried to add another swap file and it did help.
I have fixed the lines in the grub config that had seemed weird. It contined double statements.
old: GRUB_CMDLINE_LINUX_DEFAULT=‘splash=silent resume=/dev/disk/by-id/ata-TOSHIBA_KSG60ZMV256G_M.2_2280_256GB_68JB81EAK5SP-part9 quiet splash=silent resume=/dev/disk/by-id/ata-TOSHIBA_KSG60ZMV256G_M.2_2280_256GB_68JB81EAK5SP-part9 quiet’
new: GRUB_CMDLINE_LINUX_DEFAULT=‘splash=silent resume=/dev/disk/by-id/ata-TOSHIBA_KSG60ZMV256G_M.2_2280_256GB_68JB81EAK5SP-part9 quiet’
Have not verified yet by running out of RAM.
I can reproduce the freeze everytime. Once system is out of RAM and start swapping it is dead. Atop shows that the disk is 100%.
Trying to add my two cents. This system has 16GB physical RAM, 16GB swap on SSD, never had a glitch before.
I had to start 6 VMs in VBox to run out of physical RAM, once started swapping the desktop froze for 30 seconds or so, then one of the VMs aborted without my intervention, RAM usage dipped below 100% and the system was apparently normal again.
Restarting that VM (it was the 5th in the start order BTW) brought RAM usage to 100% again, system swapping some 250MB ant then freezing again with the disk LED constantly on.
This time after waiting some 15 minutes my only option was to pull the power switch.
So I can confirm that at least there is an issue with VBox running out of physical RAM; I cannot say if there is a problem with swapping itself, since I cannot figure out a way to run out of RAM without VBox on this system.
Standing by for further test if I see fit.
Where’s that recommendation? Things like swappiness belong to system defaults, I’m not aware of any openSUSE wiki page that encourages changing the defaults.
I will not debate your wisdom on the subject, but isn’t this page outdated ( i.e. writen at the time of 11.4 )?
At the time I had an extensive discussion on G+ with GregKH and some dutch computertip guy, where Greg was very clear: don’t mess with these things, you break what the makers of the distro have built, and your distro should ( an can ) do it right. At oSC15 I’ve asked (a.o.) Dimstar who’s reply was “O, yeah, do that, then post on the list that VirtualBox is slow”.
My main point is that ( like Greg said ) the distro should do this right. A user should have no need ( unless is very specific use cases ) to tinker with system defaults. I have never seen any posts here stating ‘changing swappiness saved my system’. A second point is that various tests have shown that wearing of modern SSDs exists only after years of writing ( in total ) petabytes to SSDs.
FWIW: The computertip guy this year finally has removed his openSUSE instructions ( which he admitted not even trying himself and were mainly sheer nonsense ).
FWIW2: I thought my first SSD ( a full blown 30GB ) had broken, but this year I found that the SSD itself wasn’t broken, the SATA controller was. Got a case ( incl controller ) from a friend to try, built it in and it’s still working in this friends old laptop.
Hi
I change it for any system to ensure all physical ram is used before swapping, or if lots of ram, look at using zram. It’s all part of fine tuning a system to the end user requirements. I don’t hibernate or suspend so have little use for swap and keep winding it back.
Well, I cannot argue with Malcolm or Knurpht on system issues, but plain observation tells that with the SDB suggested tuning VBox freezes the desktop as soon as 100% RAM is in use, while I’m currently writing this with 6 VMs in full operation and some use of swapping using the system defaults (or at least what are claimed as such in the SLE System Analysis and Tuning Guide):
vm.swappiness=60
vm.vfs_cache_pressure=100
So apparently what seems to be a good general tip when (not) using swap on an SSD is definitely wrong if you are going to use VBox beyond the limits of your installed physical RAM.
Standing by for further testing if needed.
I set swappiness to 1 also, once I get round to the fine tuning
But it might be a week or two before I get to it after installation
Either way, That is before or after I change that my system is rock solid
Thank you for all support.
I set swappiness to 10 and vfs_cache_presure to 100.
Most importantly I ordered 8 GB RAM stick.
It its deeply annoying to have sudden freezes. I believe VBox is innocent. I get freeze anytime any process gets over physical RAM. Sometimes it recovers when the process is not memory hungry.
Radovan
I did some more tests to the benefit of those finding this thread.
Having more RAM is definitely the best option, anytime the system begins swapping get MUCH slower (say 1000 times slower).
I too think that VBox is innocent, you can have similar effects with GIMP opening (very) large images.
Setting swappiness to 1 (or to any low value I tried) seems good if you are never going to need swap under normal operation.
If you occasionally need even small amounts of swap (say a few hundred MB) I saw little if any gain from lowering the default value of 60 for swappiness.
At 60 the system swaps a larger chunk of memory on the first instance, but then remains quieter, so you have a sudden unresponsiveness of a few seconds followed by almost normal behaviour of the desktop.
At lower values (say 10 or so) the system begins to swap a bit later and with a smaller chunk, but then continues swapping small chunks and you have an unresponsive desktop for a much longer time.
Anyway, the system doesn’t “freeze” and resumes polling desktop applications after some time (as long as 1h of apparent “freeze” in my tests).