Date: Sat, 16 Jun 2018 22:50:49 -0700 From: Mark Millard <marklmi@yahoo.com> To: bob prohaska <fbsd@www.zefox.net> Cc: freebsd-arm@freebsd.org Subject: Re: GPT vs MBR for swap devices Message-ID: <01510328-41E4-4A66-A12D-02DBA418A66B@yahoo.com> In-Reply-To: <D85BF151-9C7A-4E6D-879A-8C5F6D404774@yahoo.com> References: <7AB401DF-7AE4-409B-8263-719FD3D889E5@yahoo.com> <20180617000100.GA46435@www.zefox.net> <D85BF151-9C7A-4E6D-879A-8C5F6D404774@yahoo.com>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jun-16, at 8:38 PM, Mark Millard <marklmi at yahoo.com> wrote:
> On 2018-Jun-16, at 5:01 PM, bob prohaska <fbsd at www.zefox.net> =
wrote:
>=20
>> On Sat, Jun 16, 2018 at 04:03:06PM -0700, Mark Millard wrote:
>>> bob prohaska fbsd at www.zefox.net wrote on
>>> Sat Jun 16 19:12:22 UTC 2018 (some by reference
>>> to other web pages, which is what I quote from
>>> here) :
>>>=20
>>>> Presently, the divided swap layout fails during -j4 buildworld with
>>>> "out of swap" kills during the more frantic portions of buildworld.
>>>>=20
>>>> When all swap is placed on a single 3 GB USB mechanical disk =
partition
>>>> the "out of swap" errors go away. Similarly, when swap is placed =
entirely
>>>> on the microSD card in two partitions, one the original 1 GB =
partition=20
>>>> plus a second 2 GB partition, the "out of swap" errors dissapear.
>>>=20
>>> Since the "multiple swap partitions across multiple
>>> devices" context (my description) is what has problems,
>>> it would be interesting to see swapinfo information
>>> from around the time frame of the failures: how much is
>>> used vs. available on each swap partition? Is only one
>>> being (significantly) used? The small one (1 GiByte)?
>>>=20
>>> A related, additional example to try? . . .
>>>=20
>>> Since you report needing around 1.2 GiByte of swap, what
>>> happens if you have a split but both devices have, say,
>>> 1.5 GiByte of swap space for the partition used? If I read
>>> right, you could shrink the 2GiByte microSD card partition
>>> and the 3 GiByte USB mechanical disk partition and then use
>>> that pair as a test. (This also avoids the message about
>>> having too much swap. Also, I'm avoiding having significant
>>> size differences between the partitions used.) Technically,
>>> without the split, either partition should be sufficient
>>> without the other involved. In such a context, does the
>>> split still fail? Or does it only fail when one partition
>>> is too small to be sufficient by itself?
>>>=20
>> Thus far I think OOM kills have been happening long before either
>> partition fills, but it'll take better logging than I have
>> set up now to be sure.=20
>>=20
>> Is there a simple way to log recurrent swap measurements to
>> a file? Swapinfo doesn't seem to have the right options.
>> It would be particularly convenient if the swap usage info
>> could be appended to the gstat log file. At one point I tried
>> top -n -d all | grep Swap >> gstat.log (I'm using tcsh)
>> but nothing was added to gstat.log and since there was no
>> interest in swap usage totals I gave up.
>>=20
>>=20
>>> These suggestions are going a different direction than the
>>> I/O rate investigation but also having I/O rate information
>>> would not hurt. But I/O rate information can not substitute
>>> for the swapinfo output here. Nor can top cover what I'd be
>>> looking for: per partition usage figures are required, not
>>> just grand total swap-space usage.
>>>=20
>>>=20
>> If you can suggest commands I'll gladly try them. As this little
>> fiasco is playing out, it looks like the lesson for me is don't
>> attempt to interleave swap. Old ideas die slow, but they do die...
>>=20
>> Thanks for reading, and all your help!
>=20
> My notes will be for a context with:
>=20
> # echo $SHELL
> /bin/sh
>=20
> Initially I'll show just:
Well, looks like the notation I used did not go through
to the lists well (missing text in what it is displaying
to me viewed from . . ./2018-June/018046.html. Hopefully
it made it to Bob P. okay.
I'll try to add alternatives that might go through okay.
> # while true =
do =
swapinfo ; sleep 5 =
done
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> ^C
Written as if it was on one line the above was:
while true do swapinfo ; sleep 5 done
> You could, of course, specify a different sleep time
> (in seconds).
>=20
> As for logging to a file, that is just some additional
> command line text:
>=20
> # while true =
do =
swapinfo ; sleep 5 =
done > =
mmjnk.txt
> ^C
> FBSDUSSD# more mmjnk.txt
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
This just added a greater-than sign and a file name after
"done".
> Multiple processes writing to the same file in an uncoordinated
> manner need not produce nice lines with the text from just one
> program on each line.
>=20
> For now I do not intend to try to handle such issues and only
> give the above "just swapinfo" information logging in a specific
> file.
>=20
> But it is possible to get timestamps in the log file:
>=20
> # while true =
do date =
; swapinfo ; sleep 5 =
done > mmjnk.txt
> ^C
> FBSDUSSD# more mmjnk.txt =
Sat Jun =
16 20:35:11 PDT 2018
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Sat Jun 16 20:35:16 PDT 2018
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
> Sat Jun 16 20:35:21 PDT 2018
> Device 1K-blocks Used Avail Capacity
> /dev/gpt/FBSDUSSDswap 15728640 0 15728640 0%
>=20
> Of course the time here is "computer local" if it has not
> been set to track some standard.
Written as if it was on one line but without the
greater than sign and file name after "done":
while true do date ; swapinfo ; sleep 5 done
=3D=3D=3D
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?01510328-41E4-4A66-A12D-02DBA418A66B>