Mysql/Connexion php, Config, Index, Query, tampons, NFI im d'options

Question

avant tout, ma principale question:

Quelles sont quelques bonnes techniques de dépannage lorsque vous rencontrez un problème de variable en ce qui concerne l'accès à la base de données lente . Arrière-plan: J'ai un système qui gère plusieurs connexions DB afin que je puisse utiliser des requêtes sans tampon sur la sélection de la table principale. J'ai un problème où je vois une pause sur une requête très simple (sélectionnez l'identifiant, le nom, le titre, etc de travailler où non-unique-indexed-id limite 1) le système insère alors si aucun enregistrement trouvé ou écrase comme une mise à jour .

Je vois des pauses de plusieurs secondes sur ces requêtes sans pauses sur le traitement de la même requête entre les deux.

Les index, qui peuvent être corrompus ou trop longs à mettre à jour (char (13)), sans tampon ou tamponné, font peu de différence sur cette requête ponctuelle. Cela se passe sur plusieurs tables (elles sont construites et jetées après un traitement, il y a environ 30 copies différentes qui impliquent des processus légèrement différents mais les données stockées sont les mêmes) à différents moments sur différents fonctionne, les intervalles de temps sur l'attente est également différent.

Aussi, je suis à la recherche au mysql processlist et ne pas voir cette attente d'interrogation, ce qui me fait croire son un problème de transfert entre php cli et MySQL (même boîte)

Désolé si cela n'a guère de sens - mon le cerveau est absolument frit et épuisé en ce moment.

Est-ce que quelqu'un a rencontré quelque chose comme ça avant, si oui, comment avez-vous trouvé la cause?

Answer 1

J'ai récemment remarqué que mytop interrogera à intervalles d'une seconde, ce qui peut être plutôt révélateur.

Pour moi, cela ressemble simplement à un verrouillage de table sur les tables moteur MyISAM. Cependant, vous ne mentionnez pas le moteur de vos tables. Aussi quel est votre rapport d'insertion/mise à jour/sélection? Si vous avez un taux élevé de mises à jour, l'utilisation du cache de requêtes MySQL peut être un petit peu amélioration.

Qu'est-ce qu'un EXPLAIN vous dit sur les requêtes les plus chères? Vous devrez peut-être ajuster la façon dont vous avez conçu vos index ou réorganiser votre clause where dans votre requête. Si EXPLAIN vous donne une analyse de table complète ou un nombre de lignes très élevé, vous n'utilisez probablement pas vos index du mieux que vous le pouvez.

Pouvez-vous expliquer plus sur votre id-indexé non-unique? Un SHOW CREATE TABLE pourrait être utile.

EDIT

Si vous avez réduit votre taille de la mémoire tampon et amélioration observée, qui me dit que le temps qu'il faut pour allouer de la mémoire dans votre cas pourrait être important. Si la performance de la requête est inférieure à 1 seconde, je commencerais à examiner les performances du système, en particulier la mémoire. Je suggère de commencer par le haut, le tri par la mémoire, et l'affichage de l'espace d'échange et le nombre de défauts de la page. Ou en cours d'exécution vmstat, et gardez un œil sur l'activité de swap. Si vous constatez des temps d'attente élevés, vous pouvez attendre le débit du disque. (Un changement à innodb sans changement de performance est intéressant.Si vous étiez faible sur RAM, je pense qu'une situation de mémoire faible s'exposerait plus rapidement.)

Est-ce une application web? Si oui, existe-t-il une corrélation entre le nombre de connexions/threads, les connexions httpd et la latence de la requête?J'ai vu des processus php baloon apache de 35MB à 512MB et plus, et par la suite la machine serait en train de se transformer en swap-land.

Il est possible que vous rencontriez également un problème matériel. Il vaut toujours la peine de vérifier dmesg pour voir s'il y a des rapports de noyau ou des problèmes de disque. Y a-t-il quelque chose d'autre qui fonctionne sur le système? Auriez-vous des tâches cron qui pourraient être en concurrence pour le disque ou la mémoire?