Question charge serveur (load average)

[Recif]

Bonjour,

Je croyais que la valeur du load average était liée au nombre de proccesseurs de la machine... Mais en ce moment ça ne colle pas du tout... J'ai un serveur bi processeur quadcore, donc 8 proc logiques. Sur un linux.
Lorsque ej fais un "top", j'ai 8 de load verage et 33% de idle... Et le serveur ne ramme pas... Hors il y a bien une valeur de 1 par processeur non?...

 

[Julia41]

Le load n'a rien à voir avec le nombre de process lancé.
Tu peux installer htop pour voir "plus graphiquement".
Mais bon là ton serveur "ramme" même si ça ne se voit pas.
Le load average reprends beaucoup d'informations de la machine et compile cela en une valeur unique.
Je serais curieux de savoir ce que c'est comme site
Un joomla ou un wordpress avec pleins de plugins ?

Edit: En passant, pour que MySQL load autant c'est qu'il manque généralement des indexes. Bon ça peut aussi être énormément de connexions mais vu les process apache ça semble être ça. (ou alors des requêtes très complexes).

 

[Recif]

Merci.
En fait je n'ai jamais dit que ça correspondait au nombre de process lancés, mais au nombre de processeurs logiques (CPUs)
Par contre sur mes graphes Munin je dépasse pas le 500% sur 800% dispo...

 

[Julia41]

Merci.
En fait je n'ai jamais dit que ça correspondait au nombre de process lancés, mais au nombre de processeurs logiques (CPUs)
Par contre sur mes graphes Munin je dépasse pas le 500% sur 800% dispo...

C'est quand même "beaucoup". Pour être "optimal" faudrait "jamais" dépasser les 60% "total" (480% dans ton cas).

Bon par contre soit ton site est lourd soit tu as des trucs bloquant niveau requête SQL, je pense que t'as des bons trucs à rajouter. Un "log queries not using indexes" pourrait être pas mal pour voir si tu peux faire des bons petits trucs, des fois un simple INDEX fait passer la conso CPU de 100% à 0%. En installant APC tu ferais gagner pas mal aussi.

 

[Recif]

Ok, je ne connais pas "log queries not using indexes", c'est une appli à installer? Idem pour APC?
Merci

 

[Julia41]

Ok, je ne connais pas "log queries not using indexes", c'est une appli à installer? Idem pour APC?
Merci

Pour le "log queries not using indexes" c'est une option de MySQL (à mettre dans ton my.cnf):

log_slow_queries        = /var/log/mysql/mysql-slow.log
long_query_time = 5
log-queries-not-using-indexes

Pour APC sous Debian:

apt-get install php5-apc && /etc/init.d/apache2 restart

Sur un phpmyadmin (par exemple) APC donne ça :

Sans APC : Requests per second: 148.87 [#/sec] (mean)
Avec APC : Requests per second: 503.18 [#/sec] (mean)
Avec APC & Sans Suhosin : Requests per second: 563.98 [#/sec] (mean)

Pour un joomla avec pas mal de module :
Sans APC : Requests per second: 11.30 [#/sec] (mean)
Avec APC : Requests per second: 22.64 [#/sec] (mean)

=> Requests per second = nombre de requête acceptées par seconde et répondu en code 200 par le serveur.

 

[Recif]

Ouïe... J'ai mis le log-queries-not-using-indexes et je dois avoir un fichier qui grossi de 20ko toute les secondes! J'ai arrêté de suite... Le problème c'est qu'il logue vraiment tout et que certaines requêtes loguées ne sont pas pertinentes. Apparemment il ne considère pas le primary index comme un index... Bizarre...

 

[Julia41]

Ouïe... J'ai mis le log-queries-not-using-indexes et je dois avoir un fichier qui grossi de 20ko toute les secondes! J'ai arrêté de suite... Le problème c'est qu'il logue vraiment tout et que certaines requêtes loguées ne sont pas pertinentes. Apparemment il ne considère pas le primary index comme un index... Bizarre...

Il faut faire des EXPLAIN sur chaque requête qui est logué.
Sur les sites avec beaucoup de "bad queries" et beaucoup de visites je log 10 minutes la nuit et ça fait de quoi bosser pour quelques jours.

C/C ici des exemples de EXPLAIN <ta requête> ça donnera des bonnes idées je pense.

 

[Recif]

Qu'appelles tu des "explain"?

 

[Julia41]

Requête :

SELECT * FROM as_blog LIMIT 1;
// output ici

Explain:

EXPLAIN SELECT * FROM as_blog LIMIT 1;
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
| id | select_type | table   | type | possible_keys | key  | key_len | ref  | rows | Extra |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+
|  1 | SIMPLE      | as_blog | ALL  | NULL          | NULL | NULL    | NULL |   94 |       |
+----+-------------+---------+------+---------------+------+---------+------+------+-------+

Pas d'INDEX mais normal car pas de WHERE.

EXPLAIN SELECT ID FROM as_blog LIMIT 1;
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
| id | select_type | table   | type  | possible_keys | key     | key_len | ref  | rows | Extra       |
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+
|  1 | SIMPLE      | as_blog | index | NULL          | PRIMARY | 8       | NULL |   94 | Using index |
+----+-------------+---------+-------+---------------+---------+---------+------+------+-------------+

Là on voit que c'est bon.

 

[Recif]

Ca veut dire qu'il faut modifier le code des requêtes dans les scripts php?... J'ai peur...

 

[Julia41]

Ca veut dire qu'il faut modifier le code des requêtes dans les scripts php?... J'ai peur...

Non, créer des INDEX SQL si pas présent mais bon, c'est pas non plus obligatoire je te donnais des pistes, file nous des EXPLAIN on pourra te dire si ça peut aider ou non, vu le load de ton MySQL d'après ton top je pense qu'ils y a des trucs à faire (sauf si tu as des LIKE partout)

 

[Recif]

Euh.. Désolé mais je sais pas comment te donner des "expliqn". Je dois faire quoi concrêtement?
Pour les likes en effet j'ai quelques grosses requêtes comme ça, mais c'est loin d'être généralisé. Par contre peut être qu'en effet ce sont celles ci qui pénalisent.

 

[Julia41]

pour les EXPLAIN tu tappes ça en SSH (connecté à MySQL bien entendu) ou simplement dans PHPMyAdmin (le bouton "expliquer SQL")

 

[Recif]

Je ne trouve pas le bouton "expliquer SQL" dans phpmyadmin

 

[Julia41]

Dans ce cas écris ta requête (que tu as dans tes "not using index" log) et précède là de "EXPLAIN SELECT..".
Enfin bon, je pensais (vu que tu avais des bases de SSH) que tu aurais géré ça (j'espère que tu ne verras rien de vexant dans mes propos) là je pense que c'est peut-être un niveau au dessus.

 

[Recif]

Non, le SSH c'est trop mon dada, je suis développeur de sites web, pas admin serveur. Mais bon, je suis obligé de toucher un peu au serveur de temps en temps... Pas le choix...
Le problème de mettre explain dans les requêtes qui ont été loguées, c'est que tout et n'importe quoi a été logué, donc ça serait un peu fastidieux de toutes les faire...

 

[Julia41]

Il faut en faire quelques unes, si tu es développeur tu devrais pouvoir voir celles qui sont le plus souvent utilisées.
Celles-ci tu les tappes dans PHPMyAdmin (onglet "SQL") avec un EXPLAIN devant (si tu le tappes pas, PHPMyAdmin propose généralement de "expliquer SQL"). Avec ça tu pourras voir si tu as oublié un INDEX "grossier" (rien de méchant là dedans).
Mon dernier exemple date d'il y a 10 minutes. Un rewrite sur un truc du genre /user/<pseudo ici>
Le <pseudo> n'avait pas d'INDEX, avec un UNIQ dessus, le load du serveur est passé de 0.6 à 0.1.

 

[Recif]

Non, sincèrement je ne pourrais pas dire celles qui sont le plus utilisées, il y en a vraiment, mais vraiment beaucoup...

 

[Julia41]

Non, sincèrement je ne pourrais pas dire celles qui sont le plus utilisées, il y en a vraiment, mais vraiment beaucoup...

Pas grave tu en prends une au hasard et tu la taffs
si tu veux trier "en gros" tu fais (sur ton fichier de log):
cat mysql/mysql-slow.log|grep "SELECT" | sort | uniq -c| sort -n > temp.txt
Dans ton fichier temps, à la fin tu auras ta requête la plus utilisée (donc celle à améliorer en priorité). (Bon, il faut aussi que ce soit des requêtes en une ligne)

 

[Recif]

Ok, j'ai pris le log d'hier. J'ai fais un explain sur la plus grosse requête même si ça m'éatonne que cette dernière soit responsable du problème, mais voici:

Requête :

SELECT code_html FROM xx_banner ORDER BY RAND() LIMIT 1

Résultat:

id  select_type  table  type  possible_keys  key  key_len  ref  rows  Extra  
1 SIMPLE xx_banner ALL NULL NULL NULL NULL 28 Using temporary; Using filesort

 

[Julia41]

Arf, les RAND c'est pas INDEXable.
Bon, par contre t''as pas l'air d'avoir d'INDEX sur "code_html" mais ça doit être du full TEXT.

Genre de truc à mettre en cache ou faire le RAND en PHP.

 

[Recif]

J'ai regardé le log mysql-slow d'aujourd'hui et il n'y a quasiment rien dedans... Je commence à me demander si c'est bien MySQL... D'ailleur dans le "top" sous ssh il y a en ce moment plus souvent des process Apache en tête que MySQL...

 

[Julia41]

Est-ce que tu as installé APC ?

Edit: et après c'est aussi possible que ton site "consomme".

 

[Recif]

Actuellement

 

[Recif]

Non, pas de APC, il me semble qu'il y a déjà un cache MySQL, j'ai pas trop envie de faire tomber le serveur...

 

[Recif]

J'ai des graphes Munin, peut être y en a t-il un qui parlerait?...

 

[Julia41]

Non, pas de APC, il me semble qu'il y a déjà un cache MySQL, j'ai pas trop envie de faire tomber le serveur...

Dans ce cas là tu n'as rien compris
Ca fera l'inverse que de faire tomber le serveur.

Ton MySQL consomme toujours pas mal, mais c'est bien PHP qui bouffe.

Bon, je t'ai filé des pistes en vrac et à l'aveugle, mais déjà installe APC ça coute rien.

 

[Recif]

-bash: apache-top: command not found
de11:/var/log# apt-get install php5-apc
Lecture des listes de paquets... Fait
Construction de l'arbre des dépendances
Lecture des informations d'état... Fait
E: Impossible de trouver le paquet php5-apc