Bonjour !
 
Ca fait longtemps que je viens sur Hardware.fr, et je me suis enfin inscrit ^^
J'ai un problème avec mon serveur dédié : il arrive assez souvent que le CPU soit utilisé à 100% et que les pages mettent alors 1 ou 2 minutes à se charger.
En général ce sont les processus mysqld qui pompent tout, mais aussi les httpd.
Vous me direz que c'est peut-être j'ai oublié de mettre des index sur mes tables. Mais pourtant il y en a, et ça rame parfois quand j'ai 130 connectés alors que ça marche impec quand j'en ai 200.
bizarre ...  
 
Alors j'ai pensé que ça pouvait venir de la config de httpd.conf ou de my.cnf
Voici ma config :
début de httpd.conf :

my.cnf :

J'ai rajouté ça dans my.cnf cette nuit, mais je ne sais pas si c'est utile, bien, ou mauvais ^^ :

Pour info j'ai une distribution Debian 3.1 qui tourne sur un Intel(R) Celeron(R) CPU 2.80GHz avec 1 Go de ram (et un BP de 10 Mbps jamais utilisée au max)
 
Si quelqu'un pouvait m'aider...
Merci d'avance  

max_connections=200  
C'est beaucoup ca quand même  
 
Une possibilité ce serait qu'une requête soit très longue a s'exécuter. Pour cela, tu te connectes à MySQL quand ca rame, et tu fais un "SHOW FULL PROCESSLIST" pour voir les requêtes en cours d'exécution  
Il suffit souvent d'une requête longue pour bloquer toutes les autres qui vont s'empiler derrière (si tu as des requêtes de mise à jour)

Ok merci j'essairai ça ;-)
Oui 200 est un peu beaucoup c'est vrai ^^ mais je pense pas que ça puisse gêner. Je vais le mettre à 100
En fait j'ai un serveur xmlsocket de ma fabrication connecté à la base mysql (la connexion se réinitialise toutes les 2 minutes). A chaque fois qu'un membre se déconnecte ça envoit une longue requête UPDATE (avec environ 35 champs) avec une seule clause dans le WHERE : le pseudo du membre.
Je ne sais pas si c'est ça...
Et sinon quelqu'un pourrait me dire si ce que j'ai rajouté dans my.cnf est bon ou pas ?

A mon avis, si ton serveur marche pas bien, il vaut mieux laisser les paramètres par défaut le temps de comprendre ce qui se passe.
Pour la requête, si elle ne met à jour qu'une ligne, elle n'est surement pas très coûteuse (même s'il y a 35 champs). A condition que l'accès à cette ligne soit rapide (index).
Fais un explain de cette requête (tu ajoutes juste le mot "explain" devant la requête, et MySQL t'affiche le plan d'exécution de cette requête, c'est à dire les tables parcourus et les index utilisés )

Ok merci
En ce qui concerne mes index, j'ai des doutes avec ma table de membres : les membres n'ont pas d'id, mais le champ pseudo est en clé primaire.
C'est bon quand même, où c'est mieux en INDEX, ou alors il vaut carrément mieux mettre un id en clé primaire ?

De toute façon, je pense qu'une clé primaire est toujours indexée  
 
Après, le faire sur le pseudo, c'est pas forcément une mauvaise idée