Re: Memory upgrade

On Tue, Oct 15, 2024 at 04:42:56AM -0600, Abel Abraham Camarillo Ojeda wrote:

> On Tue, Oct 15, 2024, 04:34 Christian Schulte <cs@schulte.it> wrote:
>
> > On 10/15/24 12:09, Stuart Henderson wrote:
> > > On 2024-10-15, Zé Loff <zeloff@zeloff.org> wrote:
> > >> On Tue, Oct 15, 2024 at 10:14:42AM +0200, Christian Schulte wrote:
> > >>> ulimit -d `ulimit -aH | grep data | awk '{print $2}'`
> > >>> ulimit -n `ulimit -aH | grep nofiles | awk '{print $2}'`
> > >
> > > ulimit -d `ulimit -dH` etc... but then there's no point setting a
> > > separate hard limit in login.conf.
> > Of course. I am the only user on that system and the only limits I want
> > "my" xsession to be in effect on that system are the hard limits setup
> > by the kernel. Those make the system swap for no apparent reasons. So.
> > Why is this thing swapping?
> >
> > >
> > >>> data(kbytes) 134217728
> > >>
> > >> That's 128 GB.
> > > ...
> > >> I have no idea what stating "you can use 128GB of memory on this 8GB RAM
> > >> + 4GB swap machine" does to the system's memory management, but I
> > >> wouldn't be surprised if weird things happen.
> >
> > Same for me. This is the default hard limit on that system without me
> > having touched anything.
> >
> > >
> > > IIRC some things do use ulimit -d as a hint to how much memory they can
> > > allocate.
> > >
> > >>> Still. this does not explain why the system is swapping, although half
> > >>> of the physical RAM is not even wired.
> > >
> > > just read /sys/uvm ;)
> >
> > I am reading that already. That thing should not swap. It does. Some
> > application may well not have been that nice to the memory allocator.
> > The Java VM seems to have this gotten right. Fingers crossed.
> >
> > >
> > > (btw if you're not on -current, you may want uvm_pdaemon.c r1.116 if you
> > are
> > > low on memory).
> > >
> >
> > Will take a look at it. Thank you.
> >
> > --
> > Christian
> >
>
> I recall from 4.4BSD design and implementation (I think) that if there's a
> moment of memory pressure pages will move to swap. Later when there's no
> memory pressure pages will remain in swap if they aren't accessed, process
> is sleeping and so.
>
> So, having pages in swap doesn't mean anything, more important would be to
> identify when is the swapping happening, and if its frequent or not.
>
> Of course, you can disable swap...
>
> Don't know if the previous ever/still applies to Openbsd
>
> Regards

Yes, a physical memory shortage in the past can lead to swapped out
pages. Pages remain in swap if the pages are untouched since then,
even after the memory shortage is gone. You can look for processes
that have a large virtual size (SIZE column in top) but much less
memory in the resident set (RES column in top).

-Otto