Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.user > #196472 > unrolled thread
| Started by | Borden Rhodes <jrvp@bordenrhodes.com> |
|---|---|
| First post | 2018-06-07 20:40 +0200 |
| Last post | 2018-06-08 09:40 +0200 |
| Articles | 3 — 3 participants |
Back to article view | Back to linux.debian.user
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
| From | Borden Rhodes <jrvp@bordenrhodes.com> |
|---|---|
| Date | 2018-06-07 20:40 +0200 |
| Subject | Re: 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]
| From | Mark Fletcher <mark27q1@gmail.com> |
|---|---|
| Date | 2018-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]
| From | Reco <recoverym4n@gmail.com> |
|---|---|
| Date | 2018-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