Requête SQL beaucoup plus lente malgré un serveur kimsufi 250g plus puissant

WRInaute discret
Bonjour,

J'avais un hébergement mutualisé chez ovh. (offre Business) voila le lien http://www.ovh.com/fr/hebergement_mutualise/

Et j'ai pris un nouveau serveur kimsufi 250g.http://www.kimsufi.com/fr/

Le problème n'est pas là ;-) J'ai bien reçu mon nouveau serveur et je l'ai installé et il fonctionne à merveille.

Ma base de donnée étant sur mon premier serveur j'ai décidé de transférer la base de donnée et de changer la connexion .

Tout fonctionne. Mais...

Si je fais cette requete sur mon ancien serveur:

UPDATE OFFRES SET REF='18' WHERE ID='1'

Voici la notification: Nombre d'enregistrements affectés : 1 (Traitement en 0.0013 sec.)

Sur le nouveau serveur:

UPDATE OFFRES SET REF='18' WHERE ID='1'

Nombre d'enregistrements affectés : 1 (Traitement en 0.1119 sec.)

Ce que je comprend pas c'est que j'ai fais un import/export de ma base de donnée donc je n'ai pas touché aux index.

Et c'est seulement sur ma table OFFRES que le serveur mysql rame à fond. Et pas qu'un peu...

Que faire dans ce cas pour accélérer le réponse de chaque requête envoyé?

NB: La taille sur disque de la table OFFRES =250MO qui n'est pas grand .

Cdt.
 
WRInaute accro
Euh quand même un peu grand non ^^
vérifie tes index, as tu transféré tous les objets de la base et pas seulement les tables ?
Réparation, optimisation...
 
WRInaute discret
Les bases de données actuel comme par exemple Oracle dispose de calculs statistiques permettant d'optimiser automatiquement les requêtes sql en optant pour le plan d’exécution le plus efficace.

Dès lors, il est probable qu’après installation de ta nouvelle BD, les requêtes mettent légèrement plus de temps à être exécutés. Tout devrait revenir à la normale d'ici quelques temps après le calcul des stats par la BD.

PS: Je ne sais pas si MySql fonctionne via des mécanismes d'optimisations automatique comme Oracle, mais si c'est le cas, le problème pourrait s'expliquer ainsi.
 
WRInaute accro
Ce sera long et fastidieux si tu n'as aucune base en administration serveur mais tu peux débuter par ceci.
Ensuite tu pourras affiner tes recherches sur le forum OVH en integrant le système d’exploration installé dans tes requêtes.

Désolé de te renvoyer ainsi sur un lien mais tu n'échapperas pas à un minimum de formation pour administrer le serveur et corriger tous les aléas que tu rencontreras de façon certaine.
 
WRInaute discret
Bonjour,

est ce que ce lenteur peu être dû suite à un envoi massive d'emailing chaque jour?


D'autre façon l'envoi d'emailing peut ralentir le fonctionnement du serveur ?


Cdt.
 
WRInaute discret
salva a dit:
Ce sera long et fastidieux si tu n'as aucune base en administration serveur mais tu peux débuter par ceci.
Ensuite tu pourras affiner tes recherches sur le forum OVH en integrant le système d’exploration installé dans tes requêtes.

Désolé de te renvoyer ainsi sur un lien mais tu n'échapperas pas à un minimum de formation pour administrer le serveur et corriger tous les aléas que tu rencontreras de façon certaine.


Vraiment je suis débutant dans la gestion et configuration des serveurs dédiés.

Comment je peut explorer les fichiers sur un serveur dedié (exemple le fichier php.ini) , je ne trouve pas ca sur l'interface de plesk.


Aperçu sur niveau des charges & real monitoring

http://imageshack.us/photo/my-images/841/mrtgproxy.png/

http://imageshack.us/f/26/rtm326332412966.png/

http://imageshack.us/photo/my-images/546/rtm798044592448.png/

http://imageshack.us/photo/my-images/801/sansre1xr.png/

Cdt.
 
WRInaute discret
spout a dit:

J'ai installé MySQLTuner-perl et voila ce que j'ai obtenu :

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster
[--] Data in MyISAM tables: 4M (Tables: 515)
[--] Data in InnoDB tables: 203M (Tables: 155)
[!!] BDB is enabled but isn't being used
[!!] Total fragmented tables: 8

-------- Security Recommendations -------------------------------------------
[OK] All database users have passwords assigned

-------- Performance Metrics -------------------------------------------------
[--] Up for: 41d 0h 57m 4s (20M q [5.886 qps], 2M conn, TX: 8B, RX: 1B)
[--] Reads / Writes: 91% / 9%
[--] Total buffers: 34.0M global + 2.7M per thread (100 max threads)
[OK] Maximum possible memory usage: 309.0M (15% of installed RAM)
[OK] Slow queries: 0% (55/20M)
[OK] Highest usage of available connections: 20% (20/100)
[OK] Key buffer size / total MyISAM indexes: 8.0M/6.2M
[OK] Key buffer hit rate: 99.8% (34M cached / 52K reads)
[!!] Query cache is disabled
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 858K sorts)
[!!] Joins performed without indexes: 113010
[OK] Temporary tables created on disk: 4% (123K on disk / 2M total)
[!!] Thread cache is disabled
[!!] Table cache hit rate: 0% (64 open / 47K opened)
[OK] Open file limit used: 5% (57/1K)
[OK] Table locks acquired immediately: 99% (11M immediate / 11M locks)
[!!] InnoDB data size / buffer pool: 203.7M/8.0M

-------- Recommendations -----------------------------------------------------
General recommendations:
Add skip-bdb to MySQL configuration to disable BDB
Run OPTIMIZE TABLE to defragment tables for better performance
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Set thread_cache_size to 4 as a starting value
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
query_cache_size (>= 8M)
join_buffer_size (> 128.0K, or always use indexes with joins)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 203M)
 
WRInaute discret
J'ai ajouté ce commande mysql> SET GLOBAL query_cache_size = 1000000;pour mettre les requetes en cache.

J'ai remarqué que au début la page se charge troooop long et après elle sera très rapide.Bon tt la page est devenu en cache.

C'est normal ?
 
WRInaute passionné
Attention, tu compares ce qui n'est pas comparable :P
Sur le mutu, tu as un HG partagé (mais optimisé par des pros)
Sur ton kimsufi, tu as des disques durs hyper lents, non optimisés.

Suit les recommandations de ton tuning-primer/mysqltuner.
Code:
query_cache_size (>= 8M)
join_buffer_size (> 128.0K, or always use indexes with joins)
thread_cache_size (start at 4)
table_cache (> 64)
innodb_buffer_pool_size (>= 203M)
Donc dans ton my.cnf:
Code:
query_cache_size = 64M
table_cache = 512
innodb_buffer_pool_size = 256M
Les autres consommeront trop de RAM comparé à ce qu'il y a sur un kimsufi. (tu peux quand même monter ton join_buffer_size à 256Ko sans trop de soucis).

Je pense que ta table en question est en innoDB avec un innoDB mal configuré, ça devrait bien augmenter les perfs de changer le pool size
 
WRInaute discret
Voila après plusieurs tentative de modification j'obtiens toujours des alertes.
mysql> SET GLOBAL query_cache_size = 60000000;
mysql> SET SESSION query_cache_type = 1;
mysql> SET GLOBAL join_buffer_size =20000000;
mysql> SET GLOBAL query_cache_limit =60000000;



*********************************************************************************************************

>> MySQLTuner 1.2.0 - Major Hayden <major@mhtx.net>
>> Bug reports, feature requests, and downloads at http://mysqltuner.com/
>> Run with '--help' for additional options and output filtering

-------- General Statistics --------------------------------------------------
[--] Skipped version check for MySQLTuner script
[OK] Currently running supported MySQL version 5.0.77
[OK] Operating on 64-bit architecture

-------- Storage Engine Statistics -------------------------------------------
[--] Status: -Archive +BDB -Federated +InnoDB -ISAM -NDBCluster
ERROR 1018 (HY000) at line 1: Can't read dir of '.' (errno: 24)
ERROR 1018 (HY000) at line 1: Can't read dir of '.' (errno: 24)
[!!] InnoDB is enabled but isn't being used
[!!] BDB is enabled but isn't being used
Argument "" isn't numeric in numeric gt (>) at ./mysqltuner.pl line 549 (#1)
(W numeric) The indicated string was fed as an argument to an operator
that expected a numeric value instead. If you're fortunate the message
will identify which operator was so unfortunate.

[OK] Total fragmented tables:

-------- Security Recommendations -------------------------------------------
ERROR 1016 (HY000) at line 1: Can't open file: './mysql/user.frm' (errno: 24)
[OK] All database users have passwords assigned
ERROR 1018 (HY000) at line 1: Can't read dir of '.' (errno: 24)

-------- Performance Metrics -------------------------------------------------
[--] Up for: 41d 7h 25m 40s (20M q [5.860 qps], 2M conn, TX: 8B, RX: 1B)
[--] Reads / Writes: 91% / 9%
[--] Total buffers: 206.2M global + 21.7M per thread (100 max threads)
[!!] Maximum possible memory usage: 2.3G (120% of installed RAM)
[OK] Slow queries: 0% (92/20M)
[OK] Highest usage of available connections: 20% (20/100)
Argument "" isn't numeric in numeric eq (==) at ./mysqltuner.pl line 735 (#1)
[!!] None of your MyISAM tables are indexed - add indexes immediately
[!!] Query cache efficiency: 0.1% (12K cached / 9M selects)
[OK] Query cache prunes per day: 29
[OK] Sorts requiring temporary tables: 0% (0 temp sorts / 863K sorts)
[!!] Joins performed without indexes: 114215
[OK] Temporary tables created on disk: 4% (124K on disk / 2M total)
[!!] Thread cache hit rate: 0% (2M created / 2M connections)
[!!] Table cache hit rate: 0% (512 open / 54K opened)
[!!] Open file limit used: 98% (1K/1K)
[OK] Table locks acquired immediately: 99% (11M immediate / 11M locks)

-------- Recommendations -----------------------------------------------------
General recommendations:
Add skip-innodb to MySQL configuration to disable InnoDB
Add skip-bdb to MySQL configuration to disable BDB
Reduce your overall MySQL memory footprint for system stability
Enable the slow query log to troubleshoot bad queries
Adjust your join queries to always utilize indexes
Increase table_cache gradually to avoid file descriptor limits
Variables to adjust:
*** MySQL's maximum memory usage is dangerously high ***
*** Add RAM before increasing MySQL buffer variables ***
query_cache_limit (> 57M, or use smaller result sets)
join_buffer_size (> 19.1M, or always use indexes with joins)
thread_cache_size (> 25)
table_cache (> 512)
open_files_limit (> 1024)

Sinon, quel est le meilleur confoguration dans ce cas ?


Cdt
 
WRInaute passionné
Déjà fais le pas en SET GLOBAL, mais en dur dans la conf.

Tu as des valeurs qui sont n'importes quoi sur certains trucs.
Code:
join_buffer_size (> 19.1M, or always use indexes with joins)
Ca pas plus de 1Mo (et encore sur un kim ça fait beaucoup).

Les recommandations mysqltuner sont faites sur des valeurs moyennes.
Tes valeurs moyennes sont établies sur :
Code:
[--] Up for: 41d 7h 25m 40s (20M q [5.860 qps], 2M conn, TX: 8B, RX: 1B)
Et donc quand tu fais tes modifications et ton mysqltuner 10s après, ton "10 secondes d'utilisateurs avec ces variables" représentent moins de 0.001% de la durée d'utilisation: donc fait des restart!
 
Discussions similaires
Haut