[article] Optimiser son serveur dédié

**le Ven Mai 26, 2006 12:02**

Ouep mais justement, avec bufferisation du FS + celle d'Apache, les accès disques ne sont pas si fréquents... on ne peut donc pas dire que ça ait un impact si nefaste sur les performances.

Du coup se priver des informations des logs pour gagner si peu de ressources, me semble complètement injustifié. :s

**le Ven Mai 26, 2006 12:05**

On parle des logs d'accés apache uniquement! :wink:

**le Ven Mai 26, 2006 12:09**

Oui oui... pour moi les informations fournies sont importantes...

**le Mar Oct 17, 2006 10:17**

pour les accelerateurs, est-ce que eaccelerator est suffisamment stable avec PHP5 ?
a l'époque il y avait le fameux turck mmcache sur php4 qui fonctionnait bien, mais depuis, j'hésite à utiliser un optimiser...

**le Mer Oct 18, 2006 14:25**

fandecine a écrit:Externaliser tout ce qui est possible cela soulagera votre serveur d'autant. Pour les stats, il suffit de s'abonner à xiti ou estat (gratuit).

Supprimer les logs Apache et placer des outils gratuits, je ne vois pas du tout l'intérêt.
Les logs donnent bien plus d'informations une fois qu'ils sont traités que ces outils là.

fandecine a écrit:Enfin, ne pas oublier que la desactivation des logs d'accés présente un interet d'autant plus grand que les fichiers générés sont importants. Le gain pour un site à faible trafic n'est pas forcement significatif.

C'est un faux problème.
Une rotation quotidienne des logs (par un script) et tes fichiers sont de taille correcte.
De plus, comme le suggère yanhl, on peut 'allèger' les logs en supprimant certains appels (images, js, css, favicon...).

**le Mer Oct 18, 2006 15:15**

adviser a écrit:Une rotation quotidienne des logs (par un script) et tes fichiers sont de taille correcte.

la rotation consiste bien dans le fait d'écraser (on perd donc les infos) pour y mettre les infos les plus récentes.?

**le Mer Oct 18, 2006 15:30**

thierry8 a écrit:
adviser a écrit:Une rotation quotidienne des logs (par un script) et tes fichiers sont de taille correcte.

la rotation consiste bien dans le fait d'écraser (on perd donc les infos) pour y mettre les infos les plus récentes.?

Soit j'ai utilisé un mauvais terme, soit je me suis mal exprimé

Ce que je voulais dire, c'est que tu peux sans pb sauvegarder tes logs de manière quotidienne sans perdre de données.

Rotation des logs Apache sur la FAQ Sivit.fr

**le Mer Oct 18, 2006 15:38**

c'est donc bien ce que je disais : rotation des logs écrasement des données les plus anciennes (en fonction du délais de rotation) par les nouvelles données.

moi ça ne me dérange pas...c'est vrai que le fichier sera plus légé..
donc pour ceux qu'on un dédié et qui s'en moque..c'est bon..

sinon il faut y penser.

faire une rotation sur quelques jours de manière à garder quelques entrées.

**le Mer Oct 18, 2006 16:34**

adviser a écrit:Supprimer les logs Apache et placer des outils gratuits, je ne vois pas du tout l'intérêt.
Les logs donnent bien plus d'informations une fois qu'ils sont traités que ces outils là.

C'est pourtant écrit lisiblement! Lorsque je dit d'externaliser les services cela concerne l'utilisation des logs pour faire des stats d'accés (ex: webalizer).

Ensuite, les logs il y en a plein d'autres qui donnent les mêmes infos. Donc je maintiens que sur un site en production il n'est pas nécéssaire d'activer les logs d'accés apache (je n'ai jamais parlé des logs d'erreur!)

adviser a écrit:C'est un faux problème.
Une rotation quotidienne des logs (par un script) et tes fichiers sont de taille correcte.
De plus, comme le suggère yanhl, on peut 'allèger' les logs en supprimant certains appels (images, js, css, favicon...).

Là mon coco, on ne doit pas parler de lamême chose. avant la désactivation des logs d'accés sur un de mes serveurs le fichier logs d'accés bien qu'optimisé, dépassait allégrement le Go et lors de la rotation, le serveur était à plat! Je répette donc que cela dépend du trafic. Dans le cas que je site, prés de 350000 pages/jour donc logs d'accés enorme et innexploitables. (Si, si je maintiens

) donc desactivation et depuis, le serveur se porte à merveille!

Enfin, je ne vais pas batailler des heures pour une question de philosopie... :wink:

**le Jeu Oct 19, 2006 11:20**

fandecine a écrit:Là mon coco, on ne doit pas parler de lamême chose. avant la désactivation des logs d'accés sur un de mes serveurs le fichier logs d'accés bien qu'optimisé, dépassait allégrement le Go et lors de la rotation, le serveur était à plat! Je répette donc que cela dépend du trafic. Dans le cas que je site, prés de 350000 pages/jour donc logs d'accés enorme et innexploitables. (Si, si je maintiens ) donc desactivation et depuis, le serveur se porte à merveille!

Enfin, je ne vais pas batailler des heures pour une question de philosopie...

Je ne veux pas polémiquer dessus. Il est inutile de sortir des chiffres pour prouver quoique ce soit, ils seront toujours en deça de ce que nos serveurs traitent :mrgreen:

Je trouve dommage de supprimer les logs pour "optimiser son serveur dédié".

**le Dim Oct 22, 2006 23:06**

Perso j'ais des giga de log qui m'ennuis plus qu'autre chose , le seul qui m'interesse et qui est important c'est error_log .

J'aimerais desactiver access_log mais ...

CustomLog /dev/null combined
on mets cette ligne a la place de quoi ??

et 2 eme question ca désactive pas error_log au passage au moins ?

**le Mar Oct 24, 2006 12:51**

Pour avoir bossé en tant qu'hotliner pour un hébergeur, je peux vous dire que les logs sont bien utiles, car c'est bien ceux-ci que demande la police en cas de problème.

Une rotation des logs permet de garder un histoire. Concrètement, les données ne sont pas effacée, mais déplacée.

Une rotation journalière, ça passe sans problème pour de gros serveurs, étant donné que ces opérations font appel directement à des exécutables. A mon avis, l'optimisation passe d'abord par analyser quelles sont les données critiques d'un système.

Passer sous MySQL 5 permet dans un premier temps d'utiliser des fonctinnalités comme "SELECT SQL_CACHE" qui mets en cache le résultat d'une requête dans la mémoire vive, en surveillant si d'autres requêtes ne viennent pas modifier le résultat bufferisé. C'est une gestion des données intéressantes permettant un accès rapide aux données (temp d'accès ram < temps d'accès disque), tout en gardant une bonne synchro des données.

On peut également songer à passer certaines tables dont le contenu n'est pas très important (sessions, stats) en type HEAP (ou Memory selon les versions): le contenu est alors stocké dans la RAM, le temps d'accès est accéléré, mais en cas de plantage ou de redémarrage, les données sont perdues.

Pour optimiser un serveur, il n'est nul besoin vraiment de trouver des astuces, mais de se poser les bonnes questions et d'y donner de bonnes réponses.

**le Mar Oct 24, 2006 13:00**

Par rapport au log, à partir de quel taille (approximativement) il devient trop "gros" ? 10 Mo ?

pour avoir une idée

**le Mar Oct 24, 2006 13:06**

Sur un serveur avec un trafic assez élevé, 150Mo ça passe, jusque 230Mo également. Au dela, ça lague mais uniquement en pics.

Une solution intelligente serait d'analyser les statistiques de fréquentation pour forcer une rotation dans une zone creuse préccédent une zone de forte activité.

Rien ne sert d'avoir un serveur optimisé tout le temps. Il doit être optimisé pour les périodes de forte fréquentation. Le but est de fluidifier la charge et le trafic.

**le Jeu Déc 28, 2006 11:15**

comment dois on specifier a apache de ne pas logger images et css ? Merci

sinon en quoi un gros fichier de logs est inutilisable, si tu utlise les outils pour ou que tu bricole un peu de bash , perl ou python tu pourras trouver les infos que tu veux.

[article] Optimiser son serveur dédié

Formation recommandée sur ce thème :

Lectures recommandées sur ce thème :

Qui est en ligne