enterprise_refresh_index Sleeping MySQL Connection

8

Il y a des moments où l'indexeur qui est exécuté par cron semble être bloqué sur MySQL car les connexions Sleeping peuvent être vues. L'indexeur fonctionne pendant plusieurs heures et cela ne fonctionne pas du tout. J'ai recherché ceci mais je n'ai trouvé aucun lien. Quelqu'un qui peut faire la lumière? Peut-être configuration du serveur ou bug Magento?

— user1240207
source

0

Utilisez-vous des connexions persistantes? Combien de connexions de sommeil avez-vous? Quelle est la quantité maximale de connexions que votre serveur DB est configuré pour autoriser?

Pour vérifier le nombre de connexions de veille que vous venez d'exécuter:

show full processlist;

Pour voir l'exécution de max_connections:

show variables like 'max_connections';

Je pense que les connexions en veille ne sont pas le problème, mysqld va expirer les connexions en veille basées sur 2 valeurs:

interactive_timeout wait_timetout

Les deux durent 28800 secondes (8 heures) par défaut.

Vous pouvez définir ces options dans my.cnf (l'emplacement de ce fichier est différent dans différents systèmes d'exploitation et bases de données, percona, mysql, etc.)

Consultez également cette réponse des administrateurs de base de données: https://dba.stackexchange.com/a/1559 et si vous souhaitez en savoir plus sur la façon de déboguer l'origine des connexions en veille, consultez cet excellent article: https: // www. percona.com/blog/2007/02/08/debugging-sleeping-connections-with-mysql/

"Si vos connexions sont persistantes (ouvertes via mysql_pconnect), vous pouvez réduire ces nombres à quelque chose de raisonnable comme 600 (10 min) ou même 60 (1 min). Ou, si votre application fonctionne très bien, vous pouvez laisser la valeur par défaut. C'est dépend de vous."

Essayez d'exécuter l'indexeur à partir de la console pour voir s'il génère une erreur:

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

— lloiacono
source

Malheureusement, nous obtenons toujours ce problème. J'exécute la commande show full process et elle affiche une très longue instruction SQL avec les ID d'entité répertoriés.

— user1240207

0

configurer votre serveur mysql en définissant un délai d'expiration plus court wait_timeoutetinteractive_timeout

mysql> afficher des variables comme "%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)

Fixé avec:

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

(et également défini dans votre fichier de configuration, pour le redémarrage de votre serveur)

Mais vous traitez les symptômes plutôt que la cause sous-jacente - pourquoi les connexions sont-elles ouvertes? Si le script PHP est terminé, ne devraient-ils pas se fermer? Assurez-vous que votre serveur Web n'utilise pas le pool de connexions ...

— Charlie
source