[article] Optimiser son serveur dédié

[Bool]

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

[fandecine]

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

[Bool]

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

[labrute]

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...

[adviser]

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à.

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...).

[thierry8]

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.?

[adviser]

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

[thierry8]

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.

[fandecine]

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!)

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...

[adviser]

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

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

[Misaki]

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 ?

[Bourriquet]

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.

[thierry8]

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

pour avoir une idée

[Bourriquet]

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.

[venomelektro]

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.