[talk] Does swap still matter?

[Sujit K M]

On Thu, 17 Mar, 2022, 02:56 Pete Wright, <pete at nomadlogic.org> wrote:

>
>
> On 3/16/22 08:03, George Rosamond wrote:
> > This has been an on and off debate I've had with myself and others,
> > and wanted some input from others. Input from live experiences is
> > great, input from low-level devs is even better.
> >
> > When RAM never seemed adequate for a system in the past, the utility
> > of swap was obvious. You would see the spikes on top(1) when swap was
> > hit.
> >
> > swap = 2 x RAM, blah blah.
> >
> > Today, when those 64G or more of RAM are the norm for bare-metal
> > boxes, and it's overkill in many contexts, is swap still necessary?
>
> i'll bust out the only true answer in engineering...it depends :)
>
> one use-case for swap for me personally is saving core dumps via
> safecore and friends on freebsd.  for this allocating a 2gb partition to
> swap is fine for my purposes.
>
> the anti-pattern would be on any production system where i *never* want
> to swap out anything for both performance and security reasons.
>

Funny even IT might not know application is using swap.

>
> it's funny though, i can't remember when i've had swap save me from a
> binary with run-away memory consumption in the past decade at least.
> frankly by the time chrome/slack decide that it needs 3/4 of my 32gigs
> of ram it's game over anyway.
>
> ultimately i think if we had better OOMKiller functionality on linux, or
> better mechanisms in userland to manage and monitor memory over
> subscription and run-away processes in the general case, we could
> probably be done with swapping entirely.
>
> just my 2 bits,
> -pete
>
>
> --
> Pete Wright
> pete at nomadlogic.org
> @nomadlogicLA
>
> _______________________________________________
> talk mailing list
> talk at lists.nycbug.org
> https://lists.nycbug.org:8443/mailman/listinfo/talk
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.nycbug.org:8443/pipermail/talk/attachments/20220317/a4531772/attachment.htm>