Kayako is creating 1000's of mySQL processes

[Tamarind]

Kayako is creating 1000's of mySQL processes that is crashing server....Any Ideas???

----------------------------------

| 137709 | websupp_esuppor | localhost | websupp_esupport | Sleep | 2091 | | |
| 137721 | websupp_esuppor | localhost | websupp_esupport | Sleep | 38 | | |
| 137784 | websupp_esuppor | localhost | websupp_esupport | Sleep | 730 | | |
| 137796 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1358 | | |
| 137801 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1963 | | |
| 137804 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1621 | | |
| 137817 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1967 | | |
| 137842 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1772 | | |
| 137854 | websupp_esuppor | localhost | websupp_esupport | Sleep | 362 | | |
| 137894 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1551 | | |
| 137926 | websupp_esuppor | localhost | websupp_esupport | Sleep | 729 | | |
| 138187 | websupp_esuppor | localhost | websupp_esupport | Sleep | 2087 | | |
| 138287 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1626 | | |
| 138343 | websupp_esuppor | localhost | websupp_esupport | Sleep | 889 | | |
| 138347 | websupp_esuppor | localhost | websupp_esupport | Sleep | 5635 | | |
| 138622 | websupp_esuppor | localhost | websupp_esupport | Sleep | 1582 | | |
| 138654 | websupp_esuppor | localhost | websupp_esupport | Sleep | 392 | | |
| 138923 | websupp_esuppor | localhost | websupp_esupport | Sleep | 414 | | |
| 139038 | websupp_esuppor | localhost | websupp_esupport | Sleep | 2932 | | |
| 139462 | websupp_esuppor | localhost | websupp_esupport | Sleep | 6 | | |
| 139487 | websupp_esuppor | localhost | websupp_esupport | Sleep | 905 | | |
| 139559 | websupp_esuppor | localhost | websupp_esupport | Sleep | 2121 | | |
| 139561 | websupp_esuppor | localhost | websupp_esupport | Sleep | 2721 | | |
| 139601 | websupp_esuppor | localhost | websupp_esupport | Sleep | 302 | | |

[sergioag]

Hi

WHat version of MySQL are you using? Are you using persistent connections?

Sergio Aguayo

[John Haugeland]

This almost certainly means that PHP is aborting on a repeat basis (probably during cron), and your MySQL instance is using the default dead connection cleanup time (eight hours).

Strongly suggest you update your my.cnf/my.ini MYSQL_OPT_CONNECT_TIMEOUT setting to a more appropriate value (my servers use 900, which is 15 minutes measured in seconds). Also, it may be appropriate for you to find the reason PHP is crashing, which is typically due to out of memory concerns, max post size or mysql's packet max size.

If you would like, you're welcome of course to open a ticket with the support staff.

[dotboost]

Originally Posted by John Haugeland

This almost certainly means that PHP is aborting on a repeat basis (probably during cron), and your MySQL instance is using the default dead connection cleanup time (eight hours).

Strongly suggest you update your my.cnf/my.ini MYSQL_OPT_CONNECT_TIMEOUT setting to a more appropriate value (my servers use 900, which is 15 minutes measured in seconds). Also, it may be appropriate for you to find the reason PHP is crashing, which is typically due to out of memory concerns, max post size or mysql's packet max size.

If you would like, you're welcome of course to open a ticket with the support staff.

I have the exactly the same issue with 3 servers where i have kayako's installations. I modified the MYSQL_OPT_CONNECT_TIMEOUT to 1200 on one servers and is ok on that machine.
Anyway, the issue occur only on 3.20.02, previous versions was fine on same servers with exact the same server configuration.
I am sure is something in kayako, but well, will see the next versions...

[John Haugeland]

Originally Posted by dotboost

I am sure is something in kayako, but well, will see the next versions...

I really hope you'll open a support ticket. Every time I've seen this, it's been a question of the several possibilities I already listed.

We can probably fix this if you'll give it a chance.

[dotboost]

ticket ICC-633800
from 26 Mar 2008
i know the issue is somewhere else then the 'server misconfiguration'

[Chris Boulton]

While we're on the topic - is SupportSuite using mysql_pconnect or just mysql_connect? From what we've seen, it seems to be mysql_pconnect.

(Don't feel like violating our license agreement just to check swift.php )

[dotboost]

i use esupport, and i don't know what is using: pconnect or connect , the files related to DB connections are encoded ....

[craigbrass]

Don't feel like violating our license agreement just to check swift.php

Hehe, hardly enforceable. *winks*

[Jamie Edwards]

Originally Posted by craigbrass

Hehe, hardly enforceable. *winks*

Actually, we would like to think so.

We also will 'enforce' against encouraging others to break their agreement here on the forums, with an infraction or ban. Comments like this on our own forum are not only rude, but completely unacceptable .

[craigbrass]

How was that an encouragement or rude?

What I said there was simply that it couldn't be proved that it had been done.

[Ryan Lederman]

It will use mysql_connect() or mysql_pconnect() depending on the value of this line in config/config.php (line 50 in 3.30.x):

define("P_CONNECT", false);

So, by default it is using mysql_connect() (non-persistent connections)

[John Haugeland]

This is very clearly an issue of a misconfigured MYSQL_OPT_CONNECT_TIMEOUT. Stopping this is the entire purpose of that setting.

[dotboost]

Originally Posted by John Haugeland

This is very clearly an issue of a misconfigured MYSQL_OPT_CONNECT_TIMEOUT. Stopping this is the entire purpose of that setting.

Is a clean and default installation of Centos 4.4 with Plesk 8.6.0 , so no extra configuration was made.
That's why i don't understand why i need to add extra configuration to the server in order to prevent such multiple connections.

[John Haugeland]

Because MySQL is set up by default in lots of ways which aren't appropriate for web applications. This is the same reason you have to set your max_packet_size and a variety of other MySQL defaults.

The default configuration is meant for datacenters. Datacenter requirements are very different than web application requirements. If one size fit all, the configuration wouldn't need to be there.