Configuration d'un environnement optimal pour PostgreSQL

Bienvenue dans PostgreSQL, un puissant système de base de données open source qui peut héberger n'importe quoi, de quelques mégaoctets de données client pour une petite entreprise à des centaines de téraoctets de « big data » pour les multinationales. Quelle que soit l'application, il est probable qu'une aide à l'installation et à la configuration sera nécessaire pour préparer la base de données à l'action.

Lorsqu'un nouveau serveur est installé, les paramètres de PostgreSQL sont très minimaux car ils sont conçus pour fonctionner sur le moins de matériel possible. Cependant, ils sont très rarement optimaux. Ici, nous allons passer en revue une configuration de base pour les nouveaux projets et comment configurer PostgreSQL pour qu'il s'exécute de manière optimale sur les nouveaux projets.

Hébergement

Hébergement sur site

Avec une base de données sur site, la meilleure option est un hôte bare metal, car les machines virtuelles fonctionnent généralement plus lentement, sauf si nous parlons de machines virtuelles haut de gamme au niveau de l'entreprise. Cela permet également un contrôle plus strict des configurations du processeur, de la mémoire et du disque. Cependant, cela s'accompagne de la nécessité d'avoir un expert sous la main (ou un contrat) pour effectuer la maintenance du serveur.

Nuage

L'hébergement d'une base de données dans le cloud peut être merveilleux à certains égards, ou un cauchemar à d'autres. À moins que la plate-forme cloud choisie ne soit hautement optimisée (ce qui signifie généralement un prix plus élevé), elle peut avoir des problèmes avec des environnements à charge plus élevée. Gardez un œil sur le fait que le serveur cloud soit partagé ou dédié (dédié permettant des performances complètes du serveur pour l'application), ainsi que le niveau d'IOPS (opérations d'entrée/sortie par seconde) fourni par un serveur cloud. Lorsque (ou si) l'application se développe au point que la majorité des données ne peuvent pas être stockées en mémoire, la vitesse d'accès au disque est cruciale.

Configuration générale de l'hôte

Les principaux piliers nécessaires pour configurer PostgreSQL de manière fiable sont basés sur les capacités du processeur, de la mémoire et du disque de l'hôte. Selon les besoins des applications, un hôte suffisant ainsi qu'une configuration PostgreSQL bien réglée auront un impact incroyable sur les performances du système de base de données.

Choix d'un système d'exploitation

PostgreSQL peut être compilé sur la plupart des systèmes d'exploitation de type Unix, ainsi que sur Windows. Cependant, les performances sous Windows ne sont même pas comparables à un système de type Unix, donc à moins que ce ne soit pour un petit projet jetable, s'en tenir à un système de type Unix établi sera la voie à suivre. Pour cette discussion, nous nous en tiendrons aux systèmes basés sur Linux.

La distribution Linux apparemment la plus utilisée pour l'hébergement de PostgreSQL est un système basé sur Red Hat, tel que CentOS ou Scientific Linux, ou même Red Hat lui-même. Étant donné que Red Hat et CentOS se concentrent sur la stabilité et les performances, la communauté derrière ces projets travaille dur pour s'assurer que les applications importantes, telles que les bases de données, sont sur la version la plus sécurisée et la plus fiable de Linux possible.

REMARQUE :Linux a une gamme de versions de noyau qui ne sont pas optimales pour exécuter PostgreSQL, il est donc fortement recommandé de les éviter si possible (en particulier sur les applications où les performances de pointe sont de la plus haute importance). Les benchmarks ont montré que le nombre de transactions par seconde chute à partir des versions de noyau 3.4 à 3.10, mais récupère et s'améliore considérablement dans le noyau 3.12. Cela exclut malheureusement l'utilisation de CentOS 7 si vous suivez la route CentOS. CentOS 6 est toujours une version valide et prise en charge du système d'exploitation, et CentOS 8 devrait être publié avant que 6 ne soit plus pris en charge.

Installation

L'installation peut être effectuée soit par la source, soit en utilisant des référentiels maintenus soit par la distribution de Linux choisie, soit mieux encore, par le PostgreSQL Global Development Group (PGDG), qui maintient des référentiels pour les systèmes basés sur Red Hat (Red Hat, Scientific Linux, CentOS, Amazon Linux AMI, Oracle Enterprise Linux et Fedora), ainsi que des packages pour Debian et Ubuntu. L'utilisation des packages PGDG garantira que les mises à jour de PostgreSQL sont disponibles pour mise à jour dès leur publication, plutôt que d'attendre que les référentiels intégrés de la distribution Linux les approuvent et les fournissent.

Processeur

De nos jours, il n'est pas difficile d'avoir plusieurs cœurs disponibles pour un hôte de base de données. PostgreSQL lui-même n'a que récemment commencé à ajouter des fonctionnalités multi-threading au niveau des requêtes, et s'améliorera beaucoup dans les années à venir. Mais même sans ces améliorations nouvelles et à venir, PostgreSQL lui-même génère de nouveaux threads pour chaque connexion à la base de données par un client. Ces threads utiliseront essentiellement un cœur lorsqu'ils seront actifs, donc le nombre de cœurs requis dépendra du niveau de connexions simultanées et de requêtes simultanées nécessaires.

Une bonne base pour commencer est un système à 4 cœurs pour une petite application. En supposant que les applications effectuent une danse entre l'exécution des requêtes et la mise en veille, un système à 4 cœurs peut gérer quelques dizaines de connexions avant d'être surchargé. L'ajout de cœurs supplémentaires aidera à évoluer avec une charge de travail croissante. Il n'est pas rare que de très grandes bases de données PostgreSQL aient plus de 48 cœurs pour servir plusieurs centaines de connexions.

Conseils de réglage : Même si l'hyper-threading est disponible, les transactions par seconde sont généralement plus élevées lorsque l'hyper-threading est désactivé. Pour les requêtes de base de données qui ne sont pas trop complexes, mais dont la fréquence est plus élevée, il est plus important d'avoir plus de cœurs que des cœurs plus rapides.

Mémoire

La mémoire est un aspect extrêmement important pour les performances globales de PostgreSQL. Le paramètre principal de PostgreSQL en termes de mémoire est shared_buffers, qui est un bloc de mémoire alloué directement au serveur PostgreSQL pour la mise en cache des données. Plus la probabilité que les données nécessaires vivent en mémoire est élevée, plus les requêtes sont renvoyées rapidement, et des requêtes plus rapides signifient une configuration du cœur du processeur plus efficace, comme indiqué dans la section précédente.

Les requêtes ont également parfois besoin de mémoire pour effectuer des opérations de tri sur les données avant qu'elles ne soient renvoyées au client. Cela utilise soit de la mémoire ad hoc supplémentaire (séparée de shared_buffers), soit des fichiers temporaires sur le disque, ce qui est beaucoup plus lent.

Conseils de réglage : Un point de départ de base pour définir shared_buffers est de le définir à 1/4 de la valeur de la RAM système disponible. Cela permet au système d'exploitation d'effectuer également sa propre mise en cache des données, ainsi que tous les processus en cours d'exécution autres que la base de données elle-même.

L'augmentation de work_mem peut accélérer les opérations de tri, mais l'augmenter trop peut forcer l'hôte à manquer de mémoire, car la valeur définie peut être partiellement ou entièrement émise plusieurs fois par requête. Si plusieurs requêtes demandent plusieurs blocs de mémoire pour le tri, cela peut rapidement ajouter plus de mémoire que ce qui est disponible sur l'hôte. Gardez-le bas et augmentez-le lentement jusqu'à ce que les performances soient là où vous le souhaitez.

À l'aide de la commande "free" (telle que "free -h"), définissez effective_cache_size sur la somme de la mémoire libre et mise en cache. Cela permet au planificateur de requêtes de connaître le niveau de mise en cache du système d'exploitation éventuellement disponible et d'exécuter de meilleurs plans de requête.

Disque

Les performances du disque peuvent être l'un des éléments les plus importants à prendre en compte lors de la configuration d'un système. Les vitesses d'entrée / sortie sont importantes pour les charges de données volumineuses ou la récupération d'énormes quantités de données à traiter. Il détermine également la rapidité avec laquelle PostgreSQL peut synchroniser la mémoire avec le disque pour maintenir le pool de mémoire optimal.

Une certaine préparation dans les disques peut aider à améliorer instantanément les performances potentielles, ainsi que la pérennité du système de base de données pour la croissance.

• Disques séparés

  Une nouvelle installation de PostgreSQL créera le répertoire de données du cluster quelque part sur le lecteur principal (et éventuellement le seul) disponible sur le système.

  Une configuration de base utilisant plus de disques consisterait à ajouter un disque séparé (ou un ensemble de disques via RAID). Il a l'avantage d'avoir tous les transferts de données liés à la base de données fonctionnant sur un canal d'E/S différent du système d'exploitation principal. Cela permet également à la base de données de croître sans crainte d'un espace insuffisant causant des problèmes et des erreurs ailleurs dans le système d'exploitation.

  Pour les bases de données avec une activité extrême, le répertoire PostgreSQL Transaction Log (xlog) peut être placé sur un autre lecteur, séparant les E/S plus lourdes vers un autre canal éloigné du système d'exploitation principal ainsi que du répertoire de données principal. Il s'agit d'une mesure avancée qui aide à extraire plus de performances d'un système, qui pourrait autrement être proche de ses limites.

• Utiliser RAID

  La configuration du RAID pour les lecteurs de base de données protège non seulement contre la perte de données, mais peut également améliorer les performances si vous utilisez la bonne configuration RAID. RAID 1 ou 10 sont généralement considérés comme les meilleurs, et 10 offre la parité et la vitesse globale. RAID 5, cependant, tout en ayant des niveaux de redondance plus élevés, souffre d'une baisse significative des performances en raison de la façon dont il répartit les données sur plusieurs disques. Planifiez la meilleure option disponible avec beaucoup d'espace pour la croissance des données, et ce sera une configuration qui n'aura pas besoin d'être modifiée souvent, voire pas du tout.

• Utiliser un SSD

  Les disques SSD sont excellents pour les performances, et s'ils respectent le budget, les SSD d'entreprise peuvent accélérer les lourdes charges de travail de traitement de données jour et nuit. Les bases de données petites à moyennes avec des charges de travail petites à moyennes peuvent être exagérées, mais lorsque vous vous battez pour le plus petit pourcentage d'augmentation sur de grandes applications, le SSD peut être la solution miracle.

Conseils de réglage : Choisissez une configuration de disque qui convient le mieux à l'application en cours et qui dispose de suffisamment d'espace pour évoluer avec le temps à mesure que les données augmentent.

Si vous utilisez un SSD, définir random_page_cost sur 1,5 ou 2 (la valeur par défaut est 4) sera bénéfique pour le planificateur de requêtes, car la récupération aléatoire des données est beaucoup plus rapide que sur les disques en rotation.

Paramètres de configuration initiale

Lors de la première configuration de PostgreSQL, il existe une poignée de paramètres de configuration qui peuvent être facilement modifiés en fonction de la puissance de l'hôte. Au fur et à mesure que l'application interroge la base de données, un réglage spécifique peut être effectué en fonction des besoins de l'application. Cependant, ce sera le sujet d'un blog de réglage séparé.

Paramètres de mémoire

shared_buffers :défini sur 1/4 de la mémoire système. Si le système dispose de moins de 1 Go de mémoire totale, réglez sur ~ 1/8e de la mémoire système totale

work_mem :la valeur par défaut est de 4 Mo, et peut même être suffisante pour l'application en question. Mais si des fichiers temporaires sont souvent créés et que ces fichiers sont assez petits (des dizaines de mégaoctets), il peut être utile d'augmenter ce paramètre. Un paramètre de niveau d'entrée prudent peut être (1/4 de la mémoire système / max_connections). Ce paramètre dépend fortement du comportement réel et de la fréquence des requêtes vers la base de données, il ne doit donc être augmenté qu'avec prudence. Soyez prêt à le ramener aux niveaux précédents si des problèmes surviennent.

effective_cache_size :défini sur la somme de la mémoire libre et mise en cache signalée par la commande "free".

Paramètres des points de contrôle

Pour PostgreSQL 9.4 et versions antérieures :
checkpoint_segments :nombre de segments de points de contrôle (16 mégaoctets chacun) pour fournir le système Write Ahead Log. La valeur par défaut est 3 et peut être augmentée à 64 en toute sécurité, même pour les petites bases de données.

Pour PostgreSQL 9.5 et supérieur :
max_wal_size :cela a remplacé checkpoint_segments en tant que paramètre. La valeur par défaut est de 1 Go et peut rester ici jusqu'à ce que d'autres modifications soient nécessaires.

Sécurité

listen_address :ce paramètre détermine sur quelles adresses IP personnelles/cartes réseau écouter les connexions. Dans une configuration simple, il n'y en aura probablement qu'une seule, tandis que les réseaux plus avancés peuvent avoir plusieurs cartes pour se connecter à plusieurs réseaux. * Signifie écouter tout. Cependant, si l'application accédant à la base de données doit vivre sur le même hôte que la base de données elle-même, il suffit de la conserver en tant que "localhost".

Journalisation

Certains paramètres de journalisation de base qui ne surchargeront pas les journaux sont les suivants.

log_checkpoints = on
log_connections = on
log_disconnections = on
log_temp_files = 0