[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index][Old Index]
Re: port-amd64/54988: possible memory leaks/swap problems
> From: mlh%goathill.org@localhost (MLH)
> Joerg Sonnenberger wrote:
> > On Thu, Feb 20, 2020 at 04:15:01AM +0000, MLH wrote:
> > >
> > > Any idea on what is preventing the memory from being released and
> > > why it just locks up?
> > I don't know, I'm just saying that you are looking at the wrong pools.
> > Look for those with high Npage, those are actually big.
> The problem continues to appear to be a filesystem-related issue
> as I can do compute-bound jobs with no problem. Physical memory is
> recovered as it normally does with no issue. Large or intensive
> filesystem writes appear to cause the system to seize and it doesn't
> even appear to require physical memory to be exhausted as it just
> seized twice with vmstat showing over 2G of available physical
> memory, and physical memory isn't showing to be recovered after
> intensive fs writes when I stop it before the system seizes.
> Have any filesystem-related changes been done recently?
Such as (from CHANGES) :
uvm: More precisely track clean/dirty pages, and change how they are
indexed, speeding up fsync() on large files by orders of
magnitude. Original work done by yamt@. [ad 20200115]
as all was fine just before this change and then with kernels from
the last of Jan on, I am seeing the problems.
Main Index |
Thread Index |