akonadiserver and kmail are leaking memory

classic Classic list List threaded Threaded
22 messages Options
12
Reply | Threaded
Open this post in threaded view
|

akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
Hi,

after finally moving to Tumbleweed from some KDE 4 based akonadiserver and
kmail setup, I noticed them to exhaust my systems 32G memory:

hp       14482  5.6 83.7 41289736 27545972 ?   Sl   13:03  15:34 /usr/bin/
akonadiserver
hp       14912  0.1  2.2 6302588 743184 ?      Sl   13:04   0:28 /usr/bin/
kmail -qwindowtitle KMail

Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5 hours
wall clock run time.

The KDE 4 versions where almost stable for the same setup, that consists from
some huge IMAP mailboxes, indeed.

Does somebody know, if the upcoming kdepim versions behave better in this
respect? In other words, is it advisable to try?

Thanks,
Pete


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

auxsvr
On Sunday, 31 March 2019 19:05:32 EEST Hans-Peter Jansen wrote:
> Hi,
Hi,

> after finally moving to Tumbleweed from some KDE 4 based akonadiserver and
> kmail setup, I noticed them to exhaust my systems 32G memory:
>
> hp       14482  5.6 83.7 41289736 27545972 ?   Sl   13:03  15:34 /usr/bin/
> akonadiserver
> hp       14912  0.1  2.2 6302588 743184 ?      Sl   13:04   0:28 /usr/bin/
> kmail -qwindowtitle KMail
>
> Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5 hours
> wall clock run time.
>
> The KDE 4 versions where almost stable for the same setup, that consists from
> some huge IMAP mailboxes, indeed.
>
> Does somebody know, if the upcoming kdepim versions behave better in this
> respect? In other words, is it advisable to try?

I've been using the KDE 5 versions for a long time. I've encountered several issues, but not high RAM usage,
from what I recall.
How many emails do you have?
--
Regards,
Peter


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Knurpht-openSUSE
In reply to this post by Hans-Peter Jansen-2
Op zondag 31 maart 2019 18:05:32 CEST schreef Hans-Peter Jansen:

> Hi,
>
> after finally moving to Tumbleweed from some KDE 4 based akonadiserver and
> kmail setup, I noticed them to exhaust my systems 32G memory:
>
> hp       14482  5.6 83.7 41289736 27545972 ?   Sl   13:03  15:34 /usr/bin/
> akonadiserver
> hp       14912  0.1  2.2 6302588 743184 ?      Sl   13:04   0:28 /usr/bin/
> kmail -qwindowtitle KMail
>
> Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5 hours
> wall clock run time.
>
> The KDE 4 versions where almost stable for the same setup, that consistst
> from some huge IMAP mailboxes, indeed.
>
> Does somebody know, if the upcoming kdepim versions behave better in this
> respect? In other words, is it advisable to try?
>
> Thanks,
> Pete
I've experienced this in the early days, the solution was to rebuild the
akonadi database. Both memory and CPU usage went back to "normal" after all
the indexing was done. This for ~8 IMAP accounts, ~200.000 emails. A couple of
months later I switched from mariadb/mysql to postgressql, which definitely is
faster. The only negative side effect in both cases was that I had to recreate
my ~20 filters, but I took that as an opportunity to review them and
reorganize them.

--
Gertjan Lettink a.k.a. Knurpht
openSUSE Board Member
openSUSE Forums Team


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In reply to this post by Hans-Peter Jansen-2
In data domenica 31 marzo 2019 18:05:32 CEST, Hans-Peter Jansen ha scritto:

> Hi,
>
> after finally moving to Tumbleweed from some KDE 4 based akonadiserver and
> kmail setup, I noticed them to exhaust my systems 32G memory:
>
> hp       14482  5.6 83.7 41289736 27545972 ?   Sl   13:03  15:34 /usr/bin/
> akonadiserver
> hp       14912  0.1  2.2 6302588 743184 ?      Sl   13:04   0:28 /usr/bin/
> kmail -qwindowtitle KMail
>
> Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5 hours
> wall clock run time.
>
> The KDE 4 versions where almost stable for the same setup, that consists
> from some huge IMAP mailboxes, indeed.
>
> Does somebody know, if the upcoming kdepim versions behave better in this
> respect? In other words, is it advisable to try?
>
> Thanks,
> Pete

Leap 15.0
Bug 1100080
Try to uninstall baloo indexer. When it crashes then kmail leaks huge amount
of memory up to shutdown or unresponsiveness.
The bug is known to kde and it is linked to lmdb.
While to TW it was cherrypicked and backported (there is a fix) the Leap 15
version did not receive this blessing up to now.
with mysql, the system does not complain always, only sometimes rarely konqi
pops up after baloo crashed.
If you use postgres you will instead receive an instant konqi list of the
crash. You can compare the backtrace in the bug. Don't know why.
The number of the kde original bug with indications about the fix you find it
in the title.

If it is you will see in ksysgard:
a kontact session that stays open even if you shut it down from "exit the
program" (zombi), a korgac instance, akonadi with huge memory consumption, and
a huge number of http.so instances that will go away only after doing the
following:
kill the processes of kontact, korgac
then in the terminal: akonadictl stop
wait for the akonadi and  http.so are gone, you will see the memory normalize.
Kill then baloo indexer if he still lingers around and kill all other baloo
instances if open.

simply restart kontact and you system will run for weeks as long as:
you do not suspend to disc or to ram. Than the whole thing may start over (or
you wlan disappears, or you do not have access to the wallet etc. All little
bugs that will be fixed one day).
But if you running a system for long time without suspending it, (days, weeks)
then this method works.
Always said you are not running into some other kmail/kontact/akonadi bug.
Good luck.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
In reply to this post by auxsvr
Am Sonntag, 31. März 2019, 18:43:57 CEST schrieb auxsvr:

> On Sunday, 31 March 2019 19:05:32 EEST Hans-Peter Jansen wrote:
> > Hi,
>
> Hi,
>
> > after finally moving to Tumbleweed from some KDE 4 based akonadiserver and
> > kmail setup, I noticed them to exhaust my systems 32G memory:
> >
> > hp       14482  5.6 83.7 41289736 27545972 ?   Sl   13:03  15:34 /usr/bin/
> > akonadiserver
> > hp       14912  0.1  2.2 6302588 743184 ?      Sl   13:04   0:28 /usr/bin/
> > kmail -qwindowtitle KMail
> >
> > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > hours
> > wall clock run time.
> >
> > The KDE 4 versions where almost stable for the same setup, that consists
> > from some huge IMAP mailboxes, indeed.
> >
> > Does somebody know, if the upcoming kdepim versions behave better in this
> > respect? In other words, is it advisable to try?
>
> I've been using the KDE 5 versions for a long time. I've encountered several
> issues, but not high RAM usage, from what I recall.
> How many emails do you have?

The biggest MB carries about 6.7M mails in 134GiB.

Cheers,
Pete



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
In reply to this post by Knurpht-openSUSE
Am Sonntag, 31. März 2019, 19:02:02 CEST schrieb Knurpht-openSUSE:
> Op zondag 31 maart 2019 18:05:32 CEST schreef Hans-Peter Jansen:
> >
> > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > hours
> > wall clock run time.
> >
>
> I've experienced this in the early days, the solution was to rebuild the
> akonadi database.

Been there, done that, same result. In fact, the whole indexing failed much
more miserable before I tuned the mysql config to some degree, due to timeouts
(which is okay, given my admittedly pathologic case).

> Both memory and CPU usage went back to "normal" after all
> the indexing was done.

Yes, I hope so as well. But it's still indexing (since Thursday...), and
crashed the system hard at least once.

> This for ~8 IMAP accounts, ~200.000 emails. A couple
> of months later I switched from mariadb/mysql to postgressql, which
> definitely is faster. The only negative side effect in both cases was that
> I had to recreate my ~20 filters, but I took that as an opportunity to
> review them and reorganize them.

Well, that's not a problem here, since I don't use any local filters, all done
with sieve on the server, of course.

Will try Postgres, then. When throwing away the whole akonadi folder, there's
a real PITA: it enumerates all IMAP folders, resulting in a fully mixed up
special folders setup (Sent, Drafts, Templates, Trash) for all accounts :-(

That's a major flaw of kmail since ever... Cannot remember kmail 1 behavior
exactly, though. ;-)

Cheers,
Pete


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
In reply to this post by Stakanov Schufter
Am Sonntag, 31. März 2019, 19:38:14 CEST schrieb stakanov:

> In data domenica 31 marzo 2019 18:05:32 CEST, Hans-Peter Jansen ha scritto:
> >
> > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > hours
> > wall clock run time.
> >
>
> Leap 15.0
> Bug 1100080
> Try to uninstall baloo indexer. When it crashes then kmail leaks huge amount
> of memory up to shutdown or unresponsiveness.
> The bug is known to kde and it is linked to lmdb.
> While to TW it was cherrypicked and backported (there is a fix) the Leap 15
> version did not receive this blessing up to now.
> with mysql, the system does not complain always, only sometimes rarely konqi
> pops up after baloo crashed.

Don't know, if that fits the bill.

It's Tumbleweed, and if I'm reading your report correctly, the lmdb issue is
fixed here. Looks, like upstream found it even severe enough to create new
release, that is awaiting TW blessing, but a patch with a fix was applied Oct
6, 2018.

Next, it's the kernel, that stops akonadiserver, when it has eaten all memory
and swap. I don't let it swap, when I'm on, of course.

The baloo processes behave, they use 256G VSZ, but only tiny amounts of RSS,
which is the painful part here.

I need to stop now, and shutdown akonadi again, before the system becomes
sluggish and this mail wont get out...

Cheers,
Pete



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In data domenica 31 marzo 2019 22:59:05 CEST, Hans-Peter Jansen ha scritto:
> Am Sonntag, 31. März 2019, 19:38:14 CEST schrieb stakanov:
> > In data domenica 31 marzo 2019 18:05:32 CEST, Hans-Peter Jansen ha
scritto:

> > > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > > hours
> > > wall clock run time.
> >
> > Leap 15.0
> > Bug 1100080
> > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > amount of memory up to shutdown or unresponsiveness.
> > The bug is known to kde and it is linked to lmdb.
> > While to TW it was cherrypicked and backported (there is a fix) the Leap
> > 15
> > version did not receive this blessing up to now.
> > with mysql, the system does not complain always, only sometimes rarely
> > konqi pops up after baloo crashed.
>
> Don't know, if that fits the bill.
>
> It's Tumbleweed, and if I'm reading your report correctly, the lmdb issue is
> fixed here. Looks, like upstream found it even severe enough to create new
> release, that is awaiting TW blessing, but a patch with a fix was applied
> Oct 6, 2018.
>
> Next, it's the kernel, that stops akonadiserver, when it has eaten all
> memory and swap. I don't let it swap, when I'm on, of course.
>
> The baloo processes behave, they use 256G VSZ, but only tiny amounts of RSS,
> which is the painful part here.
>
> I need to stop now, and shutdown akonadi again, before the system becomes
> sluggish and this mail wont get out...
>
> Cheers,
> Pete
You have my compassion. That problem must be fixed. Honestly Kontact Akonadi
would be such a good and useful program if these issues would get out of the
way finally. I am a bit discouraged by that news, but I heard that there were
other bugs chiming in after the fix of lmdb bug.
Please let me know if there is a report number, I would like to be on the cc
list to follow it. So I will know what I have to expect (leap is like a time
machine backwards).
All the best.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Luca Beltrame
In reply to this post by Stakanov Schufter
In data domenica 31 marzo 2019 19:38:14 CEST, stakanov ha scritto:

> Try to uninstall baloo indexer. When it crashes then kmail leaks huge amount
> of memory up to shutdown or unresponsiveness.

That's totally unrelated. The indexer in Akonadi, although originally derived
from Baloo, uses Xapian and not lmdb (while Baloo the file indexer does indeed
use lmdb).

However it might be useful to optimize the database with "akonadictl vacuum".

> simply restart kontact and you system will run for weeks as long as:
> you do not suspend to disc or to ram. Than the whole thing may start over

I can't reproduce this issue with suspension (I *did* with hibernation,
though, but just once, and there was some other lingering bug that was later
fixed, so I'm not sure if it was the cause), I suspend my laptop a lot and PIM
behaves correctly.

--
Luca Beltrame
GPG key ID: A29D259B

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Wolfgang Bauer
In reply to this post by Hans-Peter Jansen-2
Am Sonntag, 31. März 2019, 22:40:41 schrieb Hans-Peter Jansen:

> Am Sonntag, 31. März 2019, 19:02:02 CEST schrieb Knurpht-openSUSE:
> > Op zondag 31 maart 2019 18:05:32 CEST schreef Hans-Peter Jansen:
> > > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > > hours
> > > wall clock run time.
> >
> > I've experienced this in the early days, the solution was to rebuild the
> > akonadi database.
>
> Been there, done that, same result. In fact, the whole indexing failed much
> more miserable before I tuned the mysql config to some degree, due to
> timeouts (which is okay, given my admittedly pathologic case).

One particular problem (causing huge memory and/or CPU time) I do remember
(not from actual experience, but from reading bug reports) was caused by
broken/corrupted agent_config_*_changes.dat files in the ~/.config/akonadi/
folder.
Deleting them helped (and should not cause data loss) apparently.

But that was years ago, should probably not occur nowadays...

> Will try Postgres, then. When throwing away the whole akonadi folder,
> there's a real PITA: it enumerates all IMAP folders, resulting in a fully
> mixed up special folders setup (Sent, Drafts, Templates, Trash) for all
> accounts :-(
>
> That's a major flaw of kmail since ever... Cannot remember kmail 1 behavior
> exactly, though. ;-)

Yeah, that's because folders are referred to by their (numerical) id in the
Akonadi database.
"Fixing" that would probably cause other problems though AIUI.

Kind Regards,
Wolfgang

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Wolfgang Bauer
In reply to this post by Luca Beltrame
Am Montag, 1. April 2019, 10:16:38 schrieb Luca Beltrame:
> In data domenica 31 marzo 2019 19:38:14 CEST, stakanov ha scritto:
> > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > amount of memory up to shutdown or unresponsiveness.
>
> That's totally unrelated. The indexer in Akonadi, although originally
> derived from Baloo, uses Xapian and not lmdb (while Baloo the file indexer
> does indeed use lmdb).

Indeed.
Although the mail indexer certainly has the *potential* to slow things down as
well (in the past at least, should be much better nowadays of course).

It can be uninstalled too though, it's the package akonadi-search. (indexed
search and related features will of course cease to work then, but it may be
worth a try as a temporary measure)

It *may* be also worth a try to delete the search index, it may be in
~/.local/share/baloo/ (the sub folders *except* "file", which contains the
file search index obviously), or ~/.local/share/akonadi/searchdb/.
Which one is used depends on your system, akonadi-search reuses the first one
if it exists (for "compatibility" with older versions), but creates the latter
one if the first isn't there.

I do remember discussions about problems after Xapian updates, where this
"fixed" them, although IIRC that was mostly about crashes.

And, that can only help if your problem is indeed related to *indexing* of
course, not Akonadi itself.

Kind Regards,
Wolfgang

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In reply to this post by Luca Beltrame
In data lunedì 1 aprile 2019 10:16:38 CEST, Luca Beltrame ha scritto:

> In data domenica 31 marzo 2019 19:38:14 CEST, stakanov ha scritto:
> > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > amount of memory up to shutdown or unresponsiveness.
>
> That's totally unrelated. The indexer in Akonadi, although originally
> derived from Baloo, uses Xapian and not lmdb (while Baloo the file indexer
> does indeed use lmdb).
>
> However it might be useful to optimize the database with "akonadictl
> vacuum".
> > simply restart kontact and you system will run for weeks as long as:
> > you do not suspend to disc or to ram. Than the whole thing may start over
>
> I can't reproduce this issue with suspension (I *did* with hibernation,
> though, but just once, and there was some other lingering bug that was later
> fixed, so I'm not sure if it was the cause), I suspend my laptop a lot and
> PIM behaves correctly.
This is interesting. With leap 15?
There was a user on bugs.kde that claimed that the lmdb bug "vanishes" or does
not hit, if you do create a completely new account and do import all mail.
I cannot tell you what is the issue. I am getting here on a X201 otherwise
working well a crash per user of baloo indexer for every session. Even when
the system has not been suspended and you run the automatized archiver. Then
the crash (and the memory leak of akonadi) happens right after.
What is also visible: an old bug reappears, that one that shows you a window
with a filter asking for the "right account" to attribute that filter to. But
it is no choice given. If you press O.K. the filter will be eliminated and the
next crash a new filter will be presented. Until you have no filter any more.
I tried a lot of things. Also the complete elimination and recreation of all
filters (a lot of work). But nothing helps and this is the case since Leap15.
I did open a bug but was referred to bugs.kde.
If you have any advice to not hesitate, because the situation is quite
tedious.
BTW leap has really a LOT of bugs that hit this machine. Kpowerdevil crashes
on a regular base, baloo indexer we talked about. Wlan sometimes vanishes
after suspend to disc (hibernation) because the ucode cannot be loaded by
networkmanager, I give you an excerpt of the error code after every wakeup
(because it seem to have to do with networkmanager), just to get an
impression:

----begin journalctloutput -----
apr 01 11:08:11 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Unable to
initialize device.
apr 01 11:08:11 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Failed to run
INIT ucode: -5
apr 01 11:08:11 roadrunner.suse NetworkManager[1972]: <info>  
[1554109691.5472] device (wlan1): supplicant inter>
apr 01 11:08:11 roadrunner.suse NetworkManager[1972]: <info>  
[1554109691.5472] device (wlan1): supplicant inter>
apr 01 11:08:11 roadrunner.suse NetworkManager[1972]: <error>
[1554109691.5471] sup-iface[0x5613184bd810,wlan1]:>
apr 01 11:08:09 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Could not load
the [0] uCode section
apr 01 11:08:09 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Radio
type=0x0-0x3-0x1
apr 01 11:08:08 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Unable to
initialize device.
apr 01 11:08:08 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Failed to run
INIT ucode: -5
apr 01 11:08:07 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Could not load
the [0] uCode section
apr 01 11:08:06 roadrunner.suse kernel: iwlwifi 0000:02:00.0: Radio
type=0x0-0x3-0x1
apr 01 11:08:06 roadrunner.suse NetworkManager[1972]: <warn>  
[1554109686.3987] device (wlan1): re-acquiring sup>
apr 01 11:07:58 roadrunner.suse systemd[1]: Started Show Plymouth Reboot
Screen.
apr 01 11:07:58 roadrunner.suse systemd[1]: Received SIGRTMIN+20 from PID
29299 (plymouthd).
apr 01 11:07:58 roadrunner.suse systemd[1]: Starting Show Plymouth Reboot
Screen...
apr 01 11:07:58 roadrunner.suse systemd[1]: Stopped X Display Manager.
apr 01 11:07:58 roadrunner.suse display-manager[29182]: Shutting down service
sddm..done
apr 01 11:07:58 roadrunner.suse sddm[2228]: QProcess: Destroyed while process
("/usr/lib/sddm/sddm-helper") is s>
apr 01 11:07:58 roadrunner.suse sddm[2228]: Running display stop script  "/
usr/share/sddm/scripts/Xstop"
apr 01 11:07:58 roadrunner.suse sddm[2228]: Display server stopped.
apr 01 11:07:58 roadrunner.suse systemd[1]: Unmounted /run/user/1002.
apr 01 11:07:58 roadrunner.suse systemd-logind[1778]: Removed session 4.
apr 01 11:07:58 roadrunner.suse systemd[1]: Removed slice User Slice of
mercurio.
apr 01 11:07:58 roadrunner.suse systemd[1]: Stopped Session 4 of user
mercurio.
apr 01 11:07:57 roadrunner.suse sddm-helper[29293]: [PAM] returning.
apr 01 11:07:57 roadrunner.suse sddm-helper[29293]: [PAM] Authenticating...
apr 01 11:07:57 roadrunner.suse sddm-helper[29293]: [PAM] Starting...
apr 01 11:07:57 roadrunner.suse sddm[2228]: Display server stopping...
apr 01 11:07:57 roadrunner.suse sddm[2228]: Socket server stopped.
apr 01 11:07:57 roadrunner.suse sddm[2228]: Socket server stopping...
apr 01 11:07:57 roadrunner.suse sddm[2228]: Adding cookie to "/run/sddm/
{e89e7a68-24c8-4c17-83dc-92aa5a5fc789}"
apr 01 11:07:57 roadrunner.suse sddm[2228]: Greeter starting...
apr 01 11:07:57 roadrunner.suse sddm[2228]: Loading theme configuration from
"/usr/share/sddm/themes/breeze-open>
apr 01 11:07:57 roadrunner.suse sddm[2228]: Socket server started.
apr 01 11:07:57 roadrunner.suse sddm[2228]: Socket server starting...
apr 01 11:07:57 roadrunner.suse sddm[2228]: Display server started.
apr 01 11:07:57 roadrunner.suse sddm[2228]: Running display setup script  "/
etc/X11/xdm/Xsetup"
apr 01 11:07:57 roadrunner.suse sddm[2228]: Setting default cursor
apr 01 11:07:57 roadrunner.suse systemd[1]: Stopped Restore /run/initramfs on
shutdown.
apr 01 11:07:56 roadrunner.suse pulseaudio[29230]: [pulseaudio] module-alsa-
card.c: Failed to open mixer for jac>
apr 01 11:07:56 roadrunner.suse sddm[2228]: Running: /usr/bin/X -nolisten tcp
-auth /run/sddm/{e89e7a68-24c8-4c1>
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server starting...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Loading theme configuration from
""
apr 01 11:07:56 roadrunner.suse sddm[2228]: Adding new display on vt 7 ...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Removing display ":2" ...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Running display stop script  "/
usr/share/sddm/scripts/Xstop"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server stopped.
apr 01 11:07:56 roadrunner.suse kded5[16431]: QFileSystemWatcher::removePaths:
list is empty
apr 01 11:07:56 roadrunner.suse kdeinit5[3855]:
QFileSystemWatcher::removePaths: list is empty
apr 01 11:07:56 roadrunner.suse kdeinit5[3855]:
QFileSystemWatcher::removePaths: list is empty
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server stopping...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Socket server stopped.
apr 01 11:07:56 roadrunner.suse sddm[2228]: Socket server stopping...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Auth: sddm-helper exited with 15
apr 01 11:07:56 roadrunner.suse sddm[2228]: Authentication error: "Process
crashed"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Auth: sddm-helper crashed (exit
code 15)
apr 01 11:07:56 roadrunner.suse sddm[2228]: Authentication error: "Process
crashed"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Removing display ":1" ...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Running display stop script  "/
usr/share/sddm/scripts/Xstop"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server stopped.
apr 01 11:07:56 roadrunner.suse drkonqi[29266]: Could not connect to any X
display.
apr 01 11:07:56 roadrunner.suse klauncher[29268]: Could not connect to any X
display.
apr 01 11:07:56 roadrunner.suse klauncher[29268]: qt.qpa.gl: QXcbConnection:
Failed to initialize GLX
apr 01 11:07:56 roadrunner.suse drkonqi[29266]: qt.qpa.gl: QXcbConnection:
Failed to initialize GLX
apr 01 11:07:56 roadrunner.suse ksmserver[3103]: ksmserver: ksmserver: Fatal
IO error: client killed
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server stopping...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Socket server stopped.
apr 01 11:07:56 roadrunner.suse sddm[2228]: Socket server stopping...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Auth: sddm-helper exited with 15
apr 01 11:07:56 roadrunner.suse sddm[2228]: Authentication error: "Process
crashed"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Auth: sddm-helper crashed (exit
code 15)
apr 01 11:07:56 roadrunner.suse sddm[2228]: Authentication error: "Process
crashed"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Signal received: SIGTERM
apr 01 11:07:56 roadrunner.suse sddm[2228]: Removing display ":0" ...
apr 01 11:07:56 roadrunner.suse sddm[2228]: Running display stop script  "/
usr/share/sddm/scripts/Xstop"
apr 01 11:07:56 roadrunner.suse sddm[2228]: Display server stopped.
apr 01 11:07:56 roadrunner.suse systemd[1]: Stopped target Host and Network
Name Lookups.
apr 01 11:07:56 roadrunner.suse systemd[1]: Stopped Postfix Mail Transport
Agent.
apr 01 11:07:56 roadrunner.suse postfix/master[2320]: terminating on signal 15
apr 01 11:07:56 roadrunner.suse postfix/postfix-script[29252]: stopping the
Postfix mail system
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] bluez5-util.c:
GetManagedObjects() failed: org.f>
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] main.c: Unable
to contact D-Bus: org.freedesktop>
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] server-
lookup.c: Unable to contact D-Bus: org.fr>
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] main.c: Module
load failed.
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] bluez5-util.c:
GetManagedObjects() failed: org.f>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] main.c: Unable
to contact D-Bus: org.freedesktop>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] server-
lookup.c: Unable to contact D-Bus: org.fr>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] main.c: Module
load failed.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Rejected send
message, 2 matched rules; type="method>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] module.c:
Failed to load module "module-jackdbus>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] module-
jackdbus-detect.c: Unable to contact D-Bu>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Rejected send
message, 2 matched rules; type="method>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] pid.c: Stale
PID file, overwriting.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] server-
lookup.c: Unable to contact D-Bus: org.fr>
apr 01 11:07:56 roadrunner.suse pulseaudio[29231]: [pulseaudio] main.c: Module
load failed.
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] bluez5-util.c:
GetManagedObjects() failed: org.f>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] main.c: Unable
to contact D-Bus: org.freedesktop>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] server-
lookup.c: Unable to contact D-Bus: org.fr>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] main.c: Module
load failed.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Rejected send
message, 2 matched rules; type="method>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] module.c:
Failed to load module "module-jackdbus>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] module-
jackdbus-detect.c: Unable to contact D-Bu>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Rejected send
message, 2 matched rules; type="method>
apr 01 11:07:55 roadrunner.suse pulseaudio[29231]: [pulseaudio] pid.c: Stale
PID file, overwriting.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] module.c:
Failed to load module "module-jackdbus>
apr 01 11:07:55 roadrunner.suse systemd[1]: Unmounted /run/user/1000.
apr 01 11:07:55 roadrunner.suse pulseaudio[29230]: [pulseaudio] module-
jackdbus-detect.c: Unable to contact D-Bu>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Removed session 2.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse systemd[1]: Stopped User Manager for UID 1002.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 4 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 6 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Unregistered Authentication
Agent for unix-session:4 (system bus >
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Operator of unix-session:6
FAILED to authenticate to gain authori>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <info>  
[1554109675.9030] device (wlan1): supplicant inter>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <error>
[1554109675.9030] sup-iface[0x5613184bdc30,wlan1]:>
apr 01 11:07:55 roadrunner.suse systemd[2996]: Received SIGRTMIN+24 from PID
29233 (kill).
apr 01 11:07:55 roadrunner.suse systemd[2996]: Starting Exit the Session...
apr 01 11:07:55 roadrunner.suse systemd[2996]: Reached target Shutdown.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Closed D-Bus User Message Bus
Socket.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Timers.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Paths.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Sockets.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Basic System.
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 4 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 6 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Unregistered Authentication
Agent for unix-session:4 (system bus >
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Operator of unix-session:6
FAILED to authenticate to gain authori>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <info>  
[1554109675.9030] device (wlan1): supplicant inter>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <error>
[1554109675.9030] sup-iface[0x5613184bdc30,wlan1]:>
apr 01 11:07:55 roadrunner.suse systemd[2996]: Received SIGRTMIN+24 from PID
29233 (kill).
apr 01 11:07:55 roadrunner.suse systemd[2996]: Starting Exit the Session...
apr 01 11:07:55 roadrunner.suse systemd[2996]: Reached target Shutdown.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Closed D-Bus User Message Bus
Socket.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Timers.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Paths.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Sockets.
apr 01 11:07:55 roadrunner.suse systemd[2996]: Stopped target Basic System.
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 4 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activation via
systemd failed for unit 'rtkit-daemon>
apr 01 11:07:55 roadrunner.suse dbus-daemon[1715]: [system] Activating via
systemd: service name='org.freedeskto>
apr 01 11:07:55 roadrunner.suse systemd-logind[1778]: Session 6 logged out.
Waiting for processes to exit.
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Unregistered Authentication
Agent for unix-session:4 (system bus >
apr 01 11:07:55 roadrunner.suse polkitd[1775]: Operator of unix-session:6
FAILED to authenticate to gain authori>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <info>  
[1554109675.9030] device (wlan1): supplicant inter>
apr 01 11:07:55 roadrunner.suse NetworkManager[1972]: <error>
[1554109675.9030] sup-iface[0x5613184bdc30,wlan1]:>
apr 01 11:07:55 roadrunner.suse systemd[2996]: Received SIGRTMIN+24 from PID
29233 (kill).

----end output-----

Now this forces you to a new boot in 50 % of the cases. Because wlan will not
reappear until new reboot (quite some user experiences this).
Also wallet seems not to collaborate with networkmanager cleanly. I am curious
to see if this will be  better in 15.1 and no, this is my production system so
beta testing is not possible for the data on it.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In reply to this post by Wolfgang Bauer
In data lunedì 1 aprile 2019 12:00:44 CEST, Wolfgang Bauer ha scritto:

> Am Montag, 1. April 2019, 10:16:38 schrieb Luca Beltrame:
> > In data domenica 31 marzo 2019 19:38:14 CEST, stakanov ha scritto:
> > > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > > amount of memory up to shutdown or unresponsiveness.
> >
> > That's totally unrelated. The indexer in Akonadi, although originally
> > derived from Baloo, uses Xapian and not lmdb (while Baloo the file indexer
> > does indeed use lmdb).
>
> Indeed.
> Although the mail indexer certainly has the *potential* to slow things down
> as well (in the past at least, should be much better nowadays of course).
>
> It can be uninstalled too though, it's the package akonadi-search. (indexed
> search and related features will of course cease to work then, but it may be
> worth a try as a temporary measure)
>
> It *may* be also worth a try to delete the search index, it may be in
> ~/.local/share/baloo/ (the sub folders *except* "file", which contains the
> file search index obviously), or ~/.local/share/akonadi/searchdb/.
> Which one is used depends on your system, akonadi-search reuses the first
> one if it exists (for "compatibility" with older versions), but creates the
> latter one if the first isn't there.
>
> I do remember discussions about problems after Xapian updates, where this
> "fixed" them, although IIRC that was mostly about crashes.
>
> And, that can only help if your problem is indeed related to *indexing* of
> course, not Akonadi itself.
>
> Kind Regards,
> Wolfgang
Thank you, I will try immediately, because that one drives me nuts.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Luca Beltrame
In reply to this post by Stakanov Schufter
In data lunedì 1 aprile 2019 12:04:47 CEST, stakanov ha scritto:

> This is interesting. With leap 15?

No, I forgot to mention I'm on TW (+ the KDE Unstable repos).

--
Luca Beltrame
GPG key ID: A29D259B

signature.asc (499 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In data lunedì 1 aprile 2019 12:06:58 CEST, Luca Beltrame ha scritto:
> In data lunedì 1 aprile 2019 12:04:47 CEST, stakanov ha scritto:
> > This is interesting. With leap 15?
>
> No, I forgot to mention I'm on TW (+ the KDE Unstable repos).
Ah, that explains it. Happy to hear that the future of leap will be brighter.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Wolfgang Bauer
In reply to this post by Stakanov Schufter
Am Sonntag, 31. März 2019, 23:58:03 schrieb stakanov:

> In data domenica 31 marzo 2019 22:59:05 CEST, Hans-Peter Jansen ha scritto:
> > Am Sonntag, 31. März 2019, 19:38:14 CEST schrieb stakanov:
> > > In data domenica 31 marzo 2019 18:05:32 CEST, Hans-Peter Jansen ha
>
> scritto:
> > > > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > > > hours
> > > > wall clock run time.
> > >
> > > Leap 15.0
> > > Bug 1100080
> > > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > > amount of memory up to shutdown or unresponsiveness.
> > > The bug is known to kde and it is linked to lmdb.
> > > While to TW it was cherrypicked and backported (there is a fix) the Leap
> > > 15
> > > version did not receive this blessing up to now.
> > > with mysql, the system does not complain always, only sometimes rarely
> > > konqi pops up after baloo crashed.
> >
> > Don't know, if that fits the bill.
> >
> > It's Tumbleweed, and if I'm reading your report correctly, the lmdb issue
> > is fixed here. Looks, like upstream found it even severe enough to create
> > new release, that is awaiting TW blessing, but a patch with a fix was
> > applied Oct 6, 2018.
> >
> > Next, it's the kernel, that stops akonadiserver, when it has eaten all
> > memory and swap. I don't let it swap, when I'm on, of course.
> >
> > The baloo processes behave, they use 256G VSZ, but only tiny amounts of
> > RSS, which is the painful part here.
> >
> > I need to stop now, and shutdown akonadi again, before the system becomes
> > sluggish and this mail wont get out...
> >
> > Cheers,
> > Pete
>
> You have my compassion. That problem must be fixed.

One bug report is here:
https://bugs.kde.org/show_bug.cgi?id=395131
(but I think I have seen other similar ones as well)

Of course it should be fixed, but one problem is that it certainly doesn't
happen in general, so it would need to be determined what exactly triggers
it...

JFTR, I don't see this on Leap 15.0 or 42.3 either, so it's probably not a
general problem with the mariadb versions used as one comment in that bug
report suggests (and my Akonadi databases are quite old, one even dates back
to KDEPIM 4.7, but that one actually uses an external MySQL/MariaDB database).

Kind Regards,
Wolfgang

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Wolfgang Bauer
In reply to this post by Stakanov Schufter
Am Montag, 1. April 2019, 12:06:11 schrieb stakanov:
> Thank you, I will try immediately, because that one drives me nuts.

That will of course not help for problems with baloo and/or lmdb though (I
only write this because you mentioned it in a previous mail... ;-) )

Kind Regards,
Wolfgang

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Stakanov Schufter
In reply to this post by Wolfgang Bauer
In data lunedì 1 aprile 2019 12:34:46 CEST, Wolfgang Bauer ha scritto:
> Am Sonntag, 31. März 2019, 23:58:03 schrieb stakanov:
> > In data domenica 31 marzo 2019 22:59:05 CEST, Hans-Peter Jansen ha
scritto:

> > > Am Sonntag, 31. März 2019, 19:38:14 CEST schrieb stakanov:
> > > > In data domenica 31 marzo 2019 18:05:32 CEST, Hans-Peter Jansen ha
> >
> > scritto:
> > > > > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about
> > > > > 5
> > > > > hours
> > > > > wall clock run time.
> > > >
> > > > Leap 15.0
> > > > Bug 1100080
> > > > Try to uninstall baloo indexer. When it crashes then kmail leaks huge
> > > > amount of memory up to shutdown or unresponsiveness.
> > > > The bug is known to kde and it is linked to lmdb.
> > > > While to TW it was cherrypicked and backported (there is a fix) the
> > > > Leap
> > > > 15
> > > > version did not receive this blessing up to now.
> > > > with mysql, the system does not complain always, only sometimes rarely
> > > > konqi pops up after baloo crashed.
> > >
> > > Don't know, if that fits the bill.
> > >
> > > It's Tumbleweed, and if I'm reading your report correctly, the lmdb
> > > issue
> > > is fixed here. Looks, like upstream found it even severe enough to
> > > create
> > > new release, that is awaiting TW blessing, but a patch with a fix was
> > > applied Oct 6, 2018.
> > >
> > > Next, it's the kernel, that stops akonadiserver, when it has eaten all
> > > memory and swap. I don't let it swap, when I'm on, of course.
> > >
> > > The baloo processes behave, they use 256G VSZ, but only tiny amounts of
> > > RSS, which is the painful part here.
> > >
> > > I need to stop now, and shutdown akonadi again, before the system
> > > becomes
> > > sluggish and this mail wont get out...
> > >
> > > Cheers,
> > > Pete
> >
> > You have my compassion. That problem must be fixed.
>
> One bug report is here:
> https://bugs.kde.org/show_bug.cgi?id=395131
> (but I think I have seen other similar ones as well)
>
> Of course it should be fixed, but one problem is that it certainly doesn't
> happen in general, so it would need to be determined what exactly triggers
> it...
>
> JFTR, I don't see this on Leap 15.0 or 42.3 either, so it's probably not a
> general problem with the mariadb versions used as one comment in that bug
> report suggests (and my Akonadi databases are quite old, one even dates back
> to KDEPIM 4.7, but that one actually uses an external MySQL/MariaDB
> database).
>
> Kind Regards,
> Wolfgang
Thanks for the tips. The overall systemcharge is now a bit lower. Baloo does
not crash as often. Akonadi still does leak memory in Leap15 to a large
amount. If you find the reason for this in TW you may consider backporting it
at least to the 15.1 KDE version of leap (whatever that will be) because a
productive use with no memory after 5 to 6 hours (about 6 GB only for akonadi)
is not really possible.
However once done the whole show (exit kontact, stop akonadi, kill eventual
zombi processes and korgac, then restart, the problem is less severe as
before. Still it happens as described before. Spam filter pops up and ask to
attribute the filter to an empty list etc.).
That does not want to be a rant but a feedback on the actions advised to be
clear.
Kind regards and thank you.




_________________________________________________________________
________________________________________________________
Ihre E-Mail-Postfächer sicher & zentral an einem Ort. Jetzt wechseln und alte E-Mail-Adresse mitnehmen! https://www.eclipso.de


--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: akonadiserver and kmail are leaking memory

Wolfgang Bauer
Am Dienstag, 2. April 2019, 11:10:10 schrieb stakanov:
> If you find the reason for this in TW you may consider backporting
> it at least to the 15.1 KDE version of leap (whatever that will be)

JFYI, Leap 15.1 will come with the currently latest upstream versions of
Akonadi/KDEPIM, i.e. 18.12.3, which is the same as Tumbleweed has at the
moment.

Kind Regards,
Wolfgang

--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

Reply | Threaded
Open this post in threaded view
|

Re: [Solved] akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
In reply to this post by Wolfgang Bauer
Am Montag, 1. April 2019, 11:51:39 CEST schrieb Wolfgang Bauer:

> Am Sonntag, 31. März 2019, 22:40:41 schrieb Hans-Peter Jansen:
> > Am Sonntag, 31. März 2019, 19:02:02 CEST schrieb Knurpht-openSUSE:
> > > Op zondag 31 maart 2019 18:05:32 CEST schreef Hans-Peter Jansen:
> > > > Yes, that reads 41G VSZ and 27G RSS for akondiserver, only in about 5
> > > > hours
> > > > wall clock run time.
> > >
> > > I've experienced this in the early days, the solution was to rebuild the
> > > akonadi database.
> >
> > Been there, done that, same result. In fact, the whole indexing failed
> > much
> > more miserable before I tuned the mysql config to some degree, due to
> > timeouts (which is okay, given my admittedly pathologic case).
>
> > Will try Postgres, then.

Done that now, and guess what, switching to Postgres really made a difference!

Not only memory-wise, but also performance-wise. I never found kmail opening/
switching huge folders that fast.. (and no other MUA, that I tested,

To conclude: akonadiserver, using MySQL suffers from memory leaks in some
error paths, and since anybody with higher akonadi demands seems to switch to
Postgres anyway, these issues are flying under the radar.

If somebody has more any pointers for tips to tune Postgres for akonadi any
further, that would be great, since the defaults seem to be very conservative.

Thanks, Wolfgang for your helpful support. It is much appreciated.

Cheers,
Pete



--
To unsubscribe, e-mail: [hidden email]
To contact the owner, e-mail: [hidden email]

12