akonadiserver and kmail are leaking memory

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

Re: [Solved] akonadiserver and kmail are leaking memory

Stakanov Schufter
In data domenica 7 aprile 2019 15:31:33 CEST, Hans-Peter Jansen ha scritto:

> 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
On that  behalf, I found it uttermost difficult to get clear(!) indications
about save practices and their implications with postgres, when using kmail/
akonadi locally.
This is substantially the main reason why I switched back to Mysql.
It was not clear to me with what policy I would have guaranteed a safe
postgres installation for only local use with akonadi.
Some say: set a password, some don't.
So, what did you choose on that behalf, if I might ask. (Sorry if this is
invasive, you may also point to a link describing a/the procedure or pros/
cons.
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: [Solved] akonadiserver and kmail are leaking memory

Hans-Peter Jansen-2
Am Sonntag, 7. April 2019, 16:40:00 CEST schrieb stakanov:

> In data domenica 7 aprile 2019 15:31:33 CEST, Hans-Peter Jansen ha scritto:
> > 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:
> > >
> > > > 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,

... is on the same street with kmail anyway. Again, with huge mailboxes!

> On that  behalf, I found it uttermost difficult to get clear(!) indications
> about save practices and their implications with postgres, when using kmail/
> akonadi locally.

Well, here we go:

# switch to postgres
root$ zyp in postgresql-server libQt5Sql5-postgresql

akonadictl stop
#stop all akonadi users
psg 'kmail|akonadi|mysql'
#kill akonadi mysql server instance

cat > .config/akonadi/akonadiserverrc << EOF
[Debug]
Tracer=null

[%General]
Driver=QPSQL

[PSQL]
StartServer=true
Name=akonadi
EOF

rm -r .local/share/akonadi
akonadictl start

# postgres update
https://userbase.kde.org/Akonadi/Postgres_update

> This is substantially the main reason why I switched back to Mysql.
> It was not clear to me with what policy I would have guaranteed a safe
> postgres installation for only local use with akonadi.
> Some say: set a password, some don't.

Using that procedure results in:

cat ~/.local/share/akonadi/db_data/pg_hba.conf

# "local" is for Unix domain socket connections only
local   all             all                                     trust
# IPv4 local connections:
host    all             all             127.0.0.1/32            trust
# IPv6 local connections:
host    all             all             ::1/128                 trust
# Allow replication connections from localhost, by a user with the
# replication privilege.
local   replication     all                                     trust
host    replication     all             127.0.0.1/32            trust
host    replication     all             ::1/128                 trust

At least on TW. If somebody is able to access your database on localhost or
unix domain sockets, you're busted anyway.

So, what you should care about are major Postgres upgrades: it comes down to
installing both versions, and manually upgrade the database, which also means,
that you need enough space for both versions temporarily.

Cheers,
Pete


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

12