Pages Menu
TwitterRss
Categories Menu

Posté par le 18 août 2011 dans Planet-Libre, Tutoriel | 2 commentaires

Varnish 3 : installation

1ère étape dans la série des articles sur Varnish : l’installation. Je vais traiter ici de l’installation de Varnish 3 sur une Debian Squeeze 64 bits fraîchement installée. Pourquoi 64 bits ? Parce que Varnish est conçu pour fonctionner sur des architectures 64 bits. Le 32 bits limitera la quantité de mémoire qu’il pourra utiliser, le nombre de threads qu’il pourra ouvrir…

Si vous arrivez directement sur cet article et/ou que vous souhaitez en savoir plus sur Varnish, je vous suggère la lecture de Varnish : aperçu.


 

Installation

Varnish fournit les paquets pour différentes distributions. Voici les étapes nécessaires à l’installation de Varnish 3 sur une Debian :

 

Configuration

La configuration des processus varnishd, varnishlog et varnishncsa se trouve dans /etc/default :

  • varnish pour la configuration du processus varnishd.
  • varnishlog pour la configuration du processus de log varnish.
  • varnishncsa pour la configuration du processus de log varnish au format Apache.

Configuration de varnishd :

La configuration par défaut peut être à revoir pour coller au mieux à votre serveur. Je dis peut-être car elle peut vous suffir en fonction de votre besoin (modulo quand même le cache de 256m). Il est important de faire un bench avant et après vos modifications pour vous assurer que vos modifications n’ont pas réduit les performances générales de votre serveur. Un outil pratique pour suivre un peu ce qu’il se passe sur votre serveur pendant un bench : dstat. Ne pas oublier varnishstat qui vous permettra de détecter certains problèmes.

Cache de type file ou malloc ?

C’est je pense la première question à vous poser. Varnish sera beaucoup plus performant avec le cache en mémoire. Maintenant, tout est question de la taille de votre cache et de la quantité de RAM dont vous disposez. Si vous décidez d’utiliser le stockage de type malloc, il faudra vous arranger pour que votre cache tienne en RAM sachant que vous pouvez dédier jusqu’à 80% de RAM à votre cache Varnish. Les 20% restant serviront à d’autres caches Varnish et à votre OS. Attention donc à ne pas attribuer 100% de votre RAM au risque de voir, un jour, l’OOM killer faire le ménage ! Si vous devez cacher sur disque, préférez un SSD (test à venir).

Configuration pour un serveur bi-quad core avec 16Go de RAM :

En partant sur ce serveur de tests, voilà les valeurs optimisées :

  • thread_pool : (2 par défaut). L’idée est d’avoir un pool par core. Mon serveur en a 8. thread_pool vaut donc 8. Au délà d’un pool par core, les performances seront moins bonnes.
  • thread_pool_min : (5 par défaut). C’est le nombre minimum de threads par pool. C’est utile en cas de montée en charge soudaine. La documentation de Varnish donne 200 en exemple de tuning. J’ai testé avec 200 et 100, pas de différence visible. A tester/bencher pour votre besoin.
  • thread_pool_max : (500 par défaut). C’est le nombre total de threads que vous pouvez ouvrir. Il faudra adapter le nombre de descripteurs de fichiers disponibles en fonction de cette valeur. La documentation donne 4000 en exemple et 5000 en limite pour ne pas rentrer dans des problèmes de limites système. Augmenter cette valeur trop haut n’augmentera pas vos performances ! Vérifiez avec un bench.
  • thread_pool_add_delay : (2ms par défaut sur Varnish 3). C’est la pose entre chaque création de threads. La réduire permet, surtout au démarrage de Varnish ou en cas de montée en charge soudaine, d’en créer plus rapidement et d’éviter ainsi la mise en attente d’une requête ou son rejet. Sur Varnish 3 on garde la valeur par défaut de 2ms. Sur Varnish 2.1.5, il fallait réduire la valeur par défaut de 20ms à 2ms.
  • session_linger : (50ms par défaut). De 100 à plus selon le besoin et les tests. C’est la durée durant laquelle le thread va attendre pour une nouvelle requête dans la session établie.

Voilà le résultat dans le fichier /etc/default/varnish :

 

Optimisation du système

Les optimisations sont données à titre d’exemple pour un serveur dédié Varnish. Elles seront à adapter en fonction de l’usage de votre cache.

Tuning des entrées/sorties :

  • Désactivez l’utilisation de la swap : sysctl -w vm.swappiness = 0
  • Placez le répertoire de travail de Varnish qui héberge le log SHM en tmpfs. Il n’y a aucun risque à perdre ces données en cas de reboot. Par défaut le log SHM est de 80 MB. On va créer un tmpfs de 256MB. Rajoutez cette ligne dans votre /etc/fstab :

    Si vous avez modifié la taille du log (option -l de varnishd), adaptez la taille du tmpfs. A savoir : vous pouvez intervenir à chaud sur la taille de votre tmpfs. Modifiez la taille définie dans le fstab et remontez à chaud via mount -o remount /var/lib/varnish. Vérifiez via un df.
  • Dans le cas ou vous cachez sur disque, il faudra préférer un système de fichier non journalisé pour la partition qui héberge le cache Varnish (utilisez ext2 par exemple). Il sera monté avec les options noatime, nodiratime.
  • Toujours dans l’optique où vous utilisez le disque comme stockage du cache, préférez l’ordonnanceur “anticipatory” sur un noyau linux inférieur au 2.6.33 (cet ordonnanceur a été retiré) ou “cfq”, le défaut, sur un noyau plus récent. Si votre disque est un SSD, utilisez le plus simple des ordonnanceurs : “noop”.

Tuning réseau :

  • Gardez votre varnish et vos backends à l’heure. Utilisez ntp.
  • Optimisez /proc/sys/net en fonction de votre besoin… Sachant que depuis le kernel 2.6.17, tout est en auto tuning jusqu’à 4MB de buffer, dans la majorité des cas, toucher aux différents buffers n’améliorera pas les performances de Varnish.
  • Si votre passerelle fait du NAT, attention si vous réutilisez les sessions en TIME WAIT (tw_reuse=1) et que votre passerelle ne modifie pas tw_timestamp. Les connexions seront bloquées tant que le time wait n’aura pas expiré.
  • Dans le même genre, attention à ne pas activer le suivi de connexion pour serveur Varnish. Vu le nombre de connexions qu’il peut être amené à gérer, cela peut être source à problèmes.

Encore une fois, testez et benchez vos modifications. Vérifiez au niveau de la supervision et des différents compteurs de varnishstat que tout fonctionne correctement et que les performances sont optimales.

A suivre …

2 commentaires

  1. Hello,

    Toujours aussi agréable à lire tes articles :)
    Par contre quand tu dit “sysctl -w vm.swappiness = 0″ c’est pour désactiver l’utilisation de la SWAP par le Varnish ? Que ce passe t-il dans le cas d’un débordement du coup ?

    A bientôt

  2. Salut,

    Merci 😉 En fait ça ne désactive pas vraiment la swap, mais elle ne sera utilisée que pour éviter des out of memory.

    A+

Poster une réponse

Votre adresse de messagerie ne sera pas publiée. Les champs obligatoires sont indiqués avec *


8 + un =

Vous pouvez utiliser ces balises et attributs HTML : <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code class="" title="" data-url=""> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong> <pre class="" title="" data-url=""> <span class="" title="" data-url="">