https://bugzilla.novell.com/show_bug.cgi?id=741485
https://bugzilla.novell.com/show_bug.cgi?id=741485#c0
Summary: progressive system slowdown, eventually grinding to a
halt. Reproducible with Konqueror
Classification: openSUSE
Product: openSUSE 11.4
Version: Final
Platform: 64bit
OS/Version: SuSE Other
Status: NEW
Severity: Critical
Priority: P5 - None
Component: Kernel
AssignedTo: kernel-maintainers@forge.provo.novell.com
ReportedBy: andreas_nordal_4@hotmail.com
QAContact: qa@suse.de
Found By: ---
Blocker: ---
User-Agent: Mozilla/5.0 (X11; Linux x86_64) KHTML/4.7.2 (like Gecko)
Konqueror/4.7 SUSE
Note: "Operating System" should be OpenSuse 12.1 rather than "SuSE Other", but
that was not an option in the menu for filing this bug.
My computer slowly grinds to a halt when visiting
http://tineskreativehjorne.com with Konqueror using KHTML.
Symptoms:
The computer gets progressively slower. From regular-slow with swapping, to
painstakingly slow, to completely unusable, and infinitely beyond. It seems
Linux is too busy to take user input into account (where's that 200 line
patch?). Programs don't make much progress either.
I managed to reproduce this a second time after emptying Konqueror's web cache.
Although I think I can reproduce this systematically, I haven't tried more than
twice. I have also experienced this progressive slowdown in several other ways
(copying files to USB stick, copying files to network attached storage) that I
don't remember equally well, all with OpenSuse 12.1, but I'll focus on the web
testcase for now.
System info:
2 GB RAM + 2 GB swap
Processor: Core 2 Duo T8100
kernel used for the web testcase: kernel-desktop-3.1.0-1.2.1.x86_64
special kernel parameters: NOHZ=off (due to bug 579932)
Reproducible: Always
Steps to Reproduce:
With Konqueror:
1. Set default rendering engine to KHTML
2. If having visited http://tineskreativehjorne.com before, clear the cache.
3. Go to http://tineskreativehjorne.com
Actual Results:
In the second reproduction, I just watched the early phase, with swap usage
rising to 600 MB, and then killed Konqueror before it was too late, which
immediately made the system snappy again. Thus, the description below is from
the first:
When Konqueror showed that it had loaded 97% of that page, things started to
get slow. At first, my computer just felt regular-slow – my harddisk was
swapping heroically, but I was actually able to open ksysguard, iotop, etc.
However, trying to close the likely offending tab of Konqueror proved futile –
I clicked the button at ~10Hz (yes I have measured my endurance clicking
frequency) for a minute, at least, but there was no response! The only other
open tab was showing a local directory containing 22 folders and 39 files.
I had a feeling that performance was degrading, so I placed Konqueror and
Ksysguard next to each other on the screen, and just let Linux swap in peace
for 15 mins.
When I came back, moving the mouse cursor required extreme patience. Konqueror
had loaded 98% of the page. I tried killing Konqueror from Ksysguard:
Right-clicking on "konqueror" and selecting "kill process", in between I had a
toilet visit, and to my horror, suddenly "ksysguard" was selected for killing.
However, that didn't matter, because 5 mins later, still none of them had been
killed (as it turned out, I was still waiting for the confirmation dialog!), at
which point I realised I had to pull the plug.
Konqueror's memory use had been slowly fluctuating roughly between 1.52 and
1.57 GB all the time since measuring started (at 97% loaded).
Konqueror with WebKit, and Firefox, are able to show the page without problems,
using only 162 and 130 MB memory, respectively.
After having succeeded to show the page using WebKit in Konqueror, switching to
KHTML again did not make it fail, and it just used 254 MB memory. However, all
I did from this state to reproduce, was to reopen* Konqueror, empty its cache,
and go to the page again.
*Since I am also seeing this bug:
https://bugs.kde.org/show_bug.cgi?id=257012
what I mean by "reopen"ing Konqueror is actually close, kill, open.
Expected Results:
No program should be able to cause significantly worse system slowdown than a
dedicated memory leaker like this C program (which achieves only "regular-slow"
on my scale):
#include