Hi Marco, Thanks very much for the trouble you have taken in your reply, I do appreciate it very much.
On Sun, 8 Mar 2020, Marco Möller wrote:
Upgrading your OS could result in the indexed search database to become rebuild, and this can take a very(!) long time and meanwhile painfully rendering your system almost unresponsive ...
Yes, true enough, but I have to say in this case - (1) this would be obvious as a process using resources (e.g. in top, or atop, which has already been covered in this thread, and my Nagios monitoring would immediately and very clearly have shown me what was happening, and thus I would not have been posting to this list;) and
I assume that you have maybe GNOME or KDE Plasma ...
(2) as already mentioned the desktop is XFCE, which I have not seen do such things (although I'll happily admit that I may just not have been looking hard enough:).
I am still curious to read about the outcome of your investigations.
Given what I found last night, so, I imagine, will be everyone else! As mentioned in the thread I suspected the kernel was the problem, and I am now sure of that. Below are the timings of the simple rsync copy operation that I've been using as a quick test. The first two I have already posted in earlier messages; the last two are new - I only finished building the last custom kernel last night, and I tried the Stretch stock kernel just for fun. This is a tab-separated list, I'm sorry if you don't do fixed pitch. :( Kernel Debian Time Notes 4.19 Buster 8m42s Stock kernel, Buster 3.16 Jessie 1m17s Stock kernel, Jessie 4.9 Stretch 2m40s Stock kernel, Stretch 4.19-F Buster 0m52s Custom kernel, Buster This is an 'rsync -avP' copy of a roughly 3 gigabyte file to /dev/shm/ and it generally gives an indication of what's going to happen within a couple of seconds of hitting 'return'. The transfer rate is about 40 MBytes/s with the Jessie 3.16 kernel, and about 6 MBytes/s with the stock Buster kernel. With my custom kernel it's about 60 MBytes/s on exactly the same hardware (and, otherwise, exactly the same OS) as in the measurement above (stock 4.19 kernel) which gives 6 MBytes/s, i.e. it's literally an order of magnitude faster. Food for thought. The kernel shipped with Debian Jessie was OK, but even though Buster has left it available for booting, and it does in fact boot, X won't run with it so it's effectively useless. The stock kernel in Stretch is bad enough, but the kernel shipped with Debian Buster is absolutely hopeless. The performance of the _same_ version 4.19 kernel, but with a mountain of junk removed using 'make menuconfig', is something like 50% better in this crude comparison than even the stock Jessie kernel. X seems to be fine with the custom 4.19 kernel but it hasn't yet stood the test of users hammering away at it doing actual work. Most likely after a few more exercises on the bench I'll install it at the farm tomorrow and hope that it survives. Unfortunately my tweaks to the stock kernel configuration resembled wading through the jungle with a machete, and a diff between the stock Buster kernel .config and my own .config amounts to 7,173 lines. Most of these I am sure are irrelevant to this issue, because they're about building modules which will never be used in any case on the systems I'm working with. I would like to narrow it down to which differences matter and which do not, but time is pressing and I do need to get the system I'm working with back into service for its users. I am very happy to post the custom kernel .config as it stands, if anyone would like to see it. My first suspicion is that SPECTRE etc. mitigations might be causing more serious problems on this architecture than they do on some others, but that's really a wild guess.
Wishing you all the best!
And the same you (and everyone else) too! -- 73, Ged.
