[Bug 1100080] New: Kontact / /kmail, / akonadi has a memory leak with the standard kernel of leap 15
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080 Bug ID: 1100080 Summary: Kontact / /kmail, / akonadi has a memory leak with the standard kernel of leap 15 Classification: openSUSE Product: openSUSE Distribution Version: Leap 15.0 Hardware: x86-64 OS: SUSE Other Status: NEW Severity: Major Priority: P5 - None Component: KDE Applications Assignee: opensuse-kde-bugs@opensuse.org Reporter: stakanov@freenet.de QA Contact: qa-bugs@suse.de Found By: --- Blocker: --- I experiencing the following: system of 8 GB Ram and 8 GB Swap, SSD Samsung. opening a user with kmail and kpop accounts open, filters active. openning a second user with kmail and imap active leaving now the machine idle (only automatic mail check, with ore w/o a browser open. The, as mentioned in bug 1097605, the machine has: with the 4.4 kernel and this configuration: a memory consumption of 2.5 gb with the original leap 15 kernel: a memory consumption of 6-7 GB of ram and a swap of up to 3.7 gb. All memory seems to be used by the both processes of akonadi, were the akonadi process of the kpop accounts take the most. Closing down kmail will free about 1-1,5 GB of ram. Stopping akonadi will cause a slow freeing up of about an additional 4 GB of ram, however swap will stay on 2GB once created. As said, this is linked to how the kernel 4.12 interacts with the system when idle. This is the case of 100% of sessions, it is sufficient to leave the user open and to let the system idle. If working with the system, the memory will not rise in that way. When recalling the system to life, after being idle, it will then work heavily with the ssd (because it seems it takes the necessary data from swap. The system will be sluggish and will need very long, at times mouse cursor will be frozen (and free after about a minute). Closing down the user with kmail open will eventually free up up to 90% of the claimed memory. When both users are open it may happen that the user instance with imap accounts running will also bloat but only up to 2-3 GB for akonadi, without claiming full 7 GB of ram and 3 of swap. If left alone idle for a period superior to an estimated 3 hours or more, the system will run out of memory, temp will go critical and the system will shut down. All this, I have to point this out will happen only with the combination of standard leap 15 kernel and akonadi/kmail. It does not happen if one uses leap 15 with the 4.4 kernel from 42.3. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c1
Stakanov Schufter
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c2
Fabian Vogt
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c3
--- Comment #3 from Stakanov Schufter
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c4
--- Comment #4 from Stakanov Schufter
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
Wolfgang Bauer
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c5
--- Comment #5 from Stakanov Schufter
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c6
Daniel Noga
FYI: this is fixed in 15.1 provided you erase all old search data and reindex all. In 15.0 this is not solved by this procedure instead. So fixed in 15.1 but continues to exist in 15.0.
Are you sure? 15.1 uses the same lmdb as 15.0. I think it is only bad luck that workaround did not work in 15.0 for you . I had no problem in Leap 15.0 and it started only with 15.1 for me (delete database workaround resolved it). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c7
--- Comment #7 from Stakanov Schufter
(In reply to Stakanov Schufter from comment #5)
FYI: this is fixed in 15.1 provided you erase all old search data and reindex all. In 15.0 this is not solved by this procedure instead. So fixed in 15.1 but continues to exist in 15.0.
Are you sure? 15.1 uses the same lmdb as 15.0. I think it is only bad luck that workaround did not work in 15.0 for you . I had no problem in Leap 15.0 and it started only with 15.1 for me (delete database workaround resolved it).
Unfortunately yes. As soon as I did install 15.1 I had even worse crashes with the indexer. But after going through the procedure once again, it worked finally. So for me it did a difference. Why it did not work before I cannot tell you because with 15.0 I performed exactly the same procedure. anyway, I confirm that it works in 15.1 with the procedure. If nobody else experience the problem in 15.0 then we may close this. By seeing the numbers of duplicates of this bug in Kde bugzilla I have some doubts however. Normally with this crash I experienced shortly after a memory leak of kmail. Also this is gone in 15.1. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c8
Peter Varkoly
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080
http://bugzilla.opensuse.org/show_bug.cgi?id=1100080#c9
--- Comment #9 from Stakanov Schufter
Dupl
*** This bug has been marked as a duplicate of bug 1136132 ***
So a bug from 2018 is becoming a duplicate of a bug from 2019 and no answer since the original report? I am confused. But O.K. as long as you care about it. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply@novell.com