I think I can reproduce the problem now. See below.
On Tue, Sep 22, 2020 at 02:09:01PM -0400, Mark Johnston wrote: ! On Tue, Sep 22, 2020 at 07:31:07PM +0200, Peter wrote: ! > There is something, and I don't know who owns that: ! > $ vmstat -m | grep shmfd ! > shmfd 13 14K - 473 64,256,1024,8192 ! > ! > But that doesn't look big either. ! ! That is just the amount of kernel memory used to track a set of objects, ! not the actual object sizes. Unfortunately, in 11 I don't think there's ! any way to enumerate them other than running kgdb and examining the ! shm_dictionary hash table. One of the owners of this is also postgres (maybe among others). ! I think I see a possible problem in i915, though I'm not sure if you'd ! trigger it just by using vt(4). It should be fixed in later FreeBSD ! versions, but is still a problem in 11. Here's a (untested) patch: Thank You, I'll keep that one in store, just in case. But now I found something simpler, while tracking error messages that came into my glance alongside: When patching to 11.4-p3, I had been reluctant to recompile lib32 and install that everywhere, and had kicked it off the systems. And obviousely, I had missed to recompile some of my old self-written binaries and they were still i386 and were called by various scripts. So what happens then is this: $ file scc.e scc.e: ELF 32-bit LSB executable, Intel 80386, version 1 (FreeBSD), dynamically linked, interpreter /libexec/ld-elf.so.1, for FreeBSD 9.3 (903504), stripped $ ./scc.e ELF interpreter /libexec/ld-elf.so.1 not found, error 8 Abort trap And this will cost about some (hundred?) kB of swapspace every time it happens. And they do not go away again, neither can the concerned jail do fully die again. So, maybe, when removing the lib32 & friends from the system, one must also remove the "options COMPAT_FREEBSD32" from the kernel, so that it might not try to run that binary, and maybe that would avoid the issue. (But then, what if one uses lib32 only in *some* jails? Some evil user in another jail can then bring along an i386 binary and crash the system by bloating the mem.) Anyway, my problem is now solved; as I needed these binaries back in working order anyway. regards, PMc _______________________________________________ email@example.com mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-stable To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"