Du bist nicht angemeldet. Der Zugriff auf einige Boards wurde daher deaktiviert.

#1 21. Mai 2012 12:06

piratos
arbeitet mit CMS/ms
Registriert: 12. August 2011
Beiträge: 545

Mysql max_connection

Wer ein CMS intensiv nutzt der sollte mal die Anzahl von max_connections überprüfen.

In der Standardeinstellung sind es normal 151 - es kann jedoch sein, das ein Provider davon abweicht.

Aber 151 können u.U. bei einer gut besuchten Site und einem System das zahlreiche Zugriffe ausführt und somit relativ lange eine Verbindung offen hält zu wenig sein.

Meine Empfehlung einen Wert zwischen 300 und 500 ausprobieren.

Test unter PMA

show variables like "max_connections";

setzen

set global max_connections = 300;

Es kann manchmal sein das ein Provider das Setzen unterbunden hat.

Werden die connections knapp, dann arbeitet Mysql solange wie im Rahmen von vor gesetzten internen timeouts noch fertig gewordene Abfragen ausgeführt werden und dann noch eine Verbindung frei wird.

Ansonsten wird je nach Server und Einstellung ein false oder ein Abpfiff zurück geliefert.
Auf jeden Fall wird es dann gemütlich langsam.

Offline

#2 22. Mai 2012 10:51

piratos
arbeitet mit CMS/ms
Registriert: 12. August 2011
Beiträge: 545

Re: Mysql max_connection

Hier mal zur Ergänzung der Ausführung einen Auzug mit debug und gleichzeitig mit dem Mysql Profiler

Debug: (0.170307) - (usage: 5785880) - (peak: 5908184)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (34,19,24) AND active = 1
Debug: (0.17141) - (usage: 5876272) - (peak: 5975672)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (36,37,29,30,46,45,38,47)
Debug: (0.174712) - (usage: 6116944) - (peak: 6230200)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (49,13,22,16,18,44,55)
Debug: (0.177514) - (usage: 6324944) - (peak: 6437104)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (54,51,52)
Debug: (0.179106) - (usage: 6415936) - (peak: 6526456)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (20,25)
Debug: (0.180201) - (usage: 6474160) - (peak: 6584992)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (39,40,41,42,43,50)
Debug: (0.182671) - (usage: 6654744) - (peak: 6763728)
(mysql): SELECT * FROM cms_content  FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (26,28)

Mysql Profiler

11    0.00008425    SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (54,51,52)
12    0.00008475    SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (20,25)
13    0.00008250    SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (39,40,41,42,43,50)
14    0.00008425    SELECT * FROM cms_content FORCE INDEX (cms_index_content_by_hierarchy) WHERE content_id IN (26,28)

Das FORCE INDEX stammt von mir ist hier unwichtig.

Wichtig ist hier das man klar erkennen kann, das mehr als nur eine DB Verbindung aktiv ist
Wir haben mehr als eine DB Verbindung, da wir tatsächlich mehr Abfragen haben, als der Profiler anzeigt.

Was man auch schön erkennen kann der zeitliche PHP Aufwand zwischen den Abfragen  ist im Vergleich zu den reinen Mysql Zeiten extrem hoch.

FORCE INDEX bei den eigentlichen Abfragen ist bis zu 10 x schneller.

Beitrag geändert von piratos (22. Mai 2012 10:53)

Offline