Comment résoudre l'avertissement mysql: "MyISAM: page_cleaner: la boucle prévue de 1000ms a pris XXX ms. Les paramètres peuvent ne pas être optimaux "?
J'ai couru un import mysql mysql dummyctrad < dumpfile.sql sur le serveur et sa prend trop de temps pour terminer. Le fichier de vidage est d'environ 5G. Le serveur est un Centos 6, de la mémoire=16G et 8core processeurs, mysql v 5.7 x64-
Sont normales des messages et/ou le statut "en attente d'un tableau de chasse" et le message MyISAM: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal
mysql le contenu des journaux
2016-12-13T10:51:39.909382Z 0 [Note] MyISAM: page_cleaner: 1000ms intended loop took 4013ms. The settings might not be optimal. (flushed=1438 and evicted=0, during the time.)
2016-12-13T10:53:01.170388Z 0 [Note] MyISAM: page_cleaner: 1000ms intended loop took 4055ms. The settings might not be optimal. (flushed=1412 and evicted=0, during the time.)
2016-12-13T11:07:11.728812Z 0 [Note] MyISAM: page_cleaner: 1000ms intended loop took 4008ms. The settings might not be optimal. (flushed=1414 and evicted=0, during the time.)
2016-12-13T11:39:54.257618Z 3274915 [Note] Aborted connection 3274915 to db: 'dummyctrad' user: 'root' host: 'localhost' (Got an error writing communication packets)
Processlist:
mysql> show processlist \G;
*************************** 1. row ***************************
Id: 3273081
User: root
Host: localhost
db: dummyctrad
Command: Field List
Time: 7580
State: Waiting for table flush
Info:
*************************** 2. row ***************************
Id: 3274915
User: root
Host: localhost
db: dummyctrad
Command: Query
Time: 2
State: update
Info: INSERT INTO `radacct` VALUES (351318325,'kxid ge:7186','abcxyz5976c','user100
*************************** 3. row ***************************
Id: 3291591
User: root
Host: localhost
db: NULL
Command: Query
Time: 0
State: starting
Info: show processlist
*************************** 4. row ***************************
Id: 3291657
User: remoteuser
Host: portal.example.com:32800
db: ctradius
Command: Sleep
Time: 2
State:
Info: NULL
4 rows in set (0.00 sec)
Mise à jour-1
mysqlforum ,innodb_lru_scan_depth
changer innodb_lru_scan_depth valeur de 256 ont amélioré le temps d'exécution des requêtes de type insert + pas de message d'avertissement dans le journal, le défaut était innodb_lru_scan_depth=1024;
SET GLOBAL innodb_lru_scan_depth=256;
source d'informationauteur satch_boogie | 2016-12-14
Vous devez vous connecter pour publier un commentaire.
Le problème est typique d'une instance MySQL où vous avez un taux élevé de changements à la base de données. En exécutant vos 5 GO d'importation, vous êtes en train de créer les pages sale rapidement. En tant que sale pages sont créées, la page cleaner thread est responsable de la copie de pages sale de la mémoire vers le disque.
Dans votre cas, je suppose que vous ne faites pas de 5 go importations de tous les temps. C'est donc un taux exceptionnellement élevé de chargement des données, et ce n'est que temporaire. Vous pouvez probablement ignorer les avertissements, parce que MyISAM va progressivement rattraper.
Voici une explication détaillée de la structure interne menant à cet avertissement.
Une fois par seconde, la page cleaner scanne le pool de mémoire tampon pour les pages sale pour vider à partir du pool de mémoire tampon sur le disque. L'avertissement que vous avez vu montre qu'il y a beaucoup de pages sale de chasse d'eau, et il faut plus de 4 secondes pour rincer un lot de disque, lorsqu'il complète ce travail en moins de 1 seconde. En d'autres termes, c'est en mordant plus qu'il ne peut mâcher.
Vous avez ajusté en réduisant
innodb_lru_scan_depth
de 1024 à 256. Cela réduit dans le pool de mémoire tampon de la page cleaner fil des recherches pour les pages sale lors de sa fois-par-deuxième cycle. Vous êtes en lui demandant de prendre de plus petites bouchées.Notez que si vous avez beaucoup de pool de mémoire tampon cas, il va causer des bouffées de chaleur pour faire plus de travail. Il mord
innodb_lru_scan_depth
quantité de travail pour chaque pool de mémoire tampon de l'instance. De sorte que vous pourriez avoir involontairement causé ce problème en augmentant le nombre de pools de mémoire tampon, sans diminuer la profondeur de numérisation.La documentation pour
innodb_lru_scan_depth
dit "Un réglage plus petit que la valeur par défaut est généralement approprié pour la plupart des charges de travail." Il sonne comme ils ont donné à cette option, une valeur trop élevée par défaut.Vous pouvez placer une limite sur les IOPS utilisé par le fond de rinçage, avec la
innodb_io_capacity
etinnodb_io_capacity_max
options. La première option est une limite sur le débit d'e/S MyISAM demande. Mais cette limite est souple; si le rinçage est en retard par rapport aux taux de sale création de page, MyISAM va augmenter dynamiquement rinçage taux au-delà de cette limite. La deuxième option définit les limites plus strictes sur la façon dont la mesure MyISAM peut augmenter le taux de rinçage.Si le taux de rinçage peut maintenir le taux moyen de créer de nouvelles pages sale, alors vous serez d'accord. Mais si vous créez constamment sale des pages plus rapide qu'ils peuvent être rincés, éventuellement votre pool de mémoire tampon se remplit avec les pages sale, jusqu'à ce que les pages sale dépasse
innodb_max_dirty_page_pct
du pool de mémoire tampon. À ce stade, le rinçage taux augmentera automatiquement, et peut encore causer la page_cleaner à envoyer des avertissements.Une autre solution serait de mettre MySQL sur un serveur avec des disques plus rapides. Vous avez besoin d'un système d'e/S qui peuvent gérer le débit exigé par votre page de rinçage.
Si vous voyez cet avertissement tout le temps en dessous de la moyenne de la circulation, vous pouvez essayer d'en faire trop écrire des requêtes sur ce serveur MySQL. Il serait peut-être temps de mettre à l'échelle, et de diviser l'écrit sur plusieurs MySQL, chacune avec leur propre système de disque.
Lire plus sur la page cleaner: https://blogs.oracle.com/mysqlinnodb/entry/introducing_page_cleaner_thread_in
Le goulot d'étranglement est l'enregistrement de données sur le disque dur. Quel disque dur vous avez: SSD, normal, NVMe etc.
Noter que cette solution s'applique principalement à MyISAM
J'ai eu le même problème, j'ai appliqué quelques solutions.
1er: la vérification de ce qui est mauvais
atop -d
va vous montrer l'utilisation du disque. Si le disque est "occupé", puis essayez d'arrêter toutes les requêtes de base de données (mais ne pas arrêter le serveur mysql de service!)De surveiller la façon dont beaucoup de questions que vous avez, utilisez mytop, innotop ou l'équivalent.
Si vous avez 0 de requêtes, mais l'utilisation du disque est à 100% à partir de quelques secondes à quelques minutes, puis c'est à dire que le serveur mysql est d'essayer de vider sale pages /faire un peu de ménage comme mentionné avant (après la grande-du projet de Loi Karwin).
ALORS vous pouvez essayer d'appliquer ces solutions:
2e: matériel d'optimisation
Si votre table n'est pas en RAID 1+0 envisager de doubler la vitesse de l'enregistrement des données à l'aide de ce type de solution. Essayez d'étendre votre disque dur cotroller possibilités à l'écriture de données. Essayez d'utiliser des disques SSD ou disque dur plus rapide. L'application de cette soultion dépend de votre matériel et le budget de possibilités et peuvent varier.
3e: logiciel de paramétrage
Si harware cotroller fonctionne très bien, mais vous voulez prolonger la vitesse de l'enregistrement de données vous pouvez configurer dans le fichier de configuration de mysql:
3.1.
innodb_flush_log_at_trx_commit = 2
-> si vous/re à l'aide de tables innodbIl travaille à former mon experisnce le meilleur avec un tableau pour chaque fichier:
innodb_file_per_table = 1
3.2.
continue avec MyISAM:
innodb_flush_method = O_DIRECT
innodb_doublewrite = 0
innodb_support_xa = 0
innodb_checksums = 0
Lignes ci-dessus sont en général de réduire la quantité de données nécessaires pour être enregistré dans le disque dur, de sorte que la performance est plus grande.
3.3
general_log = 0
slow_query_log = 0
Lignes au-dessus de désactiver l'enregistrement des journaux, bien sûr, il est encore une autre quantité de données enregistrées sur le disque dur
3.4
vérifier à nouveau ce qui se passe usit par exemple
tail-f /var/log/mysql/erreur.journal
4ème: remarques générales
Remarques générales:
Cela a été testé sous MySQL 5.6 ET 5.7.22
OS: Debian 9
RAID 1 + 0 disques durs SSD
Base de données: tables MyISAM
innodb_buffer_pool_size = 120G
innodb_buffer_pool_instances = 8
innodb_read_io_threads = 64
innodb_write_io_threads = 64
Quantité totale de mémoire RAM du serveur: 200GO
Après avoir fait cela, vous pouvez observer le plus élevé d'utilisation de l'UC; c'est normal, parce que l'écriture des données est plus rapide, alors le CPU à travailler plus fort.
Si vous faites cela à l'aide de mon.cnf bien sûr, n'oubliez pas de redémarrer le serveur MySQL.
5e supplément
Étant intrigué, j'ai fait ce caprice
SET GLOBAL innodb_lru_scan_depth=256;
mentionnés ci-dessus.
De travail avec de grandes tables, je n'ai pas vu de changement dans la performance.
Après les corrections ci-dessus je n'ai pas à me débarrasser de mises en garde, cependant tout le système de travail est nettement plus rapide.
Tout ce qui précède n'est qu'une expérimentation, mais j'ai mesuré les résultats, il m'a aidé un peu, alors j'espère qu'il peut être utile pour les autres.