La valeur initiale de la ram que l'on alloue a Squid est relativement minime et ridicule par rapport a ce qu'il va consommer réellement.
Si je prends un serveur doté de 8G de ram et 8G de swap (soit 16G utilisable de son point de vue), que j'alloue a squid au moins 2G de ram, celui-ci va utiliser petit a petit a force de faire son index en ram jusqu'a 37% de la ram “totale” (soit plus ou moins 6G) au bout de deux semaines.
Je recommande donc une valeur basse dans la configuration.
cache_mem 2 GB
Ne cherchez pas a recopier bêtement, ce sont ici des valeurs basique a titre indicatif.
Est il pertinent de garder des objets faisant jusqu'à 4M en ram ?
Sont ils appelé très régulièrement ?
Peut on se poser la même question pour des objets faisant jusqu'à 4M en disque ?
Je n'ai pas la réponse pour vous, il faut étudier le ou les site(s) que l'on cache pour connaitre cette réponse afin de pouvoir optimiser Squid pour qu'il délivre vite et bien du contenu.
maximum_object_size_in_memory 4096 KB
maximum_object_size 4096 KB
Si vous avez plusieurs serveurs de cache, nul besoin de raid, un disque rapide est des plus apprécié, il faut de l'I/O, beaucoup d'I/O.
Même chose que pour le disque en lui même, privilégier un filesystem non journalisé qui encaisse beaucoup de petit fichier.
Les plus “rapides” pour cela étant ext2 ou XFS sans journalisation.
En terme d'espace disque a utiliser, il est très “dur” de pouvoir dimensionner son cache lorsque l'on ignore combien le ou les site(s) vont avoir besoin.
Une bonne méthode, lorsqu'on a le temps, est d'aspirer son (ou ses) propre site(s) avec des outils tel que httrack (ou wget en mode récursif) et de regarder la place prise.
Mais l'idéal est d'avoir beaucoup de place dès le départ, un gros disque rapide entièrement utilisé pour cela est une bénédiction.
Squid dispose de plusieurs méthode d'écriture de son cache.
UFS, la méthode par défaut
AUFS, une version “posix” de UFS
DISKD, Squid invoque un thread supplémentaire pour stocker en UFS
COSS, très spécial et peu amener a des maux de cranes pour l'optimisation
Personnellement je recommanderais “diskd” lorsqu'on dispose d'un serveur dédié a squid avec beaucoup de “core”.
Ensuite il suffit d'indiquer combien d'espace disque et de répertoire de niveau 1 et 2 il doit utiliser.
Dans le cas d'un filesystem dédié, il faut prendre 80% de la partition maximum, il a besoin d'espace pour des fichier temporaire avant le stockage.
Pour les répertoire de niveau 1 et 2, les valeurs par défaut sont amplement suffisante et n'ai encore jamais eu a y toucher.
cache_dir diskd /var/spool/squid 24576 16 256
Lorsque l'on fait beaucoup d'audience, ce sont les logs qui grèvent le plus les performances.
Même motif même punition que pour le storage de squid, filesystem (et disque, lorsque possible) dédié.
Parceque vous devez gardez vos logs un an et un jour, mettez vos logs sur une machine distante (SAN/NAS) pour les archiver.
Soyons clair, net, précis, et surtout méchant, nos serveurs de cache ne sont pas la pour “tenir la jambe” a un client.
Squid doit envoyer ses informations vite et ne pas garder des sockets ouvert trop longtemps.
On refusera alors les connections persistante et on jètera les clients qui ferment mal leur connexions.
half_closed_clients off
server_persistent_connections off
client_persistent_connections off
Plusieurs écoles disent que les connections persistantes c'est bien, ca soulage le CPU, etc.
On peut alors activer les connexion persistantes pour les clients et limiter leur temps d'utilisation.
half_closed_clients off
server_persistent_connections off
client_persistent_connections on
client_lifetime 1 minutes
Que l'on peut coupler avec des variables plus poussées.
request_timeout 1 minutes
persistent_request_timeout 1 minutes
