Most of the time when my computer starts to need swap, I see a massive spike in CPU usage (kswapd0
is consistently using 99%-100% CPU). According to top
, the time is spent in sy
(system/kernel) not wa
(IO wait).
I am running Linux 4.0.4-2-ARCH on a C720 with 2GB RAM, and 6GB swap on an SSD.
I seem to have this problem with or without discard pages (TRIM) turned on.
Are there any setting I should inspect or tweak to see if I can fix this?
Is there any way to debug the problem? Something like strace
for kernel threads?
Running with default Arch Linux settings:
/proc/sys/vm/swappiness
= 60
/proc/sys/vm/vfs_cache_pressure
= 100
/sys/kernel/mm/transparent_hugepage/enabled
= [always] madvise never
It seems a relatively common problem
When the problem is happening, can you check if issuing the following command stops it:
echo 1 > /proc/sys/vm/drop_caches
If it works, you can schedule it as a periodic cron job as a workaround.
I have a C720 running Linux Kernel 4.4.0 on Ubuntu 14.04.1 LTS with 2 GB RAM and 2 GB swap.
Assuming heavy Chrome/Chromium usage, here are some ways to make your system more performant:
/etc/default/grub
and add the following kernel parameters to theGRUB_CMDLINE_LINUX_DEFAULT
line:elevator=noop
zswap.enabled=1
transparent_hugepage=madvise
sudo update-grub2
./etc/sysctl.conf
and append the following:vm.swappiness=25
# ~ max(RES intop
)*2 / RAM = 500 MB / 2 GBvm.vfs_cache_pressure=1000
# safer than periodically dropping cachesYou can verify the changes like so:
Update
Increasing
vm.min_free_kbytes
in step #3 may be beneficial. Try a value of131072
(128 MB). The final takeaway is that Linux on the desktop doesn't perform very well in low-memory situations. Some have suggested placing Chrome/Chromium in acgroup
, but that's beyond the scope of this answer.I am not sure why this answer has not been suggested:
killall -9 kswapd0
I came across this problem where the
kswapd0
process was running as a non-root user who had not logged in for a long while. I have killed this process and the issue hasn't returned.No, this does not address the root issue (how did it even get 100% in the first place) but allows you to quickly recover usage of the system.
kswap kernel are used to allocate and release memory pages, if your swap are used in you see this kernel threads using so much cpu time, that would say the kswap kernel threads are scanning the memory pages for swaping some pages and serve the memory allocation request.
I think drop the cache in this case doesn't help, because the kernel reclaim the cache when the OS is tight memory situation automatically.
If you don't have any memory problem and use the
free
command, you will see so much memory used as cache, but if you have a memory problem, Linux reduce the cache for serve the memory allocation requests, without any need to drop cacheyou can use
sar -B
and looking formajft
andpgscank
values, for other valuesman sar
(This is quasi-answer -- too long to be a comment, but not a ready answer though)
1) What about using not 6G but less, say 1 or 2 GiBs (you can set-up the size with
mkswap
w/o resizing swap partition) — tried? What results?2) What's
sysctl vm.swappiness
,sysctl vm.vfs_cache_pressure
?3) What's
cat /sys/kernel/mm/transparent_hugepage/enabled
?N. B. Do you realize you're gonna wear out your SSD significantly in that kind of set-up (not that much RAM, huge swap).
P. S. I could recommend trying to use UltraKSM but it requires patching a kernel. I do have some builds of mine own (-realtime and BFS based), but they're for
.deb
-based systems and meanwhile they can be used on different systems quite easily (usually you would need just to unpack the.deb
s and make corresponding initrd/initramfs, it can be a hassle for people not that familar with that side of Linux)(to be continued)
If you have a service running inside of docker like puppeteer (chrome headless api) Inside your dockerfile add the dumb-init.
If running Docker >= 1.13.0 use docker run's --init arg to reap zombie processes
docker run container --init
If you are running a <=1.13.0 in docker use dumb-init. Add this to your Dockerfile.
None of the answers listed here were working for me. I tried a simpler 'IT Crowd' approach of turning off the swap and then turning it back on.
# swapoff -a
then# swapon -a
.I wouldn't recommend this if the server was desperately short of RAM, but in my case there was plenty of RAM but for whatever reason swap was running amok. Swap cleared, CPU usage back to normal.
For own experience kswapd# indicates memory is fully used and swap was activated automatically to accomplish its function of memory need backing . Kill the process is not a good decision because it becomes temporal not for future. I recomend to increase memory to machine to keep performance in processes. In my case is was due to have several virtual machines on same server. Two of the VM consume a lot of resources on its processes. Regards