[kernel-bugs] [Bug 1159882] Excessive swapping when buffers / cache expand beyond free physical RAM
![](https://seccdn.libravatar.org/avatar/a895f78a81a109471893519443e4d933.jpg?s=120&d=mm&r=g)
https://bugzilla.suse.com/show_bug.cgi?id=1159882 https://bugzilla.suse.com/show_bug.cgi?id=1159882#c33 --- Comment #33 from Michal Hocko <mhocko@suse.com> --- (In reply to Robert Delahunt from comment #27)
I had reinstalled OpenSUSE LEAP 15.2 using the DVD but with network enabled, so what I should've gotten was a fresh installation of the most current stable OpenSUSE LEAP 15.2.
VMSTAT information as requested:
http://www.puresimplicity.net/~delahunt/vmstat/swapon/
http://www.puresimplicity.net/~delahunt/vmstat/swapoff/
Basically, I had reinstalled OpenSUSE LEAP 15.2 with the LUKS-contained LVM of /dev/system/home and /dev/system/swap but I had deleted the LV of swap and ran the system without swap. So the swapoff is a recording of vmstat while I was doing
dd if=/dev/zero of=/dev/sdb bs=4K status=progress
and the swapon directory is after I went back into the partitioner, recreated the swap LV, turned swap on, then ran the dd command above all over again.
I have looked at swapon data. First vmstat Last vmstat[diff] pgscan_direct 2383 0 pgscan_kswapd 14565113 424280 pgsteal_kswapd 14513308 423192 No direct reclaim, so kswapd was able to cope with the allocation pace. The overall reclaim efficiency is nice as well (99%) and the reclaim itself has freed 1.6G worth of memory pgalloc_dma32 2334299 467232 pgalloc_normal 24091786 3564456 while 15.7G of memory was requested during that time period. pswpin 0 0 pswpout 0 11842 No memory has been swapped in while 46M has been swapped out. This on its own doesn't sound overly excessive. I would be much more worried if pswpin was high because that would suggest that memory actively in use has been swapped out and so the owner would see larger latencies on refault. workingset_activate 86 41 workingset_refault 10237 141 workingset_restore 0 0 These are stats for disk based page cache refaults. workingset_refault will tell us how many page cache pages have been reclaimed and then faulted back in again. 141 pages is really minuscule. workingset_activate tells us how many pages were reclaimed recently so we should consider them active. workingset_restore will tell us that the refault is happening on a previously active page. All in all not much of a refault activity. If there is enough clean page cache then we shouldn't swap at all. There are three jumps in swapout vmstat.1600702573:pswpout 0 vmstat.1600702574:pswpout 2448 [...] vmstat.1600702577:pswpout 5555 vmstat.1600702578:pswpout 10605 vmstat.1600702579:pswpout 11330 The biggest one swapped out 5050 withing one second. vmstat.1600702577 1600702578 [diff] nr_active_anon 373934 -3376 nr_active_file 131158 0 nr_inactive_anon 48441 8556 nr_inactive_file 3288371 1169 nr_dirty 632308 28 There is plenty of inactive pagecache. A large part is dirty but there should be still a lot of clean page cache to reclaim. The file inactive list is clearly not low on the global level. workingset_refault 10281 0 no refaults detected so the heuristic from 2c012a4ad1a2 shouldn't trigger. These are all global numbers. Picture would be quite different if memory cgroups were deployed though. I have asked earlier for the behavior with cgroup_disable=memory on the kernel command line parameter. See comment 12 for more information. -- You are receiving this mail because: You are the assignee for the bug.
participants (1)
-
bugzilla_noreply@suse.com