Re: get_swap_pager(x) failed

On 2017-Dec-12, at 6:34 PM, blubee blubeeme <gurenchan at gmail.com> wrote:

> On Wed, Dec 13, 2017 at 5:53 AM, Mark Millard <markmi at dsl-only.net> wrote:
>> blubee blubeeme gurenchan at gmail.com wrote on
>> Tue Dec 12 15:58:19 UTC 2017 :
>> 
>> > On Tue, Dec 12, 2017 at 3:34 PM, blubee blubeeme <gurenchan at gmail.com
>> > >wrote:
>> > > I am seeing tons of these messages while running tail -f /var/log/messages
>> > > ============
>> > > Dec 12 15:11:41 blubee kernel: swap_pager_getswapspace(25): failed
>> > . . .
>> > >  1159 blubee        5  20    0   149M 56876K select  6   1:05   0.00%
>> > > ibus-engine-chewing
>> > >
>> > > ===========
>> > >
>> > > What's with all the swap errors? I am running ZFS and I have 16GB of ram,
>> > > how could I be having swap space errors?
>> > >
>> >
>> > Well I added 4GB of extra swap in /var/tmp/swap0
>> > then added that to my /etc/fstab: md99                    none    swap
>> > sw,file=/var/tmp/swap0,late     0       0
>> >
>> > and those errors went away.
>> 
>> I recommend reviewing bugzilla 206048 (title in part
>> "swapfile usage hangs; swap partition works"):
>> 
>> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206048
>> 
>> before using file-system based swap spaces. They have
>> lots of problems with deadlocks. See especially comments
>> #7 and #8 quoting Konstantin Belousov. #8 is just a
>> reference to:
>> 
>> https://www.freebsd.org/doc/en_US.ISO8859-1/books/developers-handbook/kerneldebug-deadlocks.html
>> 
>> Comment #3 shows a way to test for the problematical
>> behavior.
>> 
>> Using swap partitions avoids the issue.
> 
> 
> Thanks for the info, why would I be getting swap errors like that when I have 32GB of ram?
> sysctl hw.physmem
> hw.physmem: 34253692928
> 
> That really doesn't make any sense to me... Is it Chromium eating up 32GB+ of ram?

I'm not familiar with the memory use of the software
that you use. But if swap space is put to use then
file-based swap space is a bad idea from what I
understand. Having no swap space configured is
allowed but may not be sufficient for your context.

In a separate shell window you could monitor what is
going on with something like:

top -Cawores

(You may want a large window.)

That will show something like following in an
updating display:

last pid: 49403;  load averages:  0.13,  0.03,  0.01                        up 3+19:28:56  19:33:58
43 processes:  1 running, 42 sleeping
CPU:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
Mem: 1808K Active, 98G Inact, 45M Laundry, 4912M Wired, 1544M Buf, 2462M Free
Swap: 15G Total, 15G Free

  PID USERNAME       THR PRI NICE   SIZE    RES   SWAP STATE   C   TIME     CPU COMMAND
  625 root             1  20    0 55588K 15440K     0K select 15   0:01   0.00% /usr/sbin/mountd -r
  627 root             1  52    0 54024K 14348K     0K select 27   0:00   0.00% nfsd: master (nfsd)
. . .

(Some of the detail above is tied to it being a UFS context
instead of a zfs context. There will be zfs information as well
if you are using zfs.)

The SIZE, RES, and SWAP for various processes will give a clue.
Avoid over interpreting: as I understand, these days swapped-out
really means the kernel-stacks for the process are not resident.
The activity is mostly paging activity otherwise. Top does not
track such detailed changes in how it presents information. RES
being zero might not mean what one might expect. Still, the
figures are useful for seeing what is using RAM and the
swapspace.

I'm not aware of a way to find the maximum swapspace in-use-so-far
figure or any estimate of it. Top will display an active in-use
figure if it is in use (not just Total and Free). Of source the
figure is based on periodic sampling. Top does not display the
maximum-observed-so-far of its periodic sampling.

===
Mark Millard
markmi at dsl-only.net