MySQL utilisation élevée de l'UC

Récemment, mon PROCESSEUR du serveur a été très élevé.

Charge CPU moyennes 13.91 (1 min), à 11,72 (5 minutes) 8.01 (15 minutes) et mon site n'a eu qu'une légère augmentation du trafic.

Après l'exécution d'une commande en haut, j'ai vu MySQL a l'aide de 160% du CPU!

Récemment, j'ai eu l'optimisation des tables et j'ai passé à les connexions persistantes. Cela pourrait-il être la cause de MySQL à utiliser de grandes quantités de CPU?

  • Les connexions persistantes sont presque toujours pas la bonne chose à utiliser.
  • je vais les prendre maintenant et regarder pour une différence parce que je ne me souviens jamais le cpu étant au-dessus de 2 il y a un mois!
  • Les serveurs ont tendance à avoir plus d'un noyau. Pour cent l'utilisation du PROCESSEUR est calculée par rapport à un noyau, anotherwords un processus à l'aide de deux cœurs complètement aura une utilisation du PROCESSEUR de 200%. Ici, MySQL utilise 100% d'un seul cœur et 60% d'un autre cœur. Cela ne signifie pas que tous les Processeurs sont utilisés, plus il est probable qu'il a encore au moins deux Processeurs.
  • CPU élevée signifie presque toujours inefficace des requêtes. Telles sont généralement résolu par une meilleure indexation (en particulier les "composite") et/ou la reformulation de la requête.
InformationsquelleAutor Juddling | 2009-08-15
  1. 252

    D'abord, je dirais que vous voudrez probablement désactiver les connexions persistantes comme ils ont presque toujours en faire plus de mal que de bien.

    Deuxièmement, je dirais que vous voulez vérifier vos utilisateurs MySQL, juste pour s'assurer qu'il n'est pas possible pour quiconque de se connecter à partir d'un serveur distant. C'est aussi un de sécurité majeur chose à vérifier.

    Troisièmement, je dirais que vous souhaitez activer sur le MySQL Requête Lente Journal de garder un œil sur les requêtes qui prennent beaucoup de temps, et l'utiliser pour vous assurer de ne pas avoir toutes les requêtes de verrouillage de la clé de tables pour trop longtemps.

    Quelques autres choses que vous pouvez vérifier serait d'exécuter la requête suivante, tandis que la charge du PROCESSEUR est élevée:

    SHOW PROCESSLIST;

    Cela va vous montrer toutes les requêtes qui sont actuellement en cours d'exécution ou dans la file d'attente pour s'exécuter, ce que la requête est et ce qu'il fait (cette commande va tronquer la requête s'il est trop long, vous pouvez utiliser SHOW FULL PROCESSLIST pour voir l'intégralité du texte de la requête).

    Vous aurez également besoin de garder un oeil sur des choses comme votre taille de mémoire tampon, table de cache, mise en cache de requêtes et innodb_buffer_pool_size (si vous utilisez les tables innodb) que l'ensemble de ces allocations de mémoire peut avoir un effet sur les performances des requêtes qui peuvent causer MySQL de bouffer du CPU.

    Vous aurez également probablement souhaitez donner à la suite d'une lecture plus car ils contiennent de l'information de qualité.

    C'est aussi une très bonne idée d'utiliser un profiler. Quelque chose que vous pouvez activer quand vous le souhaitez qui va vous montrer ce que les requêtes de votre application est en cours d'exécution, si il y a doublon requêtes, combien de temps ils prennent, etc, etc. Un exemple de quelque chose comme cela, c'est celui que j'ai été travailler sur appelé PHP Profiler mais il ya beaucoup là-bas. Si vous êtes à l'aide d'un morceau de logiciel comme Drupal, Joomla ou WordPress, vous aurez envie de demander autour de l'intérieur de la communauté, car il y a probablement des modules disponibles pour eux et qui permettent d'obtenir cette information sans avoir à intégrer manuellement quoi que ce soit.

    • merci beaucoup pour ce, j'ai enlevé persistant connexions et puis mettre en place le slow query log. j'ai lu le journal et la plupart des requêtes est venue de deux table et les tables n'avaient pas été correctement indexées! c'est seulement environ 10 minutes, mais voici le résultat: charge CPU moyennes de 0,48 (1 min) 0.95 (5 minutes) 2.42 (15 minutes) merci beaucoup
    • même problème, résolu par l'indexation des tables que ralentir le processus, je vous remercie Steven et Juddling
    • Pourriez-vous élaborer sur la façon d'Index d'un tableau s'il vous plaît? Peut-être un lien? Je sais qu'il a été un certain temps, mais je suis vraiment nouveau dans cette chose. Désolé fr le noobish question
    • La journalisation des requêtes lentes m'a aidé à trouver mon problème particulier de l'utilisation élevée du PROCESSEUR. Dans mon cas, c'est un plugin WordPress (ultimate-tag-cloud-widget) qui était en train de faire un monstrueux requête à chaque coup juste pour montrer le populaire balises. C'est un excellent plugin, mais il a besoin d'être amélioré avec la mise en cache d'une certaine sorte (j'ai fini la personnalisation pour obtenir mon problème résolu).
    • Une autre chose qui a aidé un autre problème a été la modification du paramètre innodb_buffer_pool_size mentionnés ci-dessus. Tout en essayant de trouver la cause de l'utilisation élevée du PROCESSEUR, j'ai lu quelque part que innodb_buffer_pool_size doit être d'au moins la taille du fichier ibdata1, qui se trouve dans /var/lib/mysql. Il semble InnoDB fonctionne de manière beaucoup plus efficace lorsqu'elle est capable d'être résident dans la mémoire. Cela peut être difficile à faire dans certaines situations parce que ibdata1 peut être énorme! Il a également été suggéré quelque part pour s'assurer innodb_log_buffer_size est de 25% de la taille de innodb_buffer_pool_size.
    • Il y a aussi SPECTACLE PLEIN PROCESSLIST de commande qui montre plein de requête, pour moi, il a montré d'énormes rejoindre, généré par l'ORM système...

    InformationsquelleAutor Steven Surowiec
  2. 166

    Comme c'est le top du post si vous google pour MySQL utilisation élevée de l'UC ou de la charge, je vais ajouter une autre réponse:

    Le 1er juillet 2012, un saut de seconde a été ajoutée à l'heure UTC-temps pour compenser le ralentissement de la rotation de la terre à cause des marées. Lors de l'exécution de ntp (ou ntpd), cette deuxième a été ajoutée à votre ordinateur/l'horloge du serveur. MySQLd n'a pas l'air d'aimer cette seconde sur certains OS es, et donne une charge élevée de l'UC. Le quick fix est (en tant que root):

    $ /etc/init.d/ntpd stop
$ date -s "`date`"
$ /etc/init.d/ntpd start
    • Depuis le post original a été d'environ 3 ans, je me doute que c'est la cause de l'affiche originale du problème. Mais il était la cause de mon problème, et m'a sauvé tout à l'heure - alors merci! Plus d'infos: blog.mozilla.org/it/2012/06/30/...
    • Même problème & pour moi, la solution sur Ubuntu 12.04. Les étapes pour résoudre légèrement différente: le service ntp stop && date -s "date" && service ntp start MySQL utilisation de l'UC instantanément baissé de 50 - 100% 0 - 1%
    • yup qu'il a fait sur Amazon EC2 AMI linux ainsi, il suffit de le remplacer "service ntpd stop/start" pour l'init.d choses.
    • Merci BEAUCOUP, j'ai eu le même problème et ce qu'il est corrigé.
    • A travaillé pour moi, trop. Avoir un upvote.
    • Douce, merci @wwwhizz! Une autre solution est de simplement redémarrer votre serveur. Débarrassé de droite pour moi.
    • Merci beaucoup! Vous venez d'enregistrer mon bacon sous Fedora lors d'une tv replay installer. Bien obligé!
    • Wow. Jamais dans un million d'années souvenu, ou compris. Merci @wwwhizz!
    • Cela m'a aidé aussi, je n'aurais jamais pensé à ce sujet et n'a jamais pensé le saut de seconde question touchés mysql.
    • Redémarrer mysqld n'a pas le résoudre, les journaux ne montrait rien, SHOW PROCESSLIST n'avait rien à me dire. Google m'a dirigé ici la bonne solution 🙂
    • Yep, c'instantanément fixé mon problème!
    • Oui, cela m'a sauvé ainsi. Ubuntu doit faire quelque chose.
    • vous ne savez pas comment vous compris cela, mais il fonctionne. Cheers!
    • Il a travaillé pour moi instantanément. Merci beaucoup!
    • Cela peut-il être exécuté qu'à vous assurer ? Je veux dire, est-il sécuritaire de l'exécuter même si elle n'est pas la raison ?
    • Juillet 1, 2015 - j'ai vécu cette seconde intercalaire bug sur un courant AWS EC2 serveur exécutant Linux Amazon. Utilisation sudo service ntpd stop sur cette configuration.
    • Moi aussi dans une OpenSUSE serveur... résolu grâce à ce thread. Merci beaucoup!!
    • endommagé mon système de date-large..
    • +1 pour cette solution. Mon MySQL était en cours d'exécution de 50 à 60% pour le mois, sans raison, après l'application de cette solution, il descendit maintenant tous 0.0-0.3%, ce qui était la façon dont elle devait être. Merci beaucoup.
    • Que faites-vous si vous utilisez VMWARE temps au lieu de ntpd comme suggéré ici? serverfault.com/questions/95655/why-does-my-ntpd-not-work
    • VmWare permet de synchroniser l'heure avec la machine hôte, et, par conséquent, assurez-vous que le temps est mis à jour sur la machine hôte, alors synchronisées avec l'ordinateur invité.
    • Eh bien, ressemble à un saut de seconde a été ajoutée à nouveau en 2017, car à partir du 1er Jan notre charge moyenne a augmenté de 0,05 à 0,50 et y est resté constamment. MySQL a été de près de 50% de CPU qui ne semblent pas droit. Après avoir fait de la ci-dessus, il est revenu à la normale instantanément. Je vous remercie beaucoup.
    • Grande, qui a résolu mon problème (aussi démarré le 1er janvier 2017)
    • J'ai dû changer légèrement la date de commande pour éviter une invalid date erreur (problème de langage): date -s "$(LC_ALL=C date )".
    • Wow, ne peut pas croire que c'est ce que le problème a été. mysqld était de 77% de CPU pendant des mois au ralenti et c'est tombé à 0,3%.
    • Pour le rendre plus facile pour Ubuntu 12.04 LTS utilisateurs, ici, c'est le seul enchaîné commande: service ntp stop && date -s "`date`" && service ntp start

    InformationsquelleAutor RedPixel
  3. 30

    Si ce serveur est visible de l'extérieur, Il vaut la peine de vérifier si c'est d'avoir beaucoup de demandes de contact du monde extérieur (c'est à dire des gens qui tentent de percer il)

    • Je ne sais pas pourquoi cela a attiré un anonyme downvote, compte tenu de ce qui a été une des causes dans le passé pour certains systèmes.
    • Je pense que la baisse de vote est à MySQL visible de l'extérieur n'est pas une bonne idée.
    • Non, ce n'est pas une bonne idée, car il va agir comme un objectif pour beaucoup de gens à essayer et acquérir de l'entrée, qui donne une charge élevée de l'UC - d'où ma réponse comme une raison possible.
    • Je déteste quand quelqu'un juste en bas de votes et c'est parti !
    • +1 parce que c'est absolument une raison légitime de MySQL pour avoir une utilisation élevée du PROCESSEUR, et quelqu'un pour qui c'est la réponse vraiment vraiment besoin de cette information!
    InformationsquelleAutor Rowland Shaw