Skip site navigation (1)Skip section navigation (2)
Date:      Fri, 11 Feb 2022 01:14:01 +0000
From:      tech-lists <tech-lists@zyxst.net>
To:        questions@freebsd.org
Subject:   Re: swap/page problem
Message-ID:  <YgW4WXY93XFlIp23@cloud9.zyxst.net>
In-Reply-To: <CAN6yY1s%2BC3ap7rvajujiTqGwQVgkZrHRh6eHnTGHgTsVrfjPcg@mail.gmail.com>
References:  <CAN6yY1s%2BC3ap7rvajujiTqGwQVgkZrHRh6eHnTGHgTsVrfjPcg@mail.gmail.com>

next in thread | previous in thread | raw e-mail | index | archive | help

--fqIMx3Kuc2tfVDWt
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

Hi,

On Thu, Feb 10, 2022 at 02:28:50PM -0800, Kevin Oberman wrote:
>During a large build (llvm13), my system ground to a near halt with almost
>everything suspended. After several minutes, the system slowly recovered.
>When I looked at the messages log, I found 57 kernel messages spread over
>3.75 hours, in the form of:
>wap_pager: indefinite wait buffer: bufobj: 0, blkno: 862845, size: 20480
>
>The block numbers and sizes varied. bufobj was always '0'. I had
>significant swap available swap space,as far as I could tell. I have 20GB
>of RAM and 24GB of swap. I am running stable 48937-3c6b6246f2f from January
>13.
>
>I know that the LLVM build is huge, but I've not seen this before. What,
>exactly, is this message telling me? Am I out of RAM and swap? I couldd add
>another 24GB of swap, though it would be on spinning rust, not SSD.

I've seen this problem before and came to the conclusion=20
after reading threads on the lists and asking questions that=20
it wasn't a swap problem as primary issue but maybe theres some contention=
=20
between processes which affects llvm in particular and makes it eat swap.
Also, as you noted, swap doesn't really run out.

I use poudriere to build and have parallel jobs set to 1 now=20
with make jobs enabled and the problem doesn't happen. If you're just
using the ports tree in the traditional way, try make -j1.
If parallel jobs is unset it would use hw.ncpu which here is 8 which would
produce the problem you descrive when compiling llvm13.

These sysctls are now set:

vfs.read_max=3D128                       # default 64 - speeds up disk i/o
vfs.aio.max_buf_aio=3D8192
vfs.aio.max_aio_queue_per_proc=3D65536
vfs.aio.max_aio_per_proc=3D8192
vfs.aio.max_aio_queue=3D65536
vm.pageout_oom_seq=3D120
vm.pfault_oom_attempts=3D-1

those last two may be especially helpful for your situation.

My context here is amd64 i7-4770K (so 8 cpus with HT) clocked to 4.3GHz
and the disk used for building poers is SSD wiht 16GB swap (partition).
RAM is 32GB

--=20
J.

--fqIMx3Kuc2tfVDWt
Content-Type: application/pgp-signature; name="signature.asc"

-----BEGIN PGP SIGNATURE-----

iQIzBAABCAAdFiEE8n3tWhxW11Ccvv9/s8o7QhFzNAUFAmIFuFAACgkQs8o7QhFz
NAUr1xAAig+npXZB5qXHzpPX8nnO0q5tDTuuXYAP/rM2SwHT2Nkw3p3N5CGpAYw/
3AscbD3Iq40WZOPIPtI3UgGU8h2hrvr3nt2dBgK4Q3ueIABwoZ3AF0gQ4D9HS1Tj
ZUaAd576CBPpAWCo5io7QFAd3dPNjPRxCIEb99z6XCY1KYMKx6QnTvFOY1MKuWOe
nazPi2peUUEzYqGFZRkCXCs43+rb2AjcqDQhZlPi3Ff5YLtO2mMGvEx+Yj256p6r
XxQ9c+w256MWIsEtjn4FiyeOPWo0lrNm2bVsrrdT0WFRB8vHKZgu0SkKvpR89DmM
kv4Q5zsqIh2Vjc+XYipdMnZaCrs60yR2AahR2iADqgVhgNSU+dIxn3kIHXxinpXW
jBV81RoCzJwHLroT4VevuzOB0JDjEvUr66H9P78YFZsJRVVKfr/hW5NByONzr/kJ
gfmM2/pT1udzwusbmL5obdPwyQtZjsRtGllAZ4eK77oNRZAZkAxgmioKWSqo26Gi
nrFPoYuKPvtr5aWbKqD04bUjdMi0R9gIBbS3rJhnomP7wXy+9EAAnLdXR9Vs1ocu
PiwVFQebSobrLY7GEyA1fCp5BWIl/YTLGg+UxaS9ZqKXR6DwZHwvaAiM7R4MU+UE
oAFmqfbwobW8P2ZP+9OfVGs5o6IQweQ8VYq5nPTdvDuk1KJ3JeQ=
=TjLf
-----END PGP SIGNATURE-----

--fqIMx3Kuc2tfVDWt--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?YgW4WXY93XFlIp23>