seeps24 Posté 7 Janvier 2009 Auteur Posté 7 Janvier 2009 (modifié) Ooops, désolé zebx de t'avoir offensé ! et merci de ton aide. Modifié 7 Janvier 2009 par seeps24
seeps24 Posté 7 Janvier 2009 Auteur Posté 7 Janvier 2009 Comment puis je sauvegarder mon fichier my.cnf sous un autre nom avant de le modifier ?
zebx Posté 7 Janvier 2009 Posté 7 Janvier 2009 (modifié) Ooops, désolé zebx de t'avoir offensé ! Aucunement Ca fait toujours plaisir d'aider. Je rédige un autre article sur un niveau d'optimisation intermédiaire. En attendant de trouver un peu de temps libre, si tu notes une nette variation concernant le monitoring de ton serveur après optimisation via mysqltuner, mais que l'amélioration reste insuffisante, tu peux utiliser les informations remontées par l'outil MySQL mysqlreport. Cependant, il te faudra assimiler une partie de la documentation en ligne de mysql.com pour faire les bons choix. Enfin, et cela ne va pas dans le même sens que la remarque d'OVH, les campagnes d'optimisation doivent commencer par les front (Apache) et non par le backend (prog + base). En général, elle répondent à la loi de Pareto : tu résous 80% de tes problèmes juste en ajustant la conf Apache, le tout pour 20% d'effort Sans plus d'info sur ton serveur, on voit clairement que tu sous-exploites la RAM. Je pense que tu ne caches rien ; ni côté MySQL, ni côté Apache. Des infos sur l'activité des IO disk confirmeraient cela. Vu que ton audience est somme toute raisonnable, je pense que tu peux faire des miracles en ajustant le keepalive, le maxclient, le niveau de log et en utilisant les mods header et expire, voir deflate, côté Apache. Pour l'optimisation côté front, j'utilise chez AOL l'outil http://performance.webpagetest.org:8080/ . Cet outil fabuleux peut t'aider à identifier et résoudre certains pb. Courage Modifié 7 Janvier 2009 par zebx
seeps24 Posté 8 Janvier 2009 Auteur Posté 8 Janvier 2009 (modifié) Ayant relancer OVH, ils m'ont fait entendre que j'avais beaucoup d'erreur infimes qui me faisaient ramer le site, et que ça remplissait les logs. J'ai regardé les logs et j'ai pu voir que c'était la plupart du temps, des erreurs du type : Undefined Variable, Undefined Index. Étant donné que ces erreurs sont vraiment infimes j'aimerai faire en sorte qu'elles soient désactivées totalement, et par ailleurs, que je ne les retrouve pas dans les logs. J'ai effectué quelques recherches avant de vous poser la question. J'ai fais des tests, mais sans grand résultat. Savez-vous comment faire ? Merci EDIT : Alors voila, ca y est j'y suis arrivé seul ! Wow ! J'ai modifié fichier php.ini à partir de WinSCP qui est 100 fois mieux que Putty pour les ultra débutants comme moi, à recommander. Pour ceux qui aimerai savoir ce que j'ai fais, regardez ici : http://fr3.php.net/error_reporting/ Voici pour ce problème ! Un de moins, je vais maintenant m'attaquer à la configuration de Mysql. Je vous donne des news ici pour ceux qui serait dans le même cas que moi et qui me lirons plus tard. Modifié 8 Janvier 2009 par seeps24
seeps24 Posté 8 Janvier 2009 Auteur Posté 8 Janvier 2009 Merci zebx, une fois que j'ai téléchargé WinSCP, j'ai pu effectué toutes les opérations de ton site sans problème (je te suggère de conseiller le téléchargement de WinSCP pour les débutants, dans ton article). Alors voila, j'ai eut ce résultat : -------- Recommendations ----------------------------------------------------- General recommendations: Add skip-bdb to MySQL configuration to disable BDB Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses 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) tmp_table_size (> 32M) max_heap_table_size (> 16M) thread_cache_size (start at 4) table_cache (> 64) Par contre, dans ton article, zebx, tu dis : "utiliser ses applications plusieurs heures" : il est possible de faire tourner le script automatiquement plusieurs heures ? Comment faire ? Pour Variables to adjust, je vais m'en sortir, mais pour General recommendations, c'est autre chose ... Merci
Kioob Posté 8 Janvier 2009 Posté 8 Janvier 2009 Étant donné que ces erreurs sont vraiment infimes j'aimerai faire en sorte qu'elles soient désactivées totalement, et par ailleurs, que je ne les retrouve pas dans les logs. Surtout pas ! Les erreurs PHP ralentiront toujours le site, même si tu les masques. Le seule solution est de les corriger. Il y a d'ailleurs eu un article sur Nexen.net à ce sujet il y a quelques semaines. Et ce que tu appelles "erreurs infimes", j'appelle ça "erreurs impardonnables"
seeps24 Posté 8 Janvier 2009 Auteur Posté 8 Janvier 2009 Tu imagine même pas le nombre d'erreurs qu'il y avait ! Je passerais 2 vies à tout corriger. Je peux au moins maintenant me concentrer sur les "vraies" erreurs, les plus grosses.
Kioob Posté 8 Janvier 2009 Posté 8 Janvier 2009 Raison de plus pour les corriger ! Le traitement des erreurs est vraiment quelque chose de lent dans PHP ; plus il y en a et plus c'est pénalisant pour les performances, peu importe leur "gravité".
zebx Posté 8 Janvier 2009 Posté 8 Janvier 2009 (modifié) Alors voila, j'ai eut ce résultat : -------- Recommendations ----------------------------------------------------- General recommendations: Add skip-bdb to MySQL configuration to disable BDB Run OPTIMIZE TABLE to defragment tables for better performance MySQL started within last 24 hours - recommendations may be inaccurate Enable the slow query log to troubleshoot bad queries Adjust your join queries to always utilize indexes When making adjustments, make tmp_table_size/max_heap_table_size equal Reduce your SELECT DISTINCT queries without LIMIT clauses 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) tmp_table_size (> 32M) max_heap_table_size (> 16M) thread_cache_size (start at 4) table_cache (> 64) Rien de catastophique, mais il faudras faire plus que modifier le fichier de conf. Tu ne caches rien parce que le résultat de tes requêtes est trop gros. Dans le cadre de traitement batch, cela peut arriver. Dans le cadre d'une appli web, ce n'est pas normal - comprendre erreur de conception, par exemple l'initialisation systématique de combo-box... - ; d'où la recommandation d'utiliser LIMIT. De plus, il a identifié des jointures qui n'utilisent pas les index; catastrophiques en termes de perfs => produit cartésien : une tables de 100.000 lignes associées à une tables de 1000 lignes, va te générer un parcours de 100.000.000 lignes, exécuter les clauses Where lignes à lignes, stocker le résultat dans une table de travail et te renvoyer le résultat... Bref, MySql passe son temps à créer des tables temporaires de travail sur disque, puis les efface puisque le résultat est trop gros pour être caché. La prochaine requête arrive et rebelotte... Je te suggère une intervention rapide paliative sur les paramètres indiqués, suivi plus tard d'une intervention curative et d'un réajustement de ces paramètres. Etape 1 : modifier les variables indiquées /etc/mysql/my.cnf Utilise le double des valeurs indiquées, sauf table_cache : 4096 Ajoutes les lignes skip-bdb log-slow-queries = /var/log/mysql/mysql-slow.log long_query_time = 1 Vérifies que le parametre log est en commentaire ou inexistant : #log = /var/log/mysql/mysql.log et que les log binaires sont actifs : log-bin = /var/log/mysql/mysql-bin.log et relances Mysql Laisser chauffer l'ensemble quelques heures... Etape 2 : Mettre le bout des doigts dans le cambouis : ajuster tes requêtes SQL 1. Le plus simple est de créer les index qui manquent pour les jointures entre tables. Commences par les requêtes lentes identifiées par Mysql dans le log /var/log/mysql/mysql-slow.log Puis listes les autres requêtes SQL dans ton code qui utilisent plusieurs tables et les tables "moyennes" > 10.000 lignes Connectes toi à Mysql via la console, 'mysql' ou installes l'outil web phpmyadmin plus convivial Dans la suite, je parle de commande en mode console. Pour chaque requete, execute un EXPLAIN "requeteSQL" ; Notes les requetes et les tables associées dont la colonne "possible_keys" est à null avec la colonne "rows" > 500 Pour celles-ci, fait un explain sur les tables : Explain "tables"; La structure de la table s'affiche. Identifier les colonnes utilisées pour les jointures et créer les index manquants. alter table add index (col_sans_index); Pour l'aide en ligne : help alter table 2. Identifier les requetes qui font des select sans clause limit sur des tables de plus de 100 lignes. Controler que tu as besoin de l'ensemble de ces données. Si tu n'a besoin que des 10 1er résultats, ajouter "limit 10" à la requete. Si tu as besoin de tout, tu as "probablement" un pb général de modèle de données. Et donc une grosse maintenance de structure, du code et de tes écrans seront à envisager. Tu laisses chauffer le résultat quelques jours, tu relances mysqltuner et tu réajustes les paramètres my.cnf NB: Au travers de ces conseils, on reste sur une approche inversée de l'optimisation. Tu travailles sur la partie la plus complexe et globalement la moins efficace. Je m'explique : - le pb est il pourquoi tes requetes sont lentes ? - le pb est il pourquoi ton application les exécute aussi souvent ? - le pb ne serait-il pas comment éviter que les internautes sollicitent aussi souvent ton application ? Même si toutes ces étapes sont importantes, tu régleras 80% de ton pb sur le dernier point. Par contre, dans ton article, zebx, tu dis : "utiliser ses applications plusieurs heures" : il est possible de faire tourner le script automatiquement plusieurs heures ? Comment faire ? Je parle de ton application, pas de Mysqltuner. Laisses tes visiteurs faire le travail durant 2 jours. Relance le script, les conseils peuvent varier. En dehors de MySQL, tu peux activer le profiling PHP avec le mod xdebug et optimiser les bouts de code les plus consommateurs. Modifié 8 Janvier 2009 par zebx
seeps24 Posté 9 Janvier 2009 Auteur Posté 9 Janvier 2009 J'ai un petit problème : Lorsque j'ouvre my.cnf, je pensais trouver des variables pour les ajuster, mais je trouve ceci : [mysqld] set-variable=local-infile=0 datadir=/var/lib/mysql socket=/var/lib/mysql/mysql.sock # Default to using old password format for compatibility with mysql 3.x # clients (those using the mysqlclient10 compatibility package). old_passwords=1 [mysql.server] user=mysql basedir=/var/lib [mysqld_safe] log-error=/var/log/mysqld.log pid-file=/var/run/mysqld/mysqld.pid Comment puis je modifier les paramètres alors ? :s (j'ai jeté un oeil dans /var/lib/mysql/ sans trouver.
TrocWeb Posté 9 Janvier 2009 Posté 9 Janvier 2009 ton my.cnf est surement d'origine, il faut donc rajouter les lignes manquantes a tu recherché pour te donner une idée le: my-large dans les dossier du serveur sur les conseil de Dan j'avais réglé en gros mes problèmes sur mon ancien serveur qui ramé tu devrais aller jeter un coup d'il a mon post il va t'éclairer je pense voir ici courage avec un peut de persévérance tu va y arriver
seeps24 Posté 10 Janvier 2009 Auteur Posté 10 Janvier 2009 (modifié) Merci de ton aide ! Alors maintenant, j'ai modifié mon fichier my-large en ajoutant les variables qu'il y avait dans my.cnf et qui n'étaient pas dans my-large. J'ai ajouté aussi les variables que me donnait Tuner. Voici ce que j'obtiens, j'ai encore rien modifier, j'attends votre "feu vert" # The following options will be passed to all MySQL clients[client]#password = your_passwordport = 3306socket = /var/lib/mysql/mysql.sock# Infos du premier my.cnf[mysqld]set-variable=local-infile=0datadir=/var/lib/mysql# Default to using old password format for compatibility with mysql 3.x# clients (those using the mysqlclient10 compatibility package).old_passwords=1# Info du fichier my-large et tunerport = 3306skip-lockingkey_buffer = 256Mmax_allowed_packet = 1Mtable_cache = 256sort_buffer_size = 1Mread_buffer_size = 1Mread_rnd_buffer_size = 4Mmyisam_sort_buffer_size = 64Mthread_cache_size = 8query_cache_size= 16M# Try number of CPU's*2 for thread_concurrencythread_concurrency = 8# Infos rajoutées grâce à mysqlTunermax_connections= 200wait_timeout= 14400interactive_timeout= 14400query_cache_size= 16Mjoin_buffer_size= 128tmp_table_size= 64Mmax_heap_table_size= 32Mthread_cache_size= 4table_cache= 128# Replication Master Server (default)# binary logging is required for replicationlog-bin=mysql-bin# required unique id between 1 and 2^32 - 1# defaults to 1 if master-host is not set# but will not function as a master if omittedserver-id = 1# Infos du fichier my.cnf[mysql.server]user=mysqlbasedir=/var/lib# Infos du fichier my.cnf[mysqld_safe]log-error=/var/log/mysqld.logpid-file=/var/run/mysqld/mysqld.pid[mysqldump]quickmax_allowed_packet = 16M[mysql]no-auto-rehash# Remove the next comment character if you are not familiar with SQL#safe-updates[isamchk]key_buffer = 128Msort_buffer_size = 128Mread_buffer = 2Mwrite_buffer = 2M[myisamchk]key_buffer = 128Msort_buffer_size = 128Mread_buffer = 2Mwrite_buffer = 2M[mysqlhotcopy]interactive-timeout J'ai retiré toutes les notes inutiles. Vous trouvez ce que j'ai ajouté : # Infos du fichier my.cnf # Infos rajoutées grâce à mysqlTuner # Infos du premier my.cnf Pour les variables de Mysqltuner, j'ai doublé les variables données comme Dan l'a précisé. Qu'en pensez vous ? Merci, on est sur la bonne voie ! Modifié 10 Janvier 2009 par seeps24
Kioob Posté 10 Janvier 2009 Posté 10 Janvier 2009 # Try number of CPU's*2 for thread_concurrencythread_concurrency = 8 C'est moi qui ne sait pas compter, ou bien tu n'as même pas lu les quelques commentaires du fichier de config ?
seeps24 Posté 10 Janvier 2009 Auteur Posté 10 Janvier 2009 Je ne sais pas, qu'est ce que le CPU ? Charge CPU : 86 % ?
seeps24 Posté 10 Janvier 2009 Auteur Posté 10 Janvier 2009 (modifié) Merci Kioob de ton aide, et désolé de pas savoir. Si je demande c'est que je sais pas ... on peut ne pas savoir ! Si je suis la c'est pour apprendre. Maintenant je sais que CPU = processeur. Bon sinon pour le reste, qu'en pensez vous ? Modifié 10 Janvier 2009 par seeps24
Kioob Posté 10 Janvier 2009 Posté 10 Janvier 2009 Oui oui, c'est juste que je ne pensais pas que tu "partais de si loin". Sinon je ne crois pas qu'on aurait essayé de te faire faire ça tout seul. Pour le reste bah, ça reste un fichier de configuration d'exemple quoi...
seeps24 Posté 10 Janvier 2009 Auteur Posté 10 Janvier 2009 (modifié) Ok merci Kioob. Je pars de si loin si car je n'ai AUCUNE connaissance en matière de serveur ou d'informatique "dur". Par contre j'avais oublié quelques trucs que j'ai rajouté ou changé : Selon les recommandations de zebx : table_cache= 4096 skip-bdb (ça je ne comprend pas ce que c'est) log-slow-queries = /var/log/mysql/mysql-slow.log long_query_time = 1 log-bin = /var/log/mysql/mysql-bin.log Modifié 10 Janvier 2009 par seeps24
Kioob Posté 10 Janvier 2009 Posté 10 Janvier 2009 Quelques remarques : - les différents logs peuvent être utiles oui. Mais si la "rotation des logs" qui va avec n'est pas active sur la machine, tu vas saturer l'espace disque ce qui risque d'avoir de vilains effets de bord. => donc à vérifier. - le "skip-bdb" désactive un des moteurs de stockage de MySQL. "mysqltuner" te l'a conseillé car tu ne t'en sert pas. Ce moteur est peu répandu donc ce n'est vraiment pas génant. - pour le "table cache", bah c'est une valeur un peu au "pifomètre". Elle peut être largement sous ou sur estimée.
seeps24 Posté 10 Janvier 2009 Auteur Posté 10 Janvier 2009 (modifié) Merci encore. J'ai vérifié et apparemment, le rotation est activée (elle l'est pour les logs d'erreurs sur le serveur, alors j'ose espérer que c'est aussi bon pour ça). Je vais faire les modifications sur mon fichier my déjà, et regarder un peu quelles sont mes requêtes longues. Modifié 10 Janvier 2009 par seeps24
Kioob Posté 10 Janvier 2009 Posté 10 Janvier 2009 Bah justement pas forcément. Chaque fichier à "faire tourner" doit être déclaré.
Poulpix Posté 11 Janvier 2009 Posté 11 Janvier 2009 Bonjour, Il serait judicieux de jeter un oeil à la configuration du serveur HTTP (Apache ?) également. Un gros travail d'optimisation des requêtes MySQL, et des scripts PHP peut être aussi très bénéfique !
Kioob Posté 11 Janvier 2009 Posté 11 Janvier 2009 Ce n'est que mon avis, mais je trouve généralement plus judicieux de regarder ce qui ne va pas avant de chercher à tout modifier. => trifouiller le moteur de la voiture alors que les problèmes viennent d'un pneu crevé, ça risque d'apporter plus de problèmes que de solutions.
seeps24 Posté 15 Janvier 2009 Auteur Posté 15 Janvier 2009 Bon, j'ai créé le fichier mysql-slow.log dans /var/log/ et j'ai mi ca dans mon fichier my.cnf : log_slow_queries = /var/log/mysql-slow.log long_query_time = 5 log-queries-not-using-indexes Ceci dit, rien de rien ne se passe, le fichier log ne se rempli pas, rien ...
Sujets conseillés
Veuillez vous connecter pour commenter
Vous pourrez laisser un commentaire après vous êtes connecté.
Connectez-vous maintenant