Optimisation/Réglage d'un serveur puissant (2x4C)

[Robinson]

Bonjour,

Je pense louer prochainement un serveur très puissant composé de 2 quadruples coeurs.
Je voulais savoir si ce type de serveur demandait une optimisation spécifique pour utiliser pleinement toute sa puissance.
Je pense à Apache et sa limite de 255 slots (à la base) que l'on devrait pouvoir augmenter sans problème sur ce type de serveur.

Si vous utilisez ce type de serveur et que vous avez des conseils, je suis tout ouïe. Merci.

 

[SpeedAirMan]

Bonjour,

je te suggère de demander sur Webmaster-Hub. Dan, le webmaster héberge son forum sur ce type de machine : HG BIXEON QUADRULE COEUR BI-TURBO

 

[jcaron]

Je pense à Apache et sa limite de 255 slots (à la base) que l'on devrait pouvoir augmenter sans problème sur ce type de serveur.

Il y a plein d'autres paramètres que le nombre de cores qui compte pour déterminer le nombre de processus Apache. Dans de nombreuses configurations dynamiques (c'est le cas avec mod_perl, c'est certainement le cas avec php), c'est plus la RAM qui limite le nombre de processus simultanés. De toutes façons, le réglage optimal est de l'ordre du maximum de temps d'éxécution (total) / temps CPU, pour chaque requête (la différence entre les deux étant le temps passé à attendre des accès disque, des accès BDD, des appels à d'autres serveurs...). Au delà, tu ne fais que rajouter des context switches, donc tu perds en performance (mais tu gagnes évidemment en réactivité si les requêtes ne sont pas très très rapides).

Bref, 8 cores c'est bien mais si tu n'as pas la RAM et/ou les disques qui vont avec ça ne sert pas forcément à grand chose (et c'est plus souvent l'un de ces deux paramètres qui est le goulot d'étranglement, plutôt que le CPU). Et puis il reste à savoir ce que tu fais tourner dessus (Apache uniquement, base de données, et j'en passe).

Jacques.

 

[Robinson]

Merci SpeedAirMan mais malheureusement, Dan ne répond quasiment jamais sur les points techniques à des "nouveaux".

jcaron, le serveur :
12Go RAM
2x147 Go en SAS RAID HARD 1

Je crois qu'on peut difficilement faire plus puissant en une machine... (à l'heure actuelle)

Mon problème actuel avec deux coeurs, c'est bien le CPU, 4Go de RAM me suffisent.

Bref, je veux changer de serveur et en profiter pour tout updater (mysql5, php5...)

Pourquoi un serveur si puissant ? car j'ai les moyens et que je prévoie une augmentation du traffic pour 2008.

 

[FloBaoti]

Salut,

Simple question comme ça: pourquoi utiliser une machine si puissante? Tu as une utilisation spécifique qui nécessite celà?
Parce que c'est toujours mieux de prendre justement plusieurs machines moins puissantes. Genre tu prend 3 serveurs, 2 frontaux web et une base de donnée, c'est toujours mieux selon moi.
Certes il faut 3 fois plus de temps pour s'en occuper, mais quand un tombe en panne, ça ne coupe pas tout quoi...

 

[Robinson]

Il est plus facile et rapide de s'occuper d'un seul serveur. Surtout quand on n'est pas un expert dans le domaine et qu'on apprend sur le tas. Mais je ne repousse pas l'idée de passer sur plusieurs serveurs un jour.

Niveau pannes, je dois certainement toucher du bois, aucune grosse panne depuis deux ans que je suis sur serveur dédié. Aucune tentative de piratage (ou presque, un ptit phishing seulement), aucune attaque...

Mes seuls soucis ont été au niveau de l'optimisation et de la charge du serveur.

 

[Stellvia]

Salut robinson

Mets mysql sur un autre dédié , meme un petit , tu verra comme ca va soulager ton serveur principal , c'est incroyable ( ca prend 2 min il suffit de mettre l'ip du dédié distant au lieu de localhost , et autoriser l'ip sur le dédié distant )

J'avais le meme soucis que toi , et mon serveur ramais uniquement a cause des acces sql , je ne me rendais pas compte a quel point ca plombais un dédié , meme une grosse bécanne .

Depuis ce changement c'est le jour et la nuit .

 

[jcaron]

jcaron, le serveur :
12Go RAM
2x147 Go en SAS RAID HARD 1

Je crois qu'on peut difficilement faire plus puissant en une machine... (à l'heure actuelle)

Ah... J'ai quelques machines avec 16 Go de RAM et 17 disques durs, et j'en connais qui ont des machines avec des dizaines de Go de RAM et des dizaines de disques durs...

Mon problème actuel avec deux coeurs, c'est bien le CPU, 4Go de RAM me suffisent.

Ca veut dire que tu supervises l'utilisation CPU, le swap, le taux de swap, les accès disques, et que tu sais où est le goulot d'étranglement, donc?

Note aussi que si tu passes de 1 ou 2 cores à 8, et que tu te dis que tu peux donc avoir 4 à 8 fois plus de processus, ça veut aussi dire qu'il te faudrait 4 à 8 fois plus de RAM (or là tu n'as fait que x3). Si tu augmentes trop le nombre de processus Apache par exemple, tu risques de te mettre à swapper, et ce sera contre-productif.

Pourquoi un serveur si puissant ? car j'ai les moyens et que je prévoie une augmentation du traffic pour 2008.

Il n'est pas toujours facile de décider où va être le goulot d'étranglement lors d'une augmentation de trafic. Par exemple, une augmentation du trafic peut impliquer une augmentation de la taille de la base de données (et surtout de sa partie fréquemment utilisée), qui peut alors ne plus tenir en cache en RAM, et faire exploser les accès disques...

Comme déjà dit par d'autres, il est souvent judicieux d'avoir des machines dédiées à divers usages, ne serait-ce que parce que c'est mieux pour les caches L1/L2/L3 des processeurs, mais aussi parce que c'est plus simple de décider qui utilise quoi (en particulier la RAM). Mais avant de prendre une décision, l'important c'est de suivre avec précision la charge des machines (CPU, swap, I/O disques) et de les grapher sur la durée, pour savoir ce qui est le plus proche de la saturation (ou qui sature déjà!).

Ceci dit, je crois bien que ton choix est déjà fait, et que tu veux des indices pour configurer ça au mieux... Il serait judicieux de nous dire ce que ça donne à l'heure actuelle (taille et nombre des processus apache, par exemple).

Et evidemment, le fait de changer de version de certaines applis peut conduire à un besoin de RAM plus important...

Jacques.

 

[Robinson]

jcaron, le nombre de disques durs n'a aucun rapport avec la puissance du serveur...
16Go de RAM oui je connais mais les tarifs sont disons-le... euuuh assez différent

Le goulot d'étranglement est au niveau mysql qui consomme 99% du CPU. Avant le passage sur ce serveur il y avait plusieurs processus mysql et le problème était la RAM (2Go à l'époque), depuis qu'il n'y a plus qu'un processus mysql, le CPU encaisse tout et je n'ai trouvé aucune solution.

J'augmente par 4 le CPU et par 3 la RAM car actuellement au niveau RAM, celle-ci est utilisée au 3/4 donc cela devrait s'équilibrer.
De plus, je ne pense pas avoir besoin d'un serveur si puissant pour 2008 (4 coeurs, 8Go pourraient me suffire) mais changer de serveur fréquemment (tous les ans) ne me plaît guère.
L'actuel ne me suffit pas et m'a déjà obligé à transférer le forum sur une dédibox qui a déjà du mal à le supporter aux heures de pointes (PunBB). Ce déménagement m'a fait gagner du temps mais maintenant le serveur commence à être limite pour le site seul.

Le problème de mon site (jeu en ligne) sont les heures de pointes qui doivent représenter 85% du traffic journalier en quelques heures.
Pendant les vacances, c'est plutôt cool, pas d'heures de pointes, c'est assez régulier.

La base de données augmente au fur et à mesure même si le traffic est stable (44 millions d'enregistrements, 2.9Go).

Je sais qu'il est sans doute possible d'optimiser davantage le serveur mais je n'en ai pas les compétences et n'ai pas trouvé de personnes pouvant m'étudier cela précisément. (j'ai failli payer pour une optimisation et mise à jour mysql par l'entreprise elle-même, mais disons que leurs tarifs m'ont un peu fait renoncer )

Je t'envoie en mp le lien des graphs mais tu te rendra compte réellement des problèmes qu'à partir de demain soir où le traffic devrait être assez fort. Merci.

 

[jcaron]

jcaron, le nombre de disques durs n'a aucun rapport avec la puissance du serveur...

Tout dépend où est donc goulot d'étranglement. Si tu as besoin de beaucoup d'accès disques, c'est le nombre de disques (et leur temps d'accès) qui prime.

Le goulot d'étranglement est au niveau mysql qui consomme 99% du CPU.

Pas un grand pro de mysql (on est plutôt postgresql chez nous), mais un serveur de base de données qui utilise beaucoup de CPU c'est inhabituel. Même si tu as toute ta base en RAM et que tu ne consommes que du CPU et pas d'accès disque, il faut vraiment forcer pour bouffer autant de CPU, à moins que tu aies des requêtes mal optimisées. Malheureusement autant je pourrais te donner beaucoup de conseils de ce point de vue pour postgresql, autant pour mysql je n'en sais trop rien (mais il te manque peut-être des index, ou tu as des collations peu pertinentes, par exemple). Je ne sais pas par exemple si avec mysql il y a des opérations de "nettoyage" des tables à faire (l'équivalent du vacuum de postgresql)?

Avant le passage sur ce serveur il y avait plusieurs processus mysql et le problème était la RAM (2Go à l'époque), depuis qu'il n'y a plus qu'un processus mysql, le CPU encaisse tout et je n'ai trouvé aucune solution.

Je pense qu'il doit y avoir des mailing-lists ou forums dédiés à mysql où tu devrais poser ce genre de questions. Ta base de données ne devrait pas consommer plus de CPU que tes applis web!

J'augmente par 4 le CPU et par 3 la RAM car actuellement au niveau RAM, celle-ci est utilisée au 3/4 donc cela devrait s'équilibrer.

Je ne sais pas comment tu mesures ça, la notion de RAM utilisée est quelque chose d'horriblement complexe (sachant que la RAM qui n'est pas utilisée pour des processus est utilisée comme cache, normalement toute la RAM est toujours utilisée, et une diminution de la taille du cache peut avoir des conséquences désastreuses).

Le problème de mon site (jeu en ligne) sont les heures de pointes qui doivent représenter 85% du traffic journalier en quelques heures.

Ce sont toujours les pointes qui posent problème à gérer, mais là elles ont l'air assez sauvages tes pointes!

Je t'envoie en mp le lien des graphs mais tu te rendra compte réellement des problèmes qu'à partir de demain soir où le traffic devrait être assez fort. Merci.

Comme indiqué par mp, certains des graphes sont abbérants (1 à 2% de CPU utilisé!), non fonctionnels (accès disques) ou manquants (swap), et d'autres sont peu explicites pour moi (pas l'habitude ni de Linux ni d'OVH, j'utilise FreeBSD sur mes propres machines), donc j'ai du mal à imaginer que tu puisses tirer des conclusions et prendre des décisions avec ça, ou alors j'ai loupé un épisode...

Jacques.

 

[tofm2]

Le goulot d'étranglement est au niveau mysql qui consomme 99% du CPU. Avant le passage sur ce serveur il y avait plusieurs processus mysql et le problème était la RAM (2Go à l'époque), depuis qu'il n'y a plus qu'un processus mysql, le CPU encaisse tout et je n'ai trouvé aucune solution.

De toute manière, dans ton cas, (forum surchargé, heures de pointe, grosse BDD, nombreux enregistrements) il te FAUT séparer le web du SQL, pas d'issue sinon.

Par conséquent, tu n'y couperas pas, deux serveurs, un web, l'autre SQL, en fait ce n'est pas si difficile à gérer, c'est juste sur deux machines séparées, c'est tout. Et puis en plus, tu peux facilement diminuer la puissance nécessaire, donc le coût de location mensuel.

Par contre, pense à vérifier dès maintenant, que tes accès SQL n'utilisent pas de connections permanente, ça te met n'importe quel serveur à genoux, ça.

Peut être que, comme ça, déjà, tu pourras te contenter de l'existant.

 

[jcaron]

De toute manière, dans ton cas, (forum surchargé, heures de pointe, grosse BDD, nombreux enregistrements) il te FAUT séparer le web du SQL, pas d'issue sinon.

Par conséquent, tu n'y couperas pas, deux serveurs, un web, l'autre SQL, en fait ce n'est pas si difficile à gérer, c'est juste sur deux machines séparées, c'est tout. Et puis en plus, tu peux facilement diminuer la puissance nécessaire, donc le coût de location mensuel.

Là dessus je suis tout à fait d'accord (modulo la vérification des mesures effectuées, parce que j'ai quelques doutes...).

Par contre, pense à vérifier dès maintenant, que tes accès SQL n'utilisent pas de connections permanente, ça te met n'importe quel serveur à genoux, ça.

Là par contre je ne suis pas d'accord du tout. Autant sur un mutualisé ou si on a beaucoup de bases différentes c'est nécessaire (et je pense que sur un mutualisé on n'a généralement pas le choix de toutes façons), autant sur un dédié avec une seule base, il vaut clairement mieux avoir des connexions persistantes. C'est en tous cas vrai pour postgresql, mais même pour mysql on y gagne forcément (et je ne vois pas ce qu'on perdrait à refermer et rouvrir les connexions à chaque fois).

Jacques.

 

[tofm2]

Là par contre je ne suis pas d'accord du tout. Autant sur un mutualisé ou si on a beaucoup de bases différentes c'est nécessaire (et je pense que sur un mutualisé on n'a généralement pas le choix de toutes façons), autant sur un dédié avec une seule base, il vaut clairement mieux avoir des connexions persistantes. C'est en tous cas vrai pour postgresql, mais même pour mysql on y gagne forcément (et je ne vois pas ce qu'on perdrait à refermer et rouvrir les connexions à chaque fois).

J'en conclue que tu dois utiliser des connections permanentes. Le problème c'est que tu as des tonnes de visiteurs qui se connectent des fois pour quelques secondes, puis vont ailleurs, laissant la connection ouverte, derriere eux. (Si j'ai bien compris, il s'agit d'un forum PunBB sur les jeux videos, les forums ça attire pas mal de monde, et souvent ils ne viennent que pour lire UN post, trouvé sur Google, puis s'en vont... )

Tu héberges un serveur de jeu sur ton truc en plus de PunBB ??
Tu as un seul site ?? ou plusieurs ??

Ceci consomme de la mémoire et des ressources de façon inutile. N'importe qui te le dira, et tu trouveras des tas de threads, ici dans WRI qui te le confirmeront (il y en a une récente d'ailleurs, j'y ai participé, je ne me rapelle plus laquelle...).

EDIT : j'ai retrouvé le thread en question:
https://www.webrankinfo.com/forum/t/lenfer-des-nerfs-avec-les-requetes-sql-abondantes.85669/

Fais donc un essai ce soir, tu configure ton truc pour NE PAS utiliser les connections permanentes. comme ça, pendant 1 heure ou deux au moment de la montée en charge du serveur, puisque tu utilise des graphes style MRTG, j'ai cru comprendre, tu pourras comparer.

Je crois que ça vaudrait le coup d'essayer non ?

 

[poupee]

Je dispose d'un "vieux Xéon" avec 2 giga de Ram. Mon forum (SMF) tourne en permanence avec 150 personnes dessus, hors moteurs et je ne dépasse pas les 0.6 d'occupation (fonction top). Les jours de pointe, je parviens jusqu'à 1200 connectés en même temps et le serveur répond encore.
Disons que je suis fluide jusqu'à 800 connectés sur le forum en même temps. J'ai installé eaccelerator qui aide pas mal.
Je suis assez surpris de la configuration musclée que tu souhaite avec à peine 130 connectés dans le même temps sur un forum si peu consommateur de ressources.
Ceci dit, chacun est libre de s'offrir une Porsche ne serait-ce que pour se faire plaisir.

 

[Robinson]

Merci de vos réponses.

Je n'utilise pas de connexions permanentes, les index sont là il y a besoin, l'optimisation des requêtes est quasi parfaite, requêtes lentes très rares.

Mon site est un jeu en ligne en php accompagné d'un forum. Jeu en ligne implique beaucoup de pages visitées et assez rapidement (40-50 pages/visiteurs en moyenne hors forum).

Mes pointes sont sauvages oui car la plupart de mes visiteurs sont collégiens ou lycéens. En journée classique il y a 100-200 visiteurs, et à partir de 18h, on tourne autour de 600-700 pendant 2-3h.

poupee, félicitations pour ton forum mais PunBB n'est pas connu pour sa gourmandise et pourtant la dédibox a du mal avec ses 1Go de RAM. Mais je pense sérieusement changer de forum car il est lourd dans certaines manipulations (suppressions de topics).

Séparer mysql du web j'y pense mais ne sais pas du tout les besoins pour cette machine. Le nombre de requêtes SQL peut atteindre 320 par seconde.

Peut-être deux serveurs comme l'actuel, 2 cpu, 4Go de RAM qui coûterai moins cher que celui visé. Je peux toujours tester cela sur un mois

 

[tofm2]

Tu peux envoyer l'URL ? (eventuellement par MP ?)
promis j'irai pas à l'heure de sortie du lycée.

:wink:

 

[tofm2]

Séparer mysql du web j'y pense mais ne sais pas du tout les besoins pour cette machine. Le nombre de requêtes SQL peut atteindre 320 par seconde.

Peut-être deux serveurs comme l'actuel, 2 cpu, 4Go de RAM qui coûterai moins cher que celui visé. Je peux toujours tester cela sur un mois

peut être moins, commence par essayer petit, tu augmenteras la puissance progressivement.

 

[Robinson]

Oui mais si je vise trop bas, cela peut provoquer des problèmes et rendre le site inaccessible. Et si je pouvais y coller également la base de données du forum, ça ne serait pas un mal.

 

[jcaron]

J'en conclue que tu dois utiliser des connections permanentes.

Et pas qu'un peu, oui (pour les bases pour lesquelles c'est pertinent).

Le problème c'est que tu as des tonnes de visiteurs qui se connectent des fois pour quelques secondes, puis vont ailleurs, laissant la connection ouverte, derriere eux. (Si j'ai bien compris, il s'agit d'un forum PunBB sur les jeux videos, les forums ça attire pas mal de monde, et souvent ils ne viennent que pour lire UN post, trouvé sur Google, puis s'en vont... )

Tu confonds avec le posteur original... Moi j'ai un petit machin qui gère 15 millions de requêtes par jour, et je peux te dire que sans connexions persistantes ça ne marcherait pas. D'ailleurs c'est un truc qui est clairement conseillé dans la doc de mod_perl et autres.

Pour revenir au cas général (y compris le cas du posteur original), à partir du moment où tu n'as qu'une seule base de données (sur la même machine), tu y gagnes à avoir des connexions persistantes. Quoi qu'il arrive, chaque requête ou presque va avoir besoin d'accéder à ta base, donc entre ouvrir une connexion et la refermer à chaque requête, ou la garder ouverte, tu consommes de toutes façons la même chose en termes de nombre de processus (ou threads), de RAM, etc. Mais tu y gagnes parce que tu n'as pas le temps de mise en place de ces processus/threads, de la connexion TCP (ou du socket Unix), de l'authentification éventuelle, et tout le tintouin. Tu te demanderas pourquoi on a inventé la possibilité de garder une connexion pour plusieurs requêtes pour http le prince est le même. D'après ce que je comprends c'est moins sensible avec mysql qu'avec postgresql, mais ça dépend probablement des versions, des distributions, et j'en passe, et quoi qu'il arrive, tu y gagnes quand même.

Evidemment si tu as beaucoup de requêtes http qui ne requièrent pas d'accès à ta base de données tu peux être perdant (parce que tu immobilises un processus/thread et la RAM associée pour rien pendant que tu sers ces requêtes (en termes de CPU ça ne change rien, tant que tu n'utilises pas la bdd les threads/process du serveur de bdd restent idle et ne consomment rien), mais suivant le ratio entre ces requêtes et le nombre total de requêtes tu peux souvent y gagner quand même à utiliser des connexions persistantes), et de toutes façons tu as intérêt à isoler ces requêtes (pour des pages/fichiers statiques a priori) sur un serveur httpd séparé (soit un lighthttpd ou je ne sais plus comment il s'appelle, soit un apache réduit au minimum), avec soit des adresses différentes (souvent un peu lourd à manipuler), soit un reverse proxy devant (genre pound) qui va faire le tri, soit c'est le "light" qui va rediriger vers le "lourd" (i.e. celui avec php ou mod_perl ou autre machin lourd embarqué). Il y a aussi des reverse proxies qui savent servir des fichiers (voir perlbal), ou encore des proxies qui cachent (cf squid ou apache avec les modules kivonbien).

Bref, le seul cas (que je connaisse) où ce n'est pas une bonne idée de maintenir des connexions persistantes, c'est si le même serveur httpd se connecte suivant les cas à plusieurs bases de données, parce que ça veut dire que tu vas maintenir plein de connexions vers pleins de bases de données "pour rien" (avec souvent comment premier problème que tu vas atteindre le nombre max de connexions simultanées autorisé). Le cas typique c'est le mutualisé où chaque hébergé se connecté à sa base à lui, auquel cas il est hors de question que chaque process httpd garde une connexion vers chaque base de chaque utilisateur...

Jacques.

 

[jcaron]

Je n'utilise pas de connexions permanentes, les index sont là il y a besoin, l'optimisation des requêtes est quasi parfaite, requêtes lentes très rares.

Moi j'essaierais avec des connexions persistantes, juste pour voir ;-> Les index, dans certains cas tu peux penser ne pas en avoir besoin (parce que la requête est rapide quand même sans), mais en fait ça irait mieux avec: si la table tient entièrement en RAM, ça ira vite de faire un seqscan dessus, mais ça consommera nettement plus de CPU qu'avec un index (qui se fera entièrement en RAM aussi, mais permettra de sauter directement au bon endroit plutôt que de parcourir toute la table). Ca peut faire une différence carrément significative si la table est un peu grosse, mais assez petite pour tenir en RAM. De façon plus générale ce n'est pas parce qu'une requête n'est pas lente qu'elle ne bouffe pas tout plein de CPU. Une fois ce n'est pas grave, mais multiplié par des centaines ou milliers de requêtes ça peut coûter cher...

De façon plus générale, il est impératif de vérifier que la config de ton serveur mysql est bien adaptée à ta config. C'est pas du tout mon truc mysql, mais il y a visiblement des paramètres liés à la taille du cache, au "key_buffer", et quelques autres trucs du genre qui doivent être ajustés correctement et qui peuvent faire une différence considérable. Fais un tour sur les sites qui traîtent du sujet pour voir ce qu'ils en disent. Je pense qu'avec quelques changements minimes tu devrais pouvoir faire chuter l'utilisation CPU de ton mysql de façon spectaculaire.

Jacques.

 

[Robinson]

Je teste avec connexions persistantes, on verra bien.
Pour le moment, les pages ont l'air de s'afficher encore plus rapidement mais niveau processus il y a toujours des pointes à 99.9% et il y a peu de monde de connectés... dans un peu plus d'heure, on commencera à voir ce que ça donne.

 

[Stellvia]

Ta solution c'est mysql sur un autre dédié qui ne fait que ca .

On croirais moi il y a quelques mois ><

Nan vraiment c'est pour ca que j'insiste , c'est pour ton bien lol .

 

[Robinson]

Too many connections...


Et je viens de voir que j'ai un problème avec mysql qui ne veut pas redémarrer pour prendre en compte les modifs :

nsXXXX:~# mysqld restart
080107 17:08:13 Can't start server: Bind on TCP/IP port: Address already in use
080107 17:08:13 Do you already have another mysqld server running on port: 3306 ?
080107 17:08:13 Aborting

080107 17:08:14 mysqld: Shutdown Complete

Bref, je n'y touche plus, j'ai retiré les connexions permanentes, on verra quand il y aura moins de monde.

 

[tofm2]

Bref, je n'y touche plus, j'ai retiré les connexions permanentes, on verra quand il y aura moins de monde.

c'est bizarre c't'affaire ....


ce qui m'étonne le plus c'est le message d'erreur. Il y aurait plusieurs daemons écoutant en 3306..

essaye de voir en /var/run/mysql/ si il n'y a pas des processus qui traînent...

en clair tu arrête MySQL, et tu effaces tout ce qui traîne dans /var/run/mysql (directory pour chez moi en Mandrake, cela peut être différent sur ton serveur)

 

[jcaron]

Too many connections...

Ah ben oui il faut qu'il y ait au moins autant de connexions que de process httpd (+ un peu de marge). Et ça c'est si tu utilises une seule base de données, en faisant bien attention à ce que tous les paramètres de connexion soient bien toujours les mêmes (base de donnée, utilisateur, etc.), sinon ça multiplie le nombre de connexions requises (et si tu as plusieurs bases de données, comme déjà indiqué, ça réduit l'intérêt des connexions persistantes).

Et je viens de voir que j'ai un problème avec mysql qui ne veut pas redémarrer pour prendre en compte les modifs :

nsXXXX:~# mysqld restart
080107 17:08:13 Can't start server: Bind on TCP/IP port: Address already in use
080107 17:08:13 Do you already have another mysqld server running on port: 3306 ?
080107 17:08:13 Aborting

080107 17:08:14 mysqld: Shutdown Complete

C'est parce que l'arrêt prend une ou deux secondes, et qu'il essaie de le relancer avant que le précédent ne se soit arrêté (script idiot). Fais un stop, attends qu'il soit arrêté, puis un start.

Jacques.

 

[Robinson]

jcaron, c'est ce que je croyais aussi mais je viens de m'apercevoir que la commande mysqld ne fonctionne pas ! Peu importe ce qu'on met derrière...

La bonne commande est /etc/init.d/mysql restart

Bref nombre de connexions augmentés, je remettrai les connexions permanentes demain pour un nouveau test.

 

[Robinson]

Résultats des connexions permanentes :

aucun changement au niveau rapidité du site
aucun changement au niveau de la charge cpu (mysql pompe toujours autant)
nombre de process augmenté de 30-40%
nombre de requêtes mysql par seconde diminué de 30%

 

[jcaron]

Résultats des connexions permanentes :

[...]
aucun changement au niveau de la charge cpu (mysql pompe toujours autant)

Je pense que le "vrai" problème (qui fait que d'une part il consomme beaucoup, et d'autre part qu'il semble limité à 1 CPU à la fois) masque l'évolution qu'il pourrait y avoir... Il faut vraiment que tu résolves ces deux problèmes (surtout le premier en fait), très probablement liés à un mauvais paramétrage de mysql (buffers etc.) ou un problème d'optimisation des requêtes (index manquants, problème de collation, par exemple).

Jacques.