Pourquoi cette différence dans les performances d'INSERT... ?

Question

Bonjour, j'ai récemment effectué un test sur deux serveurs ubuntu différents.

    Here are the results:
    innodb_flush_trx_commit = 1
    Staging Server: 10,000 Inserts ----> 81 seconds  
    innodb_flush_trx_commit = 2 
    Staging Server: 10,000 Inserts ----> 61 seconds  

    Dev     Server: 
    innodb_flush_trx_commit = 1
    10,000 Inserts ----> 5 seconds  
    Dev     Server: 
    innodb_flush_trx_commit = 2
    10,000 Inserts ---->  2 seconds 

    I am clear that performance vary with innodb_flush setting.
    But why there is a huge diff in performance from the server to server ?

Quelles sont les choses à considérer ici... ? Voici les quelques détails pris en compte mais aucune chose significative à suspecter :

    staging server: Intel(R) Xeon(R) CPU X5355 @2.66GHz
                    processor 0, 1  
                    mysql 5.1.61
                    innodb_buffer_pool : 8MB
                    RAM: 4GB                        

    dev     server: AMD Opteron(tm) Processor 4130 @2.60ghZ
                    processor 0, 1  
                    mysql 5.0.67
                    innodb_buffer_pool : 8MB
                    RAM: 4GB

Veuillez m'aider à comprendre ce qui est à l'origine de cette énorme différence de performance sur différents serveurs... ?

  NOTE: same script used in the same way on noth the servers and not from remote  
        sesrvers.

Merci d'avance. Salutations, UDAY

Answer 1

Quelques questions que je me poserais...

La journalisation binaire est-elle activée dans une instance et pas dans l'autre ?

Le serveur de transit utilise-t-il un lecteur en réseau pour accéder aux données mysql ?

Le type de système de fichiers est-il le même sur les deux serveurs (ext3, ext2, etc.) ?

L'activité du disque semble être le coupable ici.

Answer 2

Votre serveur d'essai est-il un serveur de production ? Dans ce cas, il s'agit probablement d'un problème de concurrence. Si de nombreux utilisateurs travaillent sur ce serveur, les insertions peuvent être plus lentes, surtout si la ou les tables dans lesquelles vous insérez des données sont également utilisées par d'autres personnes. Le serveur de développement est probablement beaucoup moins chargé, car seuls quelques développeurs l'utilisent simultanément.

Answer 3

En laissant de côté les différences matérielles (ce qui n'est pas une hypothèse facile). Les facteurs qui influencent les performances d'une requête sont les suivants :

1. Version du moteur du SGBD
2. Plan de requête et statistiques db utilisées
3. Latence du réseau
4. Mémoire allouée au moteur du SGBD (journal du tampon de transaction inclus)
5. Priorité du processus/thread du moteur du SGBD

Answer 4

Je vous suggère également de vérifier l'utilisation du disque. Pour avoir une idée générale de l'utilisation du disque pendant l'exécution de votre test, vous pouvez utiliser iostat (sur les systèmes basés sur redhat, il se trouve dans le paquetage systat )

Par exemple, vous pouvez essayer ce qui suit :

iostat -xd 1

ce qui conduirait à un résultat similaire à celui-ci :

Device:         rrqm/s   wrqm/s     r/s     w/s   rsec/s   wsec/s avgrq-sz avgqu-sz   await  svctm  %util
sda               0.00     0.31    0.00    0.05     0.16     2.89    56.67     0.00    2.99   0.62   0.00

Comparez ici le await temps sur les deux machines. Cette mesure vous indique le temps moyen, en millisecondes, dont le disque a besoin pour répondre aux demandes d'E/S. C'est un moyen rapide de vérifier s'il y a des problèmes de sécurité. C'est un moyen rapide de vérifier s'il y a de grandes différences. Il est également intéressant de connaître le %util métrique. Elle vous donne le pourcentage du temps processeur passé à effectuer des opérations d'E/S sur le périphérique. Plus cette valeur est élevée, plus vous vous rapprochez de la saturation complète de votre périphérique.

Pour les autres options, vérifiez man iostat .

Bien sûr, la description ci-dessus ne vous donne qu'un aperçu très basique de la performance de vos disques. Gardez donc à l'esprit qu'il s'agit d'une opération supplémentaire à celle mentionnée précédemment afin de localiser votre problème.