[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Swap priority in Debian



	Hi.

On Sat, Aug 25, 2018 at 06:07:01PM +0530, Subhadip Ghosh wrote:
> 
> 
> On Saturday 25 August 2018 04:29 PM, Reco wrote:
> > 	Hi.
> > 
> > On Sat, Aug 25, 2018 at 09:42:31AM +0530, Subhadip Ghosh wrote:
> > > Hi,
> > > 
> > > I am a Debian testing user. Recently I am experiencing freezing on my Debian
> > > system intermittently and during troubleshooting the same, I found out that
> > > the I have a swap partition with priority set to -2.
> > Same here with stable.
> > 
> > 
> > > But according to the below manpage:
> > > 
> > > https://manpages.debian.org/stretch/mount/swapon.8.en.html
> > > 
> > > swap priority should be between -1 and 32767.
> > So swapon(8) utility has this restriction. Note that the system call
> > itself - swapon(2) merely interprets swap priority as a signed integer,
> > so any priority number is actually possible (within integer limits of
> > course).
> > 
> > 
> > > I have a swappiness value of 60 but I don't remember seeing the swap
> > > being used at all recently, the used swap is always 0%.
> > A hint. They invented this wonderful thing called sysstat decades ago so
> > you don't have to remember your swap usage, along with other things
> > sysstat gathers.
> > 
> > 
> > > My question is, do you think that the -2 priority is stopping the swap
> > > partition from actually being used and because of that, the system is
> > > getting frozen when the memory usage is high?
> > No, it definitely does not work this way.
> > A swap priority only comes into play once you have multiple instances of
> > swaps. If you have a single swap partition/lv/file, a priority value is
> > meaningless.
> > 
> > A system freezes, on the other hand (did I mention sysstat?), could
> > indicate heavy swapping, barrier writes, kernel bugs (12309, anyone?),
> > oom killer invocations, overheating and many other things.
> > A good starting point would be kernel message log (aka
> > /var/log/kern.log) from the time of this freeze.
> Thanks for the suggestion. I checked the kern.log but did not find any
> suspicious log, in fact no entry from that exact time frame when the last
> freeze happened. Do you have any other suggestions to troubleshoot the
> freezes?

"sar -r ALL -f 25" and "sar -S -f 25" would be the next logical step.
Note that "25" means current date (i.e. 25th of current month).

Should be preceeded by "apt install sysstat", of course.

Reco


Reply to: