Le Mercredi 02 Novembre 2005 19:03, G(P)L a écrit :
> Francois Sauterey a écrit :
> > J'ai un petit soucis avec un serveur Mysql, et peut-être y aura-t-il ici
> > un spécialiste ?
> > J'ai une machine sous Debian-Sarge qui fait serveur Apache2 hébergeant
> > +/- 500 sites différents dont la moitié à peu près en php/mysql.
> > Une autre (sur un réseau interne en 100M) est le serveur Mysql.
> > Cette dernière, toujours debian-Sarge, 512Mo de mem, refuse régulièrement
> > les connexions.
> > (un mysqladmin ping en boucle [pas de 5 secondes] donne en gros un refus
> > par minute]
> > Je cherche à optimiser les (nombreux) paramètres de MysqlServer.
> >
> > Ci-joint, mon my.cnf...
> >
> > @micalement,
>
> Bonsoir,
> Il faudrait voir pourquoi la base de données refuse les connexions,
> car si ce sont des sites webs "classiques", ca m'étonne que 500 tables
heu... 500 bases x 50 tables = 25000 tables au total...
> mettent à genoux MySQL. Il faudrait savoir si la saturation vient de la
> mémoire vive, des ressources processeurs, des accès disques, de la
> bande-passante, ...
uptime:
8:49:40 up 12 days, 3:27, 8 users, load average: 0.26, 0.32, 0.23
vmstat (après plusieur étapes effacées):
procs -----------memory---------- ---swap-- -----io----
--system------cpu----
r b swpd free buff cache si so bi bo in cs us sy id wa
0 0 32424 13004 21420 223624 0 0 0 4 265 319 0 1 99 0
Bref pas de swap... on reste dans les 512 Mo (je sais c'est un peu juste...)
La bande passante : réseau à 100Mbs
> La machine ne semble pas répondre à un _ping_ et donc c'est que la
> machine sature sur une ressource et non suite à un timeout créé par un
> MySQL trop long à repondre. Il faut donc voir ce qui crée cette
> saturation matérielle : une requête php/MySQL, une machine
> sous-dimensionnée en RAM ou CPU ?
Machine: Serveyur Dell poweredge 1550 bi proc PIII / 512 Mo
Voilà les stats données par phpmyadmin:
Trafic | ø par heure
Reçu 186 514 Ko | 23 163 Ko
Envoyé 1 156 Mo | 147 045 Ko
Total 1 338 Mo | 170 208 Ko
Connexions | ø par heure | %
Tentatives échouées 6 063 | 752,96 | 13,59 %
Arrêts prématurés 22 | 2,73 |
0,05 %
Total 44 608 | 5 539,84 | 100,00 %
Clairement ~14% des connexion échouent ;~{
Total | ø par heure | ø par minute | ø par seconde
1 259 190 | 156 377,95 | 2 606,30 | 43,44
pour un uptime-mysql de 0 jours, 8 heures, 3 minutes et 8 secondes
> Ensuite on peut voir l'optimisation de MySQL (index des tables pour une
> recherche plus rapide ou quelques commandes indiquées par les autres
> utilisateurs pour optimiser MySQL lui-même, dans son fonctionnement
> interne), mais AMHA il faut regarder la conso moyenne
> (sous-dimensionnement de la machine) et ce qui provoque les saturations
> (peut-être une site web qui a une BD très importante, ou qui héberge un
> script PHP CPUphage).
En fait l'essentiel des sites tourne sous spip...
je peux aussi ajouter:
Max used connections : 10
key buffer size : 402653184
Key blocks used : 142392
Key read requests : 12248752
En espérant que ces renseignements permettront un début de diagnostic ?
@micalement,
--
Francois Sauterey
@: Francois_AT_Sauterey.org
--
Pensez à lire la FAQ de la liste avant de poser une question :
http://wiki.debian.net/?DebianFrench
Pensez à rajouter le mot ``spam'' dans vos champs "From" et "Reply-To:"
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
