Je ne sais véritablement pas ce qui se passe. Mais ma base Spip me met une charge très importante sur mon serveur. En fait, ce serveur n’est dédié qu’à un seul site et, même s’il est vrai que c’est un site moyennement gros, presque 250 000 pages lues par jour, le serveur devrait pouvoir supporter les demandes.
La charge du CPU passe souvent de 8 ou 9% à plus de 1480%. Oui oui, mille quatre cent quatre vingt pour cent.
Quelqu’un a t-il une idée de la manière de « troubleshooter » le problème?
Que dises les log du serveur?
Il faudrait identifier la boucle qui fait chauffer le CPU pour pouvoir vous aidez.
----------
Ybbet
Le 13 juin 2014 à 16:10, Jules Yansa <jyansa@camfoot.com> a écrit :
Bonjour à tous,
Je ne sais véritablement pas ce qui se passe. Mais ma base Spip me met une charge très importante sur mon serveur. En fait, ce serveur n'est dédié qu'à un seul site et, même s'il est vrai que c'est un site moyennement gros, presque 250 000 pages lues par jour, le serveur devrait pouvoir supporter les demandes.
La charge du CPU passe souvent de 8 ou 9% à plus de 1480%. Oui oui, mille quatre cent quatre vingt pour cent.
Quelqu'un a t-il une idée de la manière de "troubleshooter" le problème?
Merci d'avance.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net
si serveur dédié ( LAMP ? ), tu peux potentiellement y faire ce que tu
veux. Donc pour voir d’où peut venir le problème, il est intéressant de
grapher un certain nombre de paramètres qui indiquent l'état de santé de
ton serveur :
- charge
- ram dispo
- nombre de hits apache
- nombre de connexions TCP ouvertes
- nombre de requêtes sql/secondes, états des cache etc.
Ces indications sont précieuses pour voir ce qui se passe sur la machine
et plus bas sur les différents démons.
Ensuite, tu peux ( si Linux ), tu peux employer dstat pour afficher pas
mal de choses en temps réel.
Genre : dstat -tdcnr -D total -N total --tcp
En passant, ce genre de choses peut provenir d'un mauvais
refroidissement: les cpu Intel ( pas sur pour AMD ) sautent des cycles
quand ils ont trop chaud, ce qui fait exploser la charge. On trouve dans
ce cas ds messages dans les logs genre "cpu throttling" ou un truc dans
ce goût.
si serveur dédié ( LAMP ? ), tu peux potentiellement y faire ce que tu
veux. Donc pour voir d’où peut venir le problème, il est intéressant de
grapher un certain nombre de paramètres qui indiquent l'état de santé de
ton serveur :
- charge
- ram dispo
- nombre de hits apache
- nombre de connexions TCP ouvertes
- nombre de requêtes sql/secondes, états des cache etc.
Ces indications sont précieuses pour voir ce qui se passe sur la machine
et plus bas sur les différents démons.
Ensuite, tu peux ( si Linux ), tu peux employer dstat pour afficher pas
mal de choses en temps réel.
Genre : dstat -tdcnr -D total -N total --tcp
En passant, ce genre de choses peut provenir d'un mauvais
refroidissement: les cpu Intel ( pas sur pour AMD ) sautent des cycles
quand ils ont trop chaud, ce qui fait exploser la charge. On trouve dans
ce cas ds messages dans les logs genre "cpu throttling" ou un truc dans
ce goût.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net
Ça peut aussi venir d'une mauvaise configuration de mysql, d'un disque faiblard sur lequel traînerait des fichiers InnoDB ou de tout un tas de choses. Personnellement, j'ai toujours constaté des problèmes de montée de charge de mysql qui est à des lieux de ce que peut faire un postgre.
Par défaut, certaines versions de MySQL exécutent des tâches internes à intervalle très court et j'ai constaté sur l'un de mes serveurs des pics de charge toutes les cinq minutes (avec une tâche qui prenait quelques dizaines de secondes sur des données de cartographie qui ne changent _jamais_).
Personnellement, je serais très intéressé par tester le support de PostGre dans SPIP...
Je rajouterais 2 choses spécifiques à mysql:
Tracer les slow query:
[mysqld]
log_slow_queries = /var/log/mysql/mysql-slow.log
long_query_time = 2
Et pourquoi pas un tit mytop.
Auquel on peux ajouter: mysqltuner (dispo dans les dépots debian) pour
voir qu'est ce qui dit.
Denis
Le 13/06/2014 16:24, Vincent a écrit :
Bonjour,
si serveur dédié ( LAMP ? ), tu peux potentiellement y faire ce que tu
veux. Donc pour voir d’où peut venir le problème, il est intéressant de
grapher un certain nombre de paramètres qui indiquent l'état de santé de
ton serveur :
- charge
- ram dispo
- nombre de hits apache
- nombre de connexions TCP ouvertes
- nombre de requêtes sql/secondes, états des cache etc.
Ces indications sont précieuses pour voir ce qui se passe sur la machine
et plus bas sur les différents démons.
Ensuite, tu peux ( si Linux ), tu peux employer dstat pour afficher pas
mal de choses en temps réel.
Genre : dstat -tdcnr -D total -N total --tcp
En passant, ce genre de choses peut provenir d'un mauvais
refroidissement: les cpu Intel ( pas sur pour AMD ) sautent des cycles
quand ils ont trop chaud, ce qui fait exploser la charge. On trouve dans
ce cas ds messages dans les logs genre "cpu throttling" ou un truc dans
ce goût.
_______________________________________________
liste spip
spip@rezo.net - désabonnement : envoyer un mail à spip-off@rezo.net