Tout d'abord, utilisez toujours la dernière version de PostgreSQL. Les améliorations des performances sont toujours à venir, donc vous perdez probablement votre temps si vous optimisez une ancienne version. Par exemple, PostgreSQL 9.2 améliore considérablement la vitesseTRUNCATE et ajoute bien sûr des analyses d'index uniquement. Même les versions mineures doivent toujours être suivies; voir la politique de version .
À ne pas faire
Ne placez PAS d' espace disque logique sur un disque RAM ou tout autre stockage non durable .
Si vous perdez un espace de table, la base de données entière peut être endommagée et difficile à utiliser sans travail important. Il y a très peu d'avantages par rapport à l'utilisation de UNLOGGEDtables et à beaucoup de RAM pour le cache de toute façon.
Si vous voulez vraiment un système basé sur ramdisk, initdbun tout nouveau cluster sur le ramdisk en initdbcréant une nouvelle instance PostgreSQL sur le ramdisk, vous avez donc une instance PostgreSQL complètement jetable.
Configuration du serveur PostgreSQL
Lors des tests, vous pouvez configurer votre serveur pour un fonctionnement non durable mais plus rapide .
C'est l'une des seules utilisations acceptables pour le fsync=offparamètre dans PostgreSQL. Ce paramètre indique à peu près à PostgreSQL de ne pas se soucier des écritures ordonnées ou de tout autre élément désagréable de protection de l'intégrité des données et de sécurité en cas de crash, ce qui lui permet de supprimer totalement vos données si vous perdez de l'énergie ou avez un crash du système d'exploitation.
Inutile de dire que vous ne devez jamais activer fsync=offen production à moins que vous n'utilisiez Pg comme base de données temporaire pour des données que vous pouvez recréer ailleurs. Si et seulement si vous faites pour désactiver fsync, vous pouvez également le full_page_writesdésactiver, car cela ne sert plus à rien. Méfiez-vous de cela fsync=offet full_page_writesappliquez-le au niveau du cluster , afin qu'ils affectent toutes les bases de données de votre instance PostgreSQL.
Pour une utilisation en production, vous pouvez éventuellement utiliser synchronous_commit=offet définir un commit_delay, car vous bénéficierez des mêmes avantages que fsync=offsans le risque de corruption des données géantes. Vous avez une petite fenêtre de perte de données récentes si vous activez la validation asynchrone - mais c'est tout.
Si vous avez la possibilité de modifier légèrement la DDL, vous pouvez également utiliser les UNLOGGEDtables de la Pg 9.1+ pour éviter complètement la journalisation WAL et obtenir une augmentation de vitesse réelle au prix de l'effacement des tables en cas de panne du serveur. Il n'y a pas d'option de configuration pour rendre toutes les tables non enregistrées, elle doit être définie pendant CREATE TABLE. En plus d'être bon pour les tests, cela est pratique si vous avez des tables remplies de données générées ou non importantes dans une base de données qui contient autrement des éléments dont vous avez besoin pour être en sécurité.
Vérifiez vos journaux et voyez si vous recevez des avertissements concernant trop de points de contrôle. Si vous l'êtes, vous devriez augmenter vos checkpoint_segments . Vous pouvez également ajuster votre checkpoint_completion_target pour lisser les écritures.
Ajustez shared_bufferspour s'adapter à votre charge de travail. Cela dépend du système d'exploitation, dépend de ce qui se passe avec votre machine et nécessite des essais et des erreurs. Les valeurs par défaut sont extrêmement conservatrices. Vous devrez peut-être augmenter la limite de mémoire partagée maximale du système d'exploitation si vous augmentez shared_bufferssur PostgreSQL 9.2 et inférieur; 9.3 et au-dessus ont changé la façon dont ils utilisent la mémoire partagée pour éviter cela.
Si vous utilisez seulement quelques connexions qui font beaucoup de travail, augmentez leur work_mempour leur donner plus de RAM pour jouer, etc. Attention, un work_memparamètre trop élevé peut provoquer des problèmes de mémoire insuffisante car il n'est pas par tri par connexion, donc une requête peut avoir plusieurs types imbriqués. Vous ne devez vraiment augmenter que work_memsi vous pouvez voir des tris se répandre sur le disque EXPLAINou se connecter avec le log_temp_filesparamètre (recommandé), mais une valeur plus élevée peut également permettre à Pg de choisir des plans plus intelligents.
Comme dit par une autre affiche ici, il est sage de mettre le xlog et les tables / index principaux sur des disques durs séparés si possible. Des partitions séparées sont assez inutiles, vous voulez vraiment des disques séparés. Cette séparation présente beaucoup moins d'avantages si vous utilisez fsync=offet presque aucune si vous utilisez des UNLOGGEDtables.
Enfin, ajustez vos requêtes. Assurez - vous que votre random_page_costet seq_page_costreflètent la performance de votre système, assurez -vous de votre effective_cache_sizeest correct, etc. Utilisez EXPLAIN (BUFFERS, ANALYZE)d'examiner les plans de requête individuels, et tourner le auto_explainmodule pour signaler toutes les requêtes lentes. Vous pouvez souvent améliorer considérablement les performances des requêtes simplement en créant un index approprié ou en modifiant les paramètres de coût.
AFAIK il n'y a aucun moyen de définir une base de données entière ou un cluster comme UNLOGGED. Ce serait intéressant de pouvoir le faire. Pensez à demander sur la liste de diffusion PostgreSQL.
Optimisation du système d'exploitation hôte
Vous pouvez également effectuer certains réglages au niveau du système d'exploitation. La principale chose que vous voudrez peut-être faire est de convaincre le système d'exploitation de ne pas vider les écritures sur le disque de manière agressive, car vous ne vous souciez vraiment pas de savoir quand / si elles arrivent sur le disque.
Sous Linux , vous pouvez contrôler cela avec le sous - système de mémoire virtuelle de » dirty_*paramètres, comme dirty_writeback_centisecs.
Le seul problème avec le réglage des paramètres d'écriture différée est trop lâche, c'est qu'un vidage par un autre programme peut entraîner le vidage de tous les tampons accumulés de PostgreSQL, provoquant de gros blocages pendant que tout bloque sur les écritures. Vous pouvez peut-être atténuer cela en exécutant PostgreSQL sur un autre système de fichiers, mais certaines vidanges peuvent être au niveau de l'appareil ou au niveau de l'hôte entier et non au niveau du système de fichiers, vous ne pouvez donc pas vous fier à cela.
Ce réglage nécessite vraiment de jouer avec les paramètres pour voir ce qui fonctionne le mieux pour votre charge de travail.
Sur les noyaux plus récents, vous pouvez vous assurer qu'il vm.zone_reclaim_modeest défini sur zéro, car cela peut entraîner de graves problèmes de performances avec les systèmes NUMA (la plupart des systèmes de nos jours) en raison des interactions avec la gestion de PostgreSQL shared_buffers.
Optimisation des requêtes et de la charge de travail
Ce sont des choses qui nécessitent des changements de code; ils peuvent ne pas vous convenir. Vous pourriez être en mesure d'appliquer certaines choses.
Si vous ne regroupez pas le travail en transactions plus importantes, commencez. Beaucoup de petites transactions sont chères, vous devriez donc grouper des trucs chaque fois que cela est possible et pratique. Si vous utilisez la validation asynchrone, cela est moins important, mais toujours fortement recommandé.
Dans la mesure du possible, utilisez des tables temporaires. Ils ne génèrent pas de trafic WAL, ils sont donc beaucoup plus rapides pour les insertions et les mises à jour. Parfois, cela vaut la peine d'intégrer un tas de données dans une table temporaire, de les manipuler comme vous le souhaitez, puis INSERT INTO ... SELECT ...de les copier dans la table finale. Notez que les tables temporaires sont par session; si votre session se termine ou si vous perdez votre connexion, la table temporaire disparaît et aucune autre connexion ne peut voir le contenu des tables temporaires d'une session.
Si vous utilisez PostgreSQL 9.1 ou une version plus récente, vous pouvez utiliser des UNLOGGEDtableaux pour les données que vous pouvez vous permettre de perdre, comme l'état de la session. Ceux-ci sont visibles sur différentes sessions et préservés entre les connexions. Ils sont tronqués si le serveur s'arrête de manière impure, ils ne peuvent donc pas être utilisés pour tout ce que vous ne pouvez pas recréer, mais ils sont parfaits pour les caches, les vues matérialisées, les tables d'état, etc.
En général, non DELETE FROM blah;. Utilisez TRUNCATE TABLE blah;plutôt; c'est beaucoup plus rapide lorsque vous videz toutes les lignes d'un tableau. Tronquez plusieurs tables en un seul TRUNCATEappel si vous le pouvez. Il y a cependant une mise en garde si vous faites beaucoup TRUNCATESde petites tables encore et encore; voir: Vitesse de troncature Postgresql
Si vous n'avez pas d'index sur les clés étrangères, les DELETEs impliquant les clés primaires référencées par ces clés étrangères seront horriblement lentes. Assurez-vous de créer de tels index si vous vous y attendez à DELETEpartir des tables référencées. Les index ne sont pas requis pour TRUNCATE.
Ne créez pas d'index dont vous n'avez pas besoin. Chaque indice a un coût de maintenance. Essayez d'utiliser un ensemble minimal d'index et laissez les analyses d'index bitmap les combiner plutôt que de maintenir trop d'index multicolonnes énormes et coûteux. Lorsque des index sont requis, essayez de remplir d'abord la table, puis créez des index à la fin.
Matériel
Avoir suffisamment de RAM pour contenir la base de données entière est une énorme victoire si vous pouvez la gérer.
Si vous n'avez pas assez de RAM, le stockage le plus rapide est le mieux. Même un SSD bon marché fait une énorme différence par rapport à la rouille en rotation. Ne faites pas confiance aux SSD bon marché pour la production, ils ne sont souvent pas sûrs et peuvent manger vos données.
Apprentissage
Le livre de Greg Smith, PostgreSQL 9.0 High Performance reste pertinent malgré une référence à une version un peu plus ancienne. Ce devrait être une référence utile.
Rejoignez la liste de diffusion générale PostgreSQL et suivez-la.
En train de lire: