Enterprise_refresh_index Ruhende MySQL-Verbindung

8

Es gibt Zeiten, in denen der von cron ausgeführte Indexer an MySQL hängen zu bleiben scheint, da schlafende Verbindungen sichtbar werden. Der Indexer läuft mehrere Stunden und dieser läuft eigentlich gar nicht. Ich habe danach gesucht, aber ich konnte keine verwandten finden. Wer kann Licht ins Dunkel bringen? Möglicherweise Serverkonfiguration oder Magento-Fehler?

— user1240207
quelle

0

Verwenden Sie dauerhafte Verbindungen? Wie viele Schlafverbindungen haben Sie? Wie viele Verbindungen kann Ihr DB Server maximal zulassen?

So überprüfen Sie, wie viele Schlafverbindungen Sie gerade ausgeführt haben:

show full processlist;

So sehen Sie die Ausführung von max_connections:

show variables like 'max_connections';

Ich denke, dass die Schlafverbindungen nicht das Problem sind, mysqld wird Schlafverbindungen basierend auf 2 Werten zeitlich festlegen:

interaktives_Zeitlimit wait_timetout

Beide sind standardmäßig 28800 Sekunden (8 Stunden).

Sie können diese Optionen in my.cnf festlegen (der Speicherort dieser Datei ist in verschiedenen Betriebssystemen und DBs, Percona, MySQL usw. unterschiedlich).

Lesen Sie auch diese Antwort von Datenbankadministratoren: https://dba.stackexchange.com/a/1559. Wenn Sie mehr darüber erfahren möchten, wie Sie den Ursprung der Schlafverbindungen debuggen können, lesen Sie diesen hervorragenden Artikel: https: // www. percona.com/blog/2007/02/08/debugging-sleeping-connections-with-mysql/

"Wenn Ihre Verbindungen dauerhaft sind (über mysql_pconnect geöffnet), können Sie diese Zahlen auf einen vernünftigen Wert wie 600 (10 Minuten) oder sogar 60 (1 Minute) senken. Wenn Ihre App einwandfrei funktioniert, können Sie die Standardeinstellung beibehalten wie du willst."

Versuchen Sie, den Indexer über die Konsole auszuführen, um festzustellen, ob ein Fehler ausgegeben wird:

php shell/indexer info # this will output the list of indexes then
php shell/indexer --reindex {index_name}

— lloiacono
quelle

Leider bekommen wir dieses Problem immer noch. Ich führe den Befehl show full process aus und er zeigt sehr lange SQL-Anweisungen mit aufgelisteten Entitäts-IDs an.

— user1240207

0

Konfigurieren Sie Ihren MySQL-Server, indem Sie ein kürzeres Timeout für wait_timeoutund festlegeninteractive_timeout

mysql> zeige Variablen wie "%timeout%";

+--------------------------+-------+
| Variable_name            | Value |
+--------------------------+-------+
| connect_timeout          | 5     |
| delayed_insert_timeout   | 300   |
| innodb_lock_wait_timeout | 50    |
| interactive_timeout      | 28800 |
| net_read_timeout         | 30    |
| net_write_timeout        | 60    |
| slave_net_timeout        | 3600  |
| table_lock_wait_timeout  | 50    |
| wait_timeout             | 28800 |
+--------------------------+-------+
9 rows in set (0.00 sec)

Set mit:

set global wait_timeout=3;
set global interactive_timeout=3;

(und auch in Ihrer Konfigurationsdatei festgelegt, wenn Ihr Server neu gestartet wird)

Aber Sie behandeln die Symptome anstelle der zugrunde liegenden Ursache - warum sind die Verbindungen offen? Wenn das PHP-Skript fertig ist, sollten sie dann nicht geschlossen werden? Stellen Sie sicher, dass Ihr Webserver kein Verbindungspooling verwendet ...

— Charlie
quelle