Aller au contenu

Sujets conseillés

  • Réponses 57
  • Créé
  • Dernière réponse

Contributeurs actifs dans ce sujet

Contributeurs actifs dans ce sujet

Posté (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é par zebx
Posté (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é par seeps24
Posté

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 :)

Posté
É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" :D

Posté

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.

Posté

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é".

Posté (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é par zebx
Posté

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.

Posté

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

Posté (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_password
port = 3306
socket = /var/lib/mysql/mysql.sock


# Infos du premier my.cnf
[mysqld]
set-variable=local-infile=0
datadir=/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 tuner
port = 3306
skip-locking
key_buffer = 256M
max_allowed_packet = 1M
table_cache = 256
sort_buffer_size = 1M
read_buffer_size = 1M
read_rnd_buffer_size = 4M
myisam_sort_buffer_size = 64M
thread_cache_size = 8
query_cache_size= 16M
# Try number of CPU's*2 for thread_concurrency
thread_concurrency = 8

# Infos rajoutées grâce à mysqlTuner
max_connections= 200
wait_timeout= 14400
interactive_timeout= 14400
query_cache_size= 16M
join_buffer_size= 128
tmp_table_size= 64M
max_heap_table_size= 32M
thread_cache_size= 4
table_cache= 128


# Replication Master Server (default)
# binary logging is required for replication
log-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 omitted
server-id = 1


# Infos du fichier my.cnf
[mysql.server]
user=mysql
basedir=/var/lib

# Infos du fichier my.cnf
[mysqld_safe]
log-error=/var/log/mysqld.log
pid-file=/var/run/mysqld/mysqld.pid


[mysqldump]
quick
max_allowed_packet = 16M

[mysql]
no-auto-rehash
# Remove the next comment character if you are not familiar with SQL
#safe-updates

[isamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_buffer = 2M

[myisamchk]
key_buffer = 128M
sort_buffer_size = 128M
read_buffer = 2M
write_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é par seeps24
Posté

# Try number of CPU's*2 for thread_concurrency
thread_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 ?

Posté (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é par seeps24
Posté

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...

Posté (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é par seeps24
Posté

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.

Posté (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é par seeps24
Posté

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 !

Posté

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.

Posté

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 ...

Veuillez vous connecter pour commenter

Vous pourrez laisser un commentaire après vous êtes connecté.



Connectez-vous maintenant

×
×
  • Créer...