On April 23, 2025 6:27:20 AM GMT+03:00, Mark Millard <mark...@yahoo.com> wrote:
>Sulev-Madis Silber <freebsd-current-freebsd-org111_at_ketas.si.pri.ee> wrote on
>Date: Wed, 23 Apr 2025 02:04:28 UTC :
>
>> yes, 2 * 8g partitions on separate disks, so i have 16g swap
>>
>> . . .
>>
>> >> >Van: Sulev-Madis Silber <freebsd-current-freebsd-org...@ketas.si.pri.ee>
>> >> >Datum: maandag, 21 april 2025 03:25
>> >> >. . .
>> >> >>
>> >> >> others don't get it at all and only suggest adding more than 4g ram
>>
>> . . .
>
>I have no clue if this will be of any help.
>
>For 64-bit systems, having total SWAP much greater than,
>say, 3.6*RAM normally produces a warning about potentially
>being in a mistuned state. They look like, for example:
>
>warning: total configured swap (477183 pages) exceeds maximum recommended
>amount (466816 pages).
>warning: increase kern.maxswzone or reduce amount of swap.
>
>If I understand right, adjusting kern.maxswzone makes other
>tradeoffs that I do not know the details of. Thus I avoid
>getting the messages by adjusting the SWAP space size
>instead. I've been told that the messages suggest a higher
>likelihood of deadlocks happening while managing the memory
>space.(Others may known what they are doing with
>kern.maxswzone adjustments and could judge the tradeoffs.)
>
>Are you getting such messages on your console or
>that you can see from "dmesg -a" or in
>/var/log/messages ?
>
>(The detailed multiplier changes some from system
>update to system update. I can not report a fixed
>multiplier. I leave margin to make it unlikely that
>I'd get the notice across various updates.)
>
>3.6 * 4 GiBytes == 14.4 GiBytes SWAP, as an example.
>Then RAM+SWAP == 4.6*RAM, so 18.4 GiBytes or so as a
>memory space.
>
>
>===
>Mark Millard
>marklmi at yahoo.com
>
>
i'm aware of that. but last time i checked it only affects possible swap
fragmentation. i tried to tune it according to some suggestions. then, others
suggested it not being thing to worry about so i took those things off. i
couldn't find good information of this. would this even affect any of my
issues. unless i'm wrong, i cause zfs to use all my ram up. with certain
specific actions. kernel won't freeze or panic. it just gives zfs what it asks.
that's my guess. and this is outside arc. it's often told as if arc tuning is
magic. i think nowadays it's not needed. i read it. i see it
my earlier poor attempts were in
https://forums.freebsd.org/threads/server-freezes-when-using-git-to-update-ports-tree.88651/
it also has outputs and others were confused as well. but some had same issues
so i'm curious if that got fixed. needs extra low ram tuning. or needs some
fix. maybe zfs fix. maybe tunable fix. maybe defaults change, unless it ruins
someone else's system. that i don't like either
as if we need something in kernel to check that whoa, 90% ram is used just to
power zfs. maybe we need to slow down here. i can't tell where memory went. all
i know i had this. and other issues
finally someone suggested limiting git itself somehow. but i don't think this
is all. hell knows what it is. now i encountered some other issues
isn't this kernel's job, ideally, to manage all this. including reserving some
ram maybe. i can't even find tunables for this. i spent ages searching and gave
up multiple times. maybe i'm missing something that (z)fs expert could easily
see. i see that low ram zfs has improved a lot somehow. so something improved
maybe i'll just wait? i clearly have not much clue left. research is hard.
maybe i'll manage to wrap my head around zfs eventually
