40 votes

Requête MySQL décalée au hasard

J'ai une requête qui ressemble à ceci:

SELECT id FROM user WHERE id='47'

L'ID est indexé et lit pour cette requête sont toujours rapide lors de l'utilisation de profilage de données, comme cela.

SET profiling = 1;
SHOW PROFILES;

Les requêtes s'exécutent toujours dans autour de 0,0002 secondes.

Cependant, si j'ai le profil de la requête à partir de l'PHP côté, comme ceci:

$current = microtime(true);
$data = $conn->query($full_query);
$elapsed = microtime(true) - $current;

Alors parfois peut-être 1 sur 50 de ces requêtes faudra quelque chose comme .2 secondes. Cependant, dans mon script de test, j'ai le code pour tester ce que les profils de la requête à l'aide de JEU de profilage = 1; et même si le PHP tour de voyage dans l'AOP peut être .2 secondes la durée de la requête était encore de 0,0002.

Les choses que je connais, ou que vous connaissez qui ne sont pas à l'origine du problème:

  1. La requête n'est pas lent. Quand je regarde la même requête, à partir de la même requête à exécuter, profilés en PHP et profilé à l'aide de JEU de PROFILAGE de la requête est toujours rapide et de ne jamais enregistré dans le slow query log, même quand il montre la prise .2 secondes de la PHP côté.
  2. Ce n'est pas skip-name-resolve liés - c'est incohérent et j'ai skip-name-resolve déjà sur
  3. Ce n'est pas du cache de requêtes liées, le problème existe dans les deux
  4. Ce problème se produit même sur les requêtes provenant de la cache.
  5. La requête n'a pas pour effet de sélectionner l'ID, mais je utiliser cette requête pour que les essais montrent que ce n'est pas un problème d'accès au disque depuis que le terrain est certainement indexés.
  6. Ce tableau est seulement de 10 à 20 mégas avec quelque chose comme un 1 meg index. La machine indique très peu de charges et innodb n'est pas à l'aide de tous ses tampons.
  7. C'est testé sur une table qui n'a pas d'autre activité contre d'autres que mes requêtes de test.

Quelqu'un a une idée de ce que l'autre chose à vérifier? Cela me semble être un problème de réseau, mais j'ai besoin d'être en mesure de voir et de trouver la question à régler le problème et je suis à cours d'endroits à vérifier suivant. Des idées?

11voto

New Alexandria Points 3106

Je voudrais profil de la machine.

Vous dites cela se produit ~1 par 50 fois, et que chaque requête est de 0,2 sec de référence. Vous devriez être capable de mettre à l'écran, puis exécuter une boucle de requêtes en PHP de test de charge des SGBDR et de recueillir des statistiques de performances.

Vous aurez probablement à exécuter plus d' 50 * 0.2 =10 seconds, depuis votre "1 50" statistique est probablement basé sur la main-exécution de requêtes individuelles basées sur ce que j'ai lu dans votre description. Essayez de 30 secondes et 90 secondes, les tests de charge.

Pendant ce temps, regarder votre top processus de l'écran. Trier par UC en appuyant sur P. Chaque fois que vous appuyez sur la touche 'P' il va changer l'ordre de tri pour les processus de de-CPU-consommation, donc assurez-vous d'avoir les plus longues sur le dessus. (en appuyant sur M tris par l'utilisation de la mémoire. vérifiez la page de manuel pour plus de détails)

Cherchez rien que des bulles vers le haut au cours de la période(s) de votre test de charge. Vous devriez voir quelque chose de sauter plus - cependant momentanément.
(remarque, un tel processus ne peut pas atteindre le haut de la liste, il n'a pas besoin, mais peut encore introduire un disque suffisant de charge ou de toute autre activité de lag le serveur MySQL)

7voto

웃웃웃웃웃 Points 8087

J'ai remarqué le même phénomène sur mes systèmes. Les requêtes qui, normalement, prendre une milliseconde va soudainement prendre 1 à 2 secondes. Toutes mes affaires sont simples, table unique d'INSERTION/mise à JOUR/REMPLACER consolidés --- pas sur tous les Sélectionne. Pas de charge, le verrouillage ou le fil de construire est évident.

Je me doutais que c'est en raison de l'effacement de pages sale, bouffées de chaleur les changements sur le disque, ou cachées des mutex, mais je n'ai pas encore le réduire.

Aussi, Écarté

  1. La charge du serveur -- pas de corrélation avec la haute

  2. la charge du Moteur-qui se passe avec InnoDB/MyISAM/Mémoire de Requête MySQL

  3. Cache-qui se passe que ce soit sur ou en dehors

  4. Journal des rotations -- pas de corrélation dans les événements

6voto

Bill Karwin Points 204877

Bon pour vous, ont été à l'aide de la requête profiler déjà. Si vous utilisez MySQL 5.6, vous avez également accès à un grand nombre de nouvelles mesures de performance dans le PERFORMANCE_SCHEMA. Ce qui a la capacité de mesurer beaucoup plus de détails que la requête profiler, et il mesure aussi à l'échelle mondiale, au lieu d'une session. P_S est apparemment ce qui va remplacer la requête profiler.

Pour diagnostiquer votre problème, je voudrais commencer par confirmer ou d'exclure un réseau TCP/IP en question. Par exemple, tester le script PHP pour voir si il obtient la même intermittent de latence lors de la connexion via le socket UNIX. Vous pouvez le faire en vous connectant à l' localhost ce qui signifie que le script PHP doit s'exécuter sur le même serveur que la base de données. Si le problème disparaît lorsque vous contourner TCP/IP, ce serait de vous dire que la cause est susceptible d'être TCP/IP.

Si vous êtes dans un environnement virtuel comme un cloud hosting, vous pouvez facilement expérimenter des variations dans les performances, car d'autres utilisateurs du même nuage de façon intermittente à l'aide des toutes la bande passante. C'est l'un des inconvénients du cloud.

Si vous pensez que c'est un protocole TCP/IP de problème, vous pouvez tester le protocole TCP/IP de la latence de façon indépendante à partir de PHP ou MySQL. Typique des outils qui sont facilement disponibles incluent ping ou traceroute. Mais il y a beaucoup d'autres. Vous pouvez également tester la vitesse du réseau avec netcat. Utiliser un outil qui permet de mesurer à plusieurs reprises au fil du temps, car il semble que vous avez de bonnes performances, la plupart du temps, avec parfois des problèmes.

Une autre possibilité est que la faute réside dans PHP. Vous pouvez essayer de profilage PHP avec XHProf pour savoir où il est passé de son temps.

4voto

svidgen Points 4012

Essayez d'isoler le problème. Un petit script comme ceci:

https://drive.google.com/file/d/0B0P3JM22IdYZYXY3Y0h5QUg2WUk/edit?usp=sharing

... pour voir les étapes de la chaîne de dopage. Si vous avez ssh2 installé, il va également revenir ps axu immédiatement après la plus longue de test en boucle pour voir ce qui est en cours d'exécution.

En cours d'exécution contre localhost sur mon aménagement de la maison de la boîte, les résultats ressemblent à ceci:

Array
(
    [tests summary] => Array
        (
            [host_ping] => Array
                (
                    [total_time] => 0.010216474533081
                    [max_time] => 0.00014901161193848
                    [min_time] => 9.7036361694336E-5
                    [tests] => 100
                    [failed] => 0
                    [last_run] => 9.8943710327148E-5
                    [average] => 0.00010216474533081
                )

            [db_connect] => Array
                (
                    [total_time] => 0.11583232879639
                    [max_time] => 0.0075201988220215
                    [min_time] => 0.0010058879852295
                    [tests] => 100
                    [failed] => 0
                    [last_run] => 0.0010249614715576
                    [average] => 0.0011583232879639
                )

            [db_select_db] => Array
                (
                    [total_time] => 0.011744260787964
                    [max_time] => 0.00031399726867676
                    [min_time] => 0.00010991096496582
                    [tests] => 100
                    [failed] => 0
                    [last_run] => 0.0001530647277832
                    [average] => 0.00011744260787964
                )

            [db_dataless_query] => Array
                (
                    [total_time] => 0.023221254348755
                    [max_time] => 0.00026106834411621
                    [min_time] => 0.00021100044250488
                    [tests] => 100
                    [failed] => 0
                    [last_run] => 0.00021481513977051
                    [average] => 0.00023221254348755
                )

            [db_data_query] => Array
                (
                    [total_time] => 0.075078248977661
                    [max_time] => 0.0010559558868408
                    [min_time] => 0.00023698806762695
                    [tests] => 100
                    [failed] => 0
                    [last_run] => 0.00076413154602051
                    [average] => 0.00075078248977661
                )

        )

    [worst full loop] => 0.039211988449097
    [times at worst loop] => Array
        (
            [host_ping] => 0.00014400482177734
            [db_connect] => 0.0075201988220215
            [db_select_db] => 0.00012803077697754
            [db_dataless_query] => 0.00023698806762695
            [db_data_query] => 0.00023698806762695
        )

    [ps_at_worst] => USER       PID %CPU %MEM    VSZ   RSS TTY      STAT START   TIME COMMAND
root         1  0.0  0.0   2884  1368 ?        Ss   Sep19   0:29 /sbin/init
root         2  0.0  0.0      0     0 ?        S    Sep19   0:00 [kthreadd]
root         3  0.0  0.0      0     0 ?        S    Sep19   0:00 [migration/0]
root         4  0.0  0.0      0     0 ?        S    Sep19   0:06 [ksoftirqd/0]
root         5  0.0  0.0      0     0 ?        S    Sep19   0:00 [migration/0]
root         6  0.0  0.0      0     0 ?        S    Sep19   0:25 [watchdog/0]
root         7  0.0  0.0      0     0 ?        S    Sep19   7:42 [events/0]
root         8  0.0  0.0      0     0 ?        S    Sep19   0:00 [cgroup]
root         9  0.0  0.0      0     0 ?        S    Sep19   0:00 [khelper]
root        10  0.0  0.0      0     0 ?        S    Sep19   0:00 [netns]
root        11  0.0  0.0      0     0 ?        S    Sep19   0:00 [async/mgr]
root        12  0.0  0.0      0     0 ?        S    Sep19   0:00 [pm]
root        13  0.0  0.0      0     0 ?        S    Sep19   0:23 [sync_supers]
root        14  0.0  0.0      0     0 ?        S    Sep19   0:24 [bdi-default]
root        15  0.0  0.0      0     0 ?        S    Sep19   0:00 [kintegrityd/0]
root        16  0.0  0.0      0     0 ?        S    Sep19   0:47 [kblockd/0]
root        17  0.0  0.0      0     0 ?        S    Sep19   0:00 [kacpid]
root        18  0.0  0.0      0     0 ?        S    Sep19   0:00 [kacpi_notify]
root        19  0.0  0.0      0     0 ?        S    Sep19   0:00 [kacpi_hotplug]
root        20  0.0  0.0      0     0 ?        S    Sep19   0:00 [ata/0]
root        21  0.0  0.0      0     0 ?        S    Sep19   0:00 [ata_aux]
root        22  0.0  0.0      0     0 ?        S    Sep19   0:00 [ksuspend_usbd]
root        23  0.0  0.0      0     0 ?        S    Sep19   0:00 [khubd]
root        24  0.0  0.0      0     0 ?        S    Sep19   0:00 [kseriod]
root        25  0.0  0.0      0     0 ?        S    Sep19   0:00 [md/0]
root        26  0.0  0.0      0     0 ?        S    Sep19   0:00 [md_misc/0]
root        27  0.0  0.0      0     0 ?        S    Sep19   0:01 [khungtaskd]
root        28  0.0  0.0      0     0 ?        S    Sep19   0:00 [kswapd0]
root        29  0.0  0.0      0     0 ?        SN   Sep19   0:00 [ksmd]
root        30  0.0  0.0      0     0 ?        S    Sep19   0:00 [aio/0]
root        31  0.0  0.0      0     0 ?        S    Sep19   0:00 [crypto/0]
root        36  0.0  0.0      0     0 ?        S    Sep19   0:00 [kthrotld/0]
root        38  0.0  0.0      0     0 ?        S    Sep19   0:00 [kpsmoused]
root        39  0.0  0.0      0     0 ?        S    Sep19   0:00 [usbhid_resumer]
root        70  0.0  0.0      0     0 ?        S    Sep19   0:00 [iscsi_eh]
root        74  0.0  0.0      0     0 ?        S    Sep19   0:00 [cnic_wq]
root        75  0.0  0.0      0     0 ?        S<   Sep19   0:00 [bnx2i_thread/0]
root        87  0.0  0.0      0     0 ?        S    Sep19   0:00 [kstriped]
root       123  0.0  0.0      0     0 ?        S    Sep19   0:00 [ttm_swap]
root       130  0.0  0.0      0     0 ?        S<   Sep19   0:04 [kslowd000]
root       131  0.0  0.0      0     0 ?        S<   Sep19   0:05 [kslowd001]
root       231  0.0  0.0      0     0 ?        S    Sep19   0:00 [scsi_eh_0]
root       232  0.0  0.0      0     0 ?        S    Sep19   0:00 [scsi_eh_1]
root       291  0.0  0.0      0     0 ?        S    Sep19   0:35 [kdmflush]
root       293  0.0  0.0      0     0 ?        S    Sep19   0:00 [kdmflush]
root       313  0.0  0.0      0     0 ?        S    Sep19   2:11 [jbd2/dm-0-8]
root       314  0.0  0.0      0     0 ?        S    Sep19   0:00 [ext4-dio-unwrit]
root       396  0.0  0.0   2924  1124 ?        S<s  Sep19   0:00 /sbin/udevd -d
root       705  0.0  0.0      0     0 ?        S    Sep19   0:00 [kdmflush]
root       743  0.0  0.0      0     0 ?        S    Sep19   0:00 [jbd2/sda1-8]
root       744  0.0  0.0      0     0 ?        S    Sep19   0:00 [ext4-dio-unwrit]
root       745  0.0  0.0      0     0 ?        S    Sep19   0:00 [jbd2/dm-2-8]
root       746  0.0  0.0      0     0 ?        S    Sep19   0:00 [ext4-dio-unwrit]
root       819  0.0  0.0      0     0 ?        S    Sep19   0:18 [kauditd]
root      1028  0.0  0.0   3572   748 ?        Ss   Sep19   0:00 /sbin/dhclient -1 -q -lf /var/lib/dhclient/dhclient-eth0.leases -pf /var/run/dhclient-eth0.pid eth0
root      1072  0.0  0.0  13972   828 ?        S<sl Sep19   2:13 auditd
root      1090  0.0  0.0   2052   512 ?        Ss   Sep19   0:00 /sbin/portreserve
root      1097  0.0  0.2  37568  3940 ?        Sl   Sep19   2:01 /sbin/rsyslogd -i /var/run/syslogd.pid -c 5
rpc       1120  0.0  0.0   2568   800 ?        Ss   Sep19   0:09 rpcbind
rpcuser   1138  0.0  0.0   2836  1224 ?        Ss   Sep19   0:00 rpc.statd
root      1161  0.0  0.0      0     0 ?        S    Sep19   0:00 [rpciod/0]
root      1165  0.0  0.0   2636   472 ?        Ss   Sep19   0:00 rpc.idmapd
root      1186  0.0  0.0   2940   756 ?        Ss   Sep19  13:27 lldpad -d
root      1195  0.0  0.0      0     0 ?        S    Sep19   0:00 [scsi_tgtd/0]
root      1196  0.0  0.0      0     0 ?        S    Sep19   0:00 [fc_exch_workque]
root      1197  0.0  0.0      0     0 ?        S    Sep19   0:00 [fc_rport_eq]
root      1199  0.0  0.0      0     0 ?        S    Sep19   0:00 [fcoe_work/0]
root      1200  0.0  0.0      0     0 ?        S<   Sep19   0:00 [fcoethread/0]
root      1201  0.0  0.0      0     0 ?        S    Sep19   0:00 [bnx2fc]
root      1202  0.0  0.0      0     0 ?        S<   Sep19   0:00 [bnx2fc_l2_threa]
root      1203  0.0  0.0      0     0 ?        S<   Sep19   0:00 [bnx2fc_thread/0]
root      1206  0.0  0.0   2184   564 ?        Ss   Sep19   1:08 /usr/sbin/fcoemon --syslog
root      1240  0.0  0.0   8556   976 ?        Ss   Sep19   1:22 /usr/sbin/sshd
root      1415  0.0  0.1  12376  2088 ?        Ss   Sep19   6:09 sendmail: accepting connections
smmsp     1424  0.0  0.0  12168  1680 ?        Ss   Sep19   0:02 sendmail: Queue runner@01:00:00 for /var/spool/clientmqueue
root      1441  0.0  0.0   5932  1260 ?        Ss   Sep19   0:56 crond
root      1456  0.0  0.0   2004   504 tty2     Ss+  Sep19   0:00 /sbin/mingetty /dev/tty2
root      1458  0.0  0.0   2004   504 tty3     Ss+  Sep19   0:00 /sbin/mingetty /dev/tty3
root      1460  0.0  0.0   2004   508 tty4     Ss+  Sep19   0:00 /sbin/mingetty /dev/tty4
root      1462  0.0  0.0   2004   504 tty5     Ss+  Sep19   0:00 /sbin/mingetty /dev/tty5
root      1464  0.0  0.0   2004   508 tty6     Ss+  Sep19   0:00 /sbin/mingetty /dev/tty6
root      1467  0.0  0.0   3316  1740 ?        S<   Sep19   0:00 /sbin/udevd -d
root      1468  0.0  0.0   3316  1740 ?        S<   Sep19   0:00 /sbin/udevd -d
apache    3796  0.0  0.4  32668  9452 ?        S    Dec16   0:08 /usr/sbin/httpd
apache    3800  0.0  0.4  32404  9444 ?        S    Dec16   0:08 /usr/sbin/httpd
apache    3801  0.0  0.4  33184  9556 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    3821  0.0  0.4  32668  9612 ?        S    Dec16   0:08 /usr/sbin/httpd
apache    3840  0.0  0.4  32668  9612 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    3841  0.0  0.4  32404  9464 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    4032  0.0  0.4  32668  9632 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    4348  0.0  0.4  32668  9460 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    4355  0.0  0.4  32664  9464 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    4356  0.0  0.5  32660  9728 ?        S    Dec16   0:07 /usr/sbin/httpd
apache    4422  0.0  0.4  32676  9460 ?        S    Dec16   0:06 /usr/sbin/httpd
root      5002  0.0  0.0   2004   504 tty1     Ss+  Nov21   0:00 /sbin/mingetty /dev/tty1
root      7540  0.0  0.0   5112  1380 ?        S    Dec17   0:00 /bin/sh /usr/bin/mysqld_safe --datadir=/var/lib/mysql --socket=/var/lib/mysql/mysql.sock --pid-file=/var/run/mysqld/mysqld.pid --basedir=/usr --user=mysql
mysql     7642  0.1  1.0 136712 20140 ?        Sl   Dec17   2:35 /usr/libexec/mysqld --basedir=/usr --datadir=/var/lib/mysql --user=mysql --log-error=/var/log/mysqld.log --pid-file=/var/run/mysqld/mysqld.pid --socket=/var/lib/mysql/mysql.sock
root      8001  0.0  0.4  31028  9600 ?        Ss   Dec13   0:18 /usr/sbin/httpd
root      8092  0.0  0.0      0     0 ?        S    13:47   0:00 [flush-253:2]
root      8511  0.0  0.0      0     0 ?        S    13:48   0:00 [flush-8:0]
root      8551 16.0  0.4  28612  8008 pts/0    S+   13:49   0:00 php test-mysql-connection.php exit
root      8552 44.0  0.1  11836  3252 ?        Ss   13:49   0:00 sshd: root@notty 
root      8560  0.0  0.0   4924  1032 ?        Rs   13:49   0:00 ps axu
root     12520  0.0  0.1  11500  3212 ?        Ss   09:05   0:00 sshd: jonwire [priv]
jonwire  12524  0.0  0.1  11832  1944 ?        S    09:05   0:05 sshd: jonwire@pts/0
jonwire  12525  0.0  0.0   5248  1736 pts/0    Ss   09:05   0:00 -bash
root     16309  0.0  0.0   5432  1436 pts/0    S    12:01   0:00 su -
root     16313  0.0  0.0   5244  1732 pts/0    S    12:01   0:00 -bash
apache   16361  0.0  0.5  32908  9836 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16363  0.0  0.5  32908  9784 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16364  0.0  0.4  32660  9612 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16365  0.0  0.4  32668  9608 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16366  0.0  0.7  35076 13948 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16367  0.0  0.4  32248  9264 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   16859  0.0  0.5  32916  9844 ?        S    Dec15   0:08 /usr/sbin/httpd
apache   20379  0.0  0.4  32248  8904 ?        S    Dec15   0:08 /usr/sbin/httpd
root     28368  0.0  0.0      0     0 ?        S    Nov01   0:21 [flush-253:0]
apache   31973  0.0  0.4  31668  8608 ?        S    Dec16   0:08 /usr/sbin/httpd

)

Les résultats de l' ps axu d'ici sont assez inutiles, parce que je suis de la connexion à localhost. Mais, je peux voir à partir de ces résultats que la DB connecter des pics de latence parfois, comme le fait le "réseau" de la latence (certains TCP/IP buffer?).

Si j'étais vous, je voudrais augmenter le nombre de cycles d'essai jusqu'à 5000 et 50000.

0voto

Zsolt Szilagy Points 1636

Je peux simplement deviner , mais puisque vous avez éliminé la charge du serveur, et je suppose que vous avez vérifié les drapeaux rouges dans InnoDb-Stats (phpmyadmin est une aide précieuse dans ce domaine, bien qu'il existe des outils plus professionnels), il ne reste qu'un usage incohérent de clés. Se pourrait-il que votre requête varie légèrement et qu’il existe une constellation dans laquelle des indices sous-optimaux sont utilisés?

S'il vous plaît ajouter un FORCE INDEX PRIMARY ou similaire répéter vos tests.

Prograide.com

Prograide est une communauté de développeurs qui cherche à élargir la connaissance de la programmation au-delà de l'anglais.
Pour cela nous avons les plus grands doutes résolus en français et vous pouvez aussi poser vos propres questions ou résoudre celles des autres.

Powered by:

X