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:
http://www.webrankinfo.com/forums/viewtopic_85669.htm

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