Kopano is using up all mysql connections ?

[jengelh]

There is no SQL connection pooling at present (ZCP just did not do it and it has not changed since); each thread keeps its own connection state. You can look at the thread list with utilities like htop, gdb, or stabbing in /proc/N/task manually.

[crankshaft]

Is there a fix in the pipeline for this problem ??

[fbartels]

yes, see the post I linked you to in my first reply.

[crankshaft]

Thanks, but I already checked that post, there does not appear to be any fix for this yet ?

[fbartels]

@crankshaft not, a public one. but there was a pull request linked which will be part of the next Kopano release. We are currently busy doing last tests and if no errors are found there will be a release probably next week.

[crankshaft]

Understood, thanks

[fbartels]

Hi @crankshaft,

8.7.13 is now available in the pre-final download directory. Your feedback would be appreciated.

See https://forum.kopano.io/topic/3215/kopano-core-8-7-13-pre-final for more information.

[crankshaft]

Thanks, but I have only ever installed and updated using debian apt update and there are no updates showing right now ?

[xthbx]

@crankshaft you probably used the repositorie https://kb.kopano.io/display/WIKI/1.+Core

you need to change

#Core
deb https://serial:<INSERT_SERIALKEY>@download.kopano.io/supported/core:/final/xxx/ ./

to

#Core
deb https://serial:<INSERT_SERIALKEY>@download.kopano.io/supported/core:/pre-final/xxx/ ./

[crankshaft]

@xthbx said in Kopano is using up all mysql connections ?:

deb https://serial:<INSERT_SERIALKEY>@download.kopano.io/supported/core:/final/xxx/ ./

Thanks, I forgot about that, long time since I installed it, I have added the repo and will test later after taking a snapshot of the server first.

[crankshaft]

The upgrade was successful and at the moment there are 13 processes open, and I saw a new process start and stop again, which I dont recall noticing before.

But it will have to run for a day before I can see if there’s any real difference.

[crankshaft]

There is still 38 (the default mysql max) connections to mysql and given that we only have 5 users and today nobody is accessing emails, I am surprised there are so many active connections.

Why not implement proper mysql connection pooling and have an option to set the pool size, so that the threads can share the connection pool ?

This seems to be a better approach than all of these open connections which are sleeping 99% of the time ?

[xthbx]

i also don’t understand what changed from 8.7.9 to 8.7.1x

[jengelh]

@crankshaft said in Kopano is using up all mysql connections ?:

Why not implement proper mysql connection pooling and have an option to set the pool size, so that the threads can share the connection pool ?

At worst, every thread (some number N) will have work to do, and then you need N connections anyway, whether you use the current static (thread-private on-first-use) approach or a (shared) pool.

Running with a conn pool smaller than that would mean requests to kopano-server via the SOAP-HTTP interface would have to block waiting for a free SQL connection, at which point you could just reduce the threadcount with the same effect.