Bonjour,

J'ai reçu depuis quelques semaine un PR de 5 sur mon Topsites et depuis c'est la galère je n'arrive à trouver de l'information sur l'optimisation de ce tuple mysql et apache.

Pourriez-vous m'aider SVP:

Dédibox Ubunto
DD 160 GO
Ram 1 Go
boot 40 Mo
swap 2048
/ le reste

J'allais oublier environ 5 000 000 de requêtes par jour et des pics à plus de 100 la seconde.

Le CPU vit tranquille sa petite vie et ne fait pas grand chose, et tous les sites (15) sur la boite dédié rament le soir vers 17h00 heure de pointe.

Voici mes fichiers de config


J'ai une grande expérience de l'informatique mais très peu d'unix et des serveurs Web, aussi toute aide sera la bienvenue.

Par avance merci.

quand tu dis "c'est la galere", cela veut dire que tu as des problemes ?

Ton top est pas trop mal a premiere vue.

Si tu plantes, comment est-il au moment du plantage ?

Bonjour,

Grand merci pour vos réponses.

En fait tous jours vers les 17 heures on ne peut plus accéder à mes sites tout devient hyper lent et les réponses n'arrivent pas aux clients.

Quand je fais un top en ssh le cpu se repose la ram est chargée et le résultat plus d'accès http posssible .

J'ai du trop chargé mysql et pas assez apache, mais mes connaissance dans le domaine sont très légères et c'est pourquoi je sollicite votre aide.

Entre temps j'ai installé APC, dommage ce n'était pas le meilleur et les load module pour charger un peu les machines clients, dont voici les changements opérés et j'ai peur que cela ne change pas grand chose :



Si cela vous cause, n'hésitez pas à conversez ;-)

Merci d'avance et bonne journée.

Bonjour en complément,

voici deux stats éloquentent sur mon serveur et sur celui de webmaster hub qui lui ne perd rien et qui décoiffe, bravo à l'équipe.


Perte de request et lenteur

MasterHub


Excellent 0 pertes ! Et là on voit bien que le CPU est sollicité !

Cdt Pascal

Ca dépend beaucoup de la façon dont les sites sont programmés. Si tu as un site qui se contente de récupérer des infos dans mysql, mais qui n'opère que peu de traitement, c'est normal que ta charge CPU soit réduite. Je crois que ton optimisation (si elle est possible) passerait d'abord par une optimisation des scripts côté serveur. Essaye de nous poster un exemple de requête SQL appelée depuis le script, histoire de voir comment c'est construit...

Salut,

Si tes accès bases sont de la lecture pense à mettre en place un système de cache, le résultat sera flagrant. D'autre part si tu fais des modifications en base, pose toi la question de savoir si les ordres SQL peuvent être différées.

Il n'y a aucun mérite... tu compares une Dedibox avec un Bi-Xeon en Dual-Core ... encore heureux qu'on remarque une différence entre les deux serveurs.

La différence principale vient du fait que ton serveur met 438 ms pour la connexion alors que le serveur du Hub met 5.4ms
Tu as donc un nombre important d'erreurs de timeout.

Et le serveur du Hub pourrait aller bien plus vite que ça, si seulement ton CPU arrivait à suivre
Tu n'utilises que 436KB de bande passante (soit à peine plus de 4Mb), et on a 2 cartes à 100Mb/s ... on est donc à 2% d'utilisation de la bande passante.

Dan

la solution à vo problemes de serveur : le bixeon dual core

Mais c'est vrai que l'opimisation de l'hébergement c'est un boulot et c'est super chiant, enfin ca reste un point important...

Bonsoir,

Merci à tous de vos réponses en fait j'ai gratté et :

Eureka ! J’ai finis par y arriver.

Cela n’a pas été sans peine et je pense qu’il pourrait encore y avoir des améliorations mais déjà, le résultat obtenu est plus que satisfaisant pour un début.

Donc je vais vous livrer ma petite cuisine, le tout sans prétention, simplement si cela peut aider quelqu’un ce serait dommage de ne pas vous en faire profiter. Encore une fois je ne me prends pas pour un expert apache, loin s’en faut ...

L’ensemble des modifications tient en peu de lignes et principalement dans apache2.conf.

Voici le code modifié :


Positionnez AllowOverride sur none afin d’éviter qu’apache tente d’ouvrir le .htaccess dans chaque répertoire qu’il visite.

Pensez à mettre le KeepAlive et KeepAliveTimout (entre 2 et 5), permettent l’envoi de requêtes multipes. C’est very good pour les pages html comportant par exemple plusieurs images, si vous le mettez sur off alors apache va générer de multiple TCP et ainsi créer une surcharge importante pour tous les TCP, un par image ..

La directive ServerLimit permet d’overrider le par défaut qui vous limite à 256 clients.

Mon maxclient correspond à mon besoin et il est bien équilibré aujourd’hui pour moi.

Attention de bien équilibré le minspare par rapport au maxspare, ces paramètres déterminent le nombre de processus enfants, si le min est trop bas apache génèrera trop d’enfant et pendant ce temps il ne répondra pas aux requêtes et il consommera plus de ram. Normalement et là, ce n’est pas tout à fait le cas ;-) on devrait avoir un ratio de 4 afin de ne pas généré plus de 4 enfants. Ah les sales gosses ;-)
MaxRequestsPerChild n’hésitez pas à en mettre quelques milliers.
Alors maintenant quelques modules pour arranger encore plus la vie de votre serveur.
La compression http peut être activée grâce au module deflate. La communication avec le navigateur est automatique et apache de ce fait détermine automatiquement si il peut compresser ou non. (Content-Encoding: utilisation de gzip par apache)
Encore un petit truc, mettre en cache chez le client une copie des données et gérer sa conservation : économie de BP, ce contrôle du cache est exécuté par les modules mod_epires et mod_headers, en local coté serveur cela peut être effectué avec le mod_cache. Ensuite codez les Expires defaut et type.
Dernier point pour les PROS qui veulent vraiment affiner leur serveur.
En fait il y à deux type de pages, les pages statiques et les pages dynamiques, or si apaches sait gérer les deux il ne le fait pas de manière identique. En effet 3mo suffisent pour les statiques et de 3 à 20 mo de ram pour les dynamiques. Or notre ami apache ne libère pas la ram et ce jusqu’à ce que le processus meurt, aussi vous vous retrouver rapidement avec une taille de ram importante voir l’utilisation du swap = accès HD.
Deux solutions, 1 propre et un peu complexe et une débrouillardise que j’ai mise en œuvre pour l’instant.
Propre :
Montez un Apache léger (minimum de modules statiquement compilés) comme serveur frontal pour les pages statiques. Les pages requêtes dynamique doivent être envoyés au serveur Apache puissant (compilé avec les modules utiles). Un serveur frontal léger offre l'avantage d'une prise en charge rapide du contenu statique sans consommer trop de ram, et le dynamique est transféré vers le gros serveur.
Vous pouvez filtrer le transfert des requêtes via les modules mod_proxy et mod_rewrite. Vous en mettez un sur le port 80 et l’autre sur le 8092 par exemple.

Code :


Et hop, bon il faut le tester et le mettre au point mais c’est l’idée.

Votre client ne verra rien et votre ram sera heureuse.

La débrouillardise :
Crontab –e (mode root)

Puis :
*/60 10-19 * * mon,tue,wed,thu,fri,sat /etc/init.d/apache2 reload

Cela revient à dire toute les 60 minutes de 10 heures à 19 heures du lundi au samedi, pépère soit gentil de reload apache afin de virer les processus inutiles et de libérer ma RAM, non de dieu ! ;-)

Voilà j’espère que ce petit tuto pourra vous aider, enfin moi j’ai pas mal galéré et même si cela n’est pas encore pointu, mon serveur tourne et les temps de réponses sont passé de 10 minutes à 1 à 3 secondes avec au redémarrage d’apache (reload) une conso de 350 mo de ram ce qui est plus que satisfaisant sachant que j’ai configuré un mysql de ouf avec par exemple 384mo de keysbuffers etc ... enfin en gros la config que l’on trouve dans huge.ini de easyphp 2.0.

Je vous rappelle le contexte, Sur une dédibox, j’ai une quinzaine de sites web dont 4 annuaires et mon fameux Topsites qui à lui seul reçoit environ 600 000 requêtes chaque jour pour l’affichage de notre bouton statistiques sur les sites web des inscrits sur notre TopSites. Et bien sur une table qui montent jusqu’à 180 000 lignes le soir, avec l’IP, le User, le referer, une variable rate, unique_visite, totale_visite et sortie. Chaque requête d’affichage du bouton de stats génère environ 8 requêtes de lecture et de maj en mysql.
Dernier point que l’on néglige souvent et qui est pourtant évident le calcul des stats, en effet j’ai diminué mon bouton de 7.65Ko à 1.20 et je suis passé sur le domaine TopSites de 5Go à 1.5go par jour en BP. Eh oui 600 000 * de 6.45 ko = trop lourd ...

J'allais oublié, je suis heureux de n'avoir pas du investir dans un bi-néon
au fait sur mon httpperf je ne perds plus de clients tout le monde à sa réponse et mon cpu monte maintenant de manière significative, ah le feignant.

Cordialement Pascal

Bonjour,

Pour la Crontab mettez plutôt :



Toutes suggestions pour l'amélioration de ces codes et informations seront les bienvenues.

Merci.