muadib2000 hat geschrieben:Ich dachte das ginge aus meinem Beitrag bereits hervor. Ich würde in der Datei: class.sql.inc.php mysql_pconnect:
Das steht ja auch so im Wiki
muadib2000 hat geschrieben:Wenn man bei seinem Server Root-Zugriff hat oder seinen Hoster überzeugen kann, sollte man (wenn nicht schon geschehen) in der Datei my.cnf im Ordner mysql\bin unter "skip-innodb" folgenden Eintrag hinzufügen bzw. die Auskommentierung entferenen.
Code: Alles auswählen
skip-innodb
# Uncomment the following if you are using InnoDB tables
set-variable = interactive_timeout=30
Die Zahl gibt übrigens die Sekunden bis zum Timeout an. Außerdem kann es zu Problemen kommen wenn die Zahl der persistenten Verbindungen begrenzt ist, es sollte also idealer Weise keine Beschränkungen in dieser Hinsicht geben.
Das meinte ich.
Allerdings sieht das bei mir in der /etc/mysql/my.cnf (Debian Sarge System) anders aus. Dort gibt es diese Zeile gar nicht.
Bei mir würde der Eintrag so aussehen müssen:
Per Default steht dieser Wert bei mir auf 28800 Sekunden!
ABER, das kann man auch mit Redaxo eigenen Mitteln erreichen
Du hast mich da auf eine Idee gebracht. Folgendes ist Sache:
Bei der MySQL-Variable
interactive_timeout handelt es sich um eine Variable, welche auch zur Laufzeit geändert werden kann.
Daraus folgt, das lediglich eine einzige Zeile in der
classes/class.sql.inc.php hinzugefügt werden muss:
Code: Alles auswählen
// MySQL Version bestimmen
if ($REX['MYSQL_VERSION'] == '')
{
$this->setQuery('SET interactive_timeout = 30');
$this->setQuery('SELECT VERSION() as VERSION');
...
SET interactive_timeout = 30 setzt den Wert wärend der Laufzeit auf
30
Ein ähnliches Problem gibt es bei bei der Verwendung von MySQL5 mit der MySQL-Variablen
sql_mode (siehe
FAQ).
PS: Ein entsprechender Wiki-Eintrag folgt später.
[EDIT]
Nachtrag: Wie ich gerade feststellen musste, hat diese Einstellung aber keinen Einfluss auf die schlafenden Prozesse
Bei meinen Tests wurden bis zu 7 Prozesse gestartet und keiner wurde nach dem Ablauf des Timeout sofort wieder beendet. Einige wurden dann aber auch "wiederverwendet". D.h., das die ProzessID die gleiche blieb (auch nach dem Timeout).
Am Ende ist die Sache mit dem pconnect wohl sehr von der Systemumgebung der DB und einem gewissen Finetuning bei entsprechend belasteten Servern abhängig.
Somit könnte man sagen das pconnect eine gute Wahl bei entprechender Systemumgebung ist und man bei den ersten Anzeichen von Problemen (wie z.B. keine
Verbindung mehr zu DB) besser auf connect umstellen sollte.