Rappel sur LUA et PostGreSQL
Dans le cadre d’un projet d’intégration de SEP, j’ai installé un serveur LiveUpdate en interne. LiveUpdate est la technologie utilisée par les produits Symantec pour se mettre à jour par Internet (c'est l'équivalent d'un serveur WSUS chez Microsoft).
Dans la suite de ce billet, Live Update désigne le service de mise à jour et Live Update Administrateur (LUA) désigne le serveur interne de distribution des mises à jour.
Le client Live Update utilise une technologie PULL pour se connecter en HTTP et en FTP. Par défaut le client Live Update est configuré pour pointer vers les serveurs publics de Symantec. Il est possible de modifier ce comportement de manière à ce qu'il se connecte au serveur LUA interne en lieu et place des serveurs publics.
Le serveur LiveUpdate Administrateur utilise le moteur de base de données PostgreSQL . La version de PostgreSQL fournie avec LUA 2.x est la version 8.1(cf. site officiel PostGreSQL).
Remarque : Le support technique de Symantec recommande fortement à ses clients l'application de toutes les mises à jour du serveur LUA de manière à bénéficier de toutes les améliorations disponibles (notamment des améliorations apportées par la version 8.1 de PostGreSQL).
Le moteur PostGreSQL est configurable via le fichier « postgresql.conf » situé a la racine du dossier d’installation de LiveUpdate Administrator.
Tuning des performances PostGreSQL
Voici les principaux paramètres ayant une grande influence sur les performances de la base ainsi que les valeurs recommandées :
1. shared_buffers
Le paramètre shared_buffers détermine la quantité de mémoire utilisée pour la mise en cache des données. Certaines sources recommandent une valeur correspondant à 25% de la mémoire vive du serveur.
Par défaut la valeur du paramètre shared_buffers est de 32Mo avec LUA 2.2. Une valeur de 512 Mo permet d'améliorer les performances. Certains gros clients ont augmenté cette valeur jusqu'à 1024 Mo et on ensuite pû observer de grandes améliorations.
2. temp_buffers
Le paramètre temp_buffers n'est utilisé que pour le maintient des tables temporaires en mémoire.
Comme LUA 2.x ne dépend pas fortement de ces tableaux, certains clients ont réduit cette valeur de 2 Mo dans le cadre de leur mise au point.
3. work_mem
work_mem fixe la quantité maximale de mémoire à utiliser pour l’exécution d’une requête.
Le réglage de work_mem à 256 Mo a conduit à une amélioration des performances pour certains clients.
4. max_fsm_pages
Cette valeur doit être réglée sur le nombre maximum de pages de données (affichage Web) que vous voulez modifier ou supprimer. Une valeur de 20 000 a bien fonctionné pour certains clients.
5. wal_buffers
Une valeur de 256Kb devrait être suffisamment grande. pour une bonne utilisation de LUA.
6. checkpoint_segments
Les valeurs recommandées vont de 16 à 128 en fonction de l’espace disque disponible.
Par défaut, la valeur est de 3. Certains gros clients ont augmenté cette valeur à 30 et vu de grandes améliorations.
7. effective_cache_size
Effective_cache_size définit la taille du cache disque par rapport à la quantité de mémoire RAM disponible pour la mise en cache des données,
Il est recommandé de configurer la valeur effective_cache_size à 50% de la RAM du système (cette préconisation est valide si et seulement si le serveur est dédié au rôle LUA).
Par défaut, LUA 2.2 a effective_cache_size a une valeur de 128Mo. Certains gros clients ont augmenté cette valeur jusqu'à 2048 Mo et vu de grandes améliorations.