Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > linux.debian.user > #196472 > unrolled thread

Re: The Internet locks up Buster

Started byBorden Rhodes <jrvp@bordenrhodes.com>
First post2018-06-07 20:40 +0200
Last post2018-06-08 09:40 +0200
Articles 3 — 3 participants

Back to article view | Back to linux.debian.user


Contents

  Re: The Internet locks up Buster Borden Rhodes <jrvp@bordenrhodes.com> - 2018-06-07 20:40 +0200
    Re: The Internet locks up Buster Mark Fletcher <mark27q1@gmail.com> - 2018-06-08 01:00 +0200
    Re: The Internet locks up Buster Reco <recoverym4n@gmail.com> - 2018-06-08 09:40 +0200

#196472 — Re: The Internet locks up Buster

FromBorden Rhodes <jrvp@bordenrhodes.com>
Date2018-06-07 20:40 +0200
SubjectRe: The Internet locks up Buster
Message-ID<vY7Zg-2z8-11@gated-at.bofh.it>
> I.e. 12309 bug is back. It's obscure and presumably fixed (at least four
> times fixed) bug that happens with relatively slow filesystem (be it
> SSD/HDD/NFS or whatever) and a large amount of free RAM. I first
> encountered the thing back in 2.6.18 days, where it was presumably
> implemented (as in - nobody complained before ;).

Thank you, Reco and Abdullah, for providing some very helpful
information. I'll retest with the kernel parameters. I went over to
https://bugzilla.kernel.org/show_bug.cgi?id=12309 and it seems they've
closed the bug and/or given up on this. Is there any value in
continuing to whine about this problem? I mean, it's not like
large-capacity RAM is going away.

[toc] | [next] | [standalone]


#196476

FromMark Fletcher <mark27q1@gmail.com>
Date2018-06-08 01:00 +0200
Message-ID<vYc2S-59o-3@gated-at.bofh.it>
In reply to#196472
On Thu, Jun 07, 2018 at 02:13:17PM -0400, Borden Rhodes wrote:
> > I.e. 12309 bug is back. It's obscure and presumably fixed (at least four
> > times fixed) bug that happens with relatively slow filesystem (be it
> > SSD/HDD/NFS or whatever) and a large amount of free RAM. I first
> > encountered the thing back in 2.6.18 days, where it was presumably
> > implemented (as in - nobody complained before ;).
> 
> Thank you, Reco and Abdullah, for providing some very helpful
> information. I'll retest with the kernel parameters. I went over to
> https://bugzilla.kernel.org/show_bug.cgi?id=12309 and it seems they've
> closed the bug and/or given up on this. Is there any value in
> continuing to whine about this problem? I mean, it's not like
> large-capacity RAM is going away.
> 

I feel like we are missing a trick here. Even with a relatively slow I/O 
device (I was faintly amused to see SSD in the list of relatively slow 
devices, if SSD is slow what is fast?) it should eventually catch up 
UNLESS something is generating an insane amount of I/O over a sustained 
period. Just browsing the web shouldn't do that unless RAM is very 
tight, and the O/P indicated they have lots of RAM.

I run my machine here with 24GB RAM and part of my filesystem is on an 
external USB hard drive cage. From reading this thread you'd think that 
when I run data analyses reading and writing that external drive cage, 
it would be a recipe for this bug, but it isn't. And that is because 
those processes do a lot of work and make the CPU work hard, but they 
don't do insane amounts of I/O. (lots, but not insane amounts)

So, I think the O/P should look into what is causing all the I/O in the 
first place, and why that I/O is sustained even when most of the 
processes on the system are blocked. Something isn't right there. The 
usual suspect would be swapping but again the O/P said they have 
"large-capacity RAM" and were just browsing the web with or without 
LibreOffice open -- this shouldn't trigger swapping.

Mark

[toc] | [prev] | [next] | [standalone]


#196483

FromReco <recoverym4n@gmail.com>
Date2018-06-08 09:40 +0200
Message-ID<vYka5-1D0-1@gated-at.bofh.it>
In reply to#196472
	Hi.

On Thu, Jun 07, 2018 at 02:13:17PM -0400, Borden Rhodes wrote:
> > I.e. 12309 bug is back. It's obscure and presumably fixed (at least four
> > times fixed) bug that happens with relatively slow filesystem (be it
> > SSD/HDD/NFS or whatever) and a large amount of free RAM. I first
> > encountered the thing back in 2.6.18 days, where it was presumably
> > implemented (as in - nobody complained before ;).
> 
> Thank you, Reco and Abdullah, for providing some very helpful
> information. I'll retest with the kernel parameters. I went over to
> https://bugzilla.kernel.org/show_bug.cgi?id=12309 and it seems they've
> closed the bug and/or given up on this.

You've missed a crucial part - this bug was fixed, and then fixed again,
and it went like this at least four times.
Which means that all previous fixes were incomplete.


> Is there any value in continuing to whine about this problem?

You mean, here, at debian-user? Someone might be able to provide you
with yet another workaround, which may or may not solve this problem for
you.

Or, filling a bug at bugs.debian.org? Never hurts, but due to the
obscurity of the problem chances of solving it this way are slim.

Or, you meant bugzilla.kernel.org? See above.

> I mean, it's not like large-capacity RAM is going away.

Yup. But HDDs do. SSDs are considered obsolete (NVMe is a new shiny toy).
Conventional SASes are going into happy land faster than you can blink.

We're living at interesting times - RAM amount is more or less static,
but I/O capacity grows with each passing year.

Reco

[toc] | [prev] | [standalone]


Back to top | Article view | linux.debian.user


csiph-web