On Apr 22, 2025, at 20:27, 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.
Going in a different direction . . . Are you going to publish step-by-step instructions that repeat the problem(s) that you get in your context --with notes at/about the failure points? Also, you wrote . . . QUOTE i mean it would be easy to add huge amounts of ram but people could also want to use zfs in slightly less powerful embedded systems where lack of power is expected but weird fails maybe not END QUOTE The Design and Implementation of the FreeBSD Operating System (2nd edition) book says: QUOTE (Page 49, last paragraph) ZFS was designed to easily manage and operate enormous file systems, which it does well. Its design assumed that it would have many fast 64-bit CPUs with large amounts of memory to support these enormous file systems. When these resources are available, it works extremely well. However, it is neither designed for nor is it well suited to run on resource-constrained systems using 32-bit CPUs with less than 8 Gbytes of memory and one small, nearly full disk typical of many embedded systems. Thus, the fast filesystem continues to be the file system of choice for these smaller systems. END QUOTE NOTE: In my interpretation, the "32-bit CPUs" vs. "less than 8 Gbytes of memory" context referenced is that there is a problem if either issue is involved: CPUs can not substitute for needing sufficient RAM and RAM can not substitute for needing appropriate CPUs. QUOTING MORE (Page 548, 2nd bullet) Like all non-overwriting file sydstems, ZFS operates best when at least a quarter of its disk pool is free. Write throughput becomes poor when the pool gets too full. By contrast, UFS can run well to 95 percent full and acceptably to 99 percent full. END QUOTE I'll not quote about the mmap details that is one of the things that "works less well than UFS". (4th bullet.) I've no clue if you have a ZFS-based problem, but if you do it would not be surprising. === Mark Millard marklmi at yahoo.com
