Tout d'abord, utilisez toujours la dernière version de PostgreSQL. Les améliorations de performances sont toujours à venir, vous perdez donc probablement votre temps si vous réglez une ancienne version. Par exemple, PostgreSQL 9.2 améliore considérablement la vitesse de TRUNCATE et bien sûr ajoute des analyses d'index uniquement. Même les versions mineures doivent toujours être suivies ; voir la politique de version.
A ne pas faire
Ne faites PAS placez un tablespace sur un disque RAM ou un autre stockage non durable.
Si vous perdez un tablespace, toute la base de données peut être endommagée et difficile à utiliser sans un travail important. Il y a très peu d'avantages à cela par rapport à la simple utilisation de UNLOGGED tables et avoir beaucoup de RAM pour le cache de toute façon.
Si vous voulez vraiment un système basé sur un disque virtuel, initdb un tout nouveau cluster sur le ramdisk par initdb une nouvelle instance PostgreSQL sur le disque virtuel, vous disposez donc d'une instance PostgreSQL entièrement 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=off paramè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é contre les collisions, lui donnant la permission de supprimer totalement vos données si vous perdez de l'alimentation ou si le système d'exploitation tombe en panne.
Inutile de dire que vous ne devez jamais activer fsync=off en production, sauf si vous utilisez Pg comme base de données temporaire pour les données que vous pouvez régénérer ailleurs. Si et seulement si vous faites pour désactiver fsync peut également activer full_page_writes off, car il ne sert plus à rien alors. Méfiez-vous que fsync=off et full_page_writes postuler au cluster niveau, donc ils affectent tous bases de données dans votre instance PostgreSQL.
Pour une utilisation en production, vous pouvez éventuellement utiliser synchronous_commit=off et définissez un commit_delay , car vous obtiendrez bon nombre des mêmes avantages que fsync=off sans le risque géant de corruption des données. 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 le DDL, vous pouvez également utiliser UNLOGGED tables dans Pg 9.1+ pour éviter complètement la journalisation WAL et obtenir un véritable gain de vitesse au prix de l'effacement des tables si le serveur plante. Il n'y a pas d'option de configuration pour rendre toutes les tables déconnectées, elle doit être définie pendant CREATE TABLE . En plus d'être bon pour les tests, c'est pratique si vous avez des tables pleines de données générées ou sans importance 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 c'est le cas, vous devriez augmenter vos checkpoint_segments. Vous pouvez également ajuster votre checkpoint_completion_target pour lisser les écritures.
Réglez shared_buffers pour s'adapter à votre charge de travail. Cela dépend du système d'exploitation, de ce qui se passe d'autre sur votre machine et nécessite quelques essais et erreurs. Les valeurs par défaut sont extrêmement conservatrices. Vous devrez peut-être augmenter la limite maximale de mémoire partagée du système d'exploitation si vous augmentez shared_buffers sur PostgreSQL 9.2 et inférieur ; 9.3 et versions ultérieures ont modifié la façon dont ils utilisent la mémoire partagée pour éviter cela.
Si vous n'utilisez que quelques connexions qui font beaucoup de travail, augmentez work_mem pour leur donner plus de RAM pour jouer avec les tris, etc. Méfiez-vous d'un work_mem trop élevé Le paramètre peut entraîner des problèmes de mémoire insuffisante car il s'agit d'un tri par connexion et non d'une connexion, de sorte qu'une requête peut avoir plusieurs tris imbriqués. Toi seulement vraiment il faut augmenter work_mem si vous pouvez voir des tris se répandre sur le disque dans EXPLAIN ou connecté avec les log_temp_files paramètre (recommandé), mais une valeur plus élevée peut également permettre à Pg de choisir des plans plus intelligents.
Comme l'a dit 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. Les partitions séparées sont assez inutiles, vous voulez vraiment des disques séparés. Cette séparation a beaucoup moins d'avantages si vous utilisez fsync=off et presque aucun si vous utilisez UNLOGGED tableaux.
Enfin, ajustez vos requêtes. Assurez-vous que votre random_page_cost et seq_page_cost reflètent les performances de votre système, assurez-vous que votre effective_cache_size est correct, etc. Utilisez EXPLAIN (BUFFERS, ANALYZE) pour examiner les plans de requête individuels et activer le auto_explain module activé 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 ajustant les paramètres de coût.
AFAIK, il n'y a aucun moyen de définir une base de données ou un cluster entier comme UNLOGGED . Ce serait intéressant de pouvoir le faire. Pensez à demander sur la liste de diffusion PostgreSQL.
Réglage du système d'exploitation hôte
Il y a aussi quelques réglages que vous pouvez faire 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/s'ils arrivent sur le disque.
Sous Linux, vous pouvez contrôler cela avec le dirty_* du sous-système de mémoire virtuelle paramètres, comme dirty_writeback_centisecs .
Le seul problème avec le réglage des paramètres d'écriture différée trop lâche 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 se bloque lors des écritures. Vous pourrez peut-être atténuer ce problème en exécutant PostgreSQL sur un système de fichiers différent, mais certains vidages peuvent être au niveau du périphérique ou de l'hôte entier et non au niveau du système de fichiers, vous ne pouvez donc pas vous y fier.
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 souhaiterez peut-être vous assurer que vm.zone_reclaim_mode est défini sur zéro, car il peut entraîner de graves problèmes de performances avec les systèmes NUMA (la plupart des systèmes de nos jours) en raison d'interactions avec la façon dont PostgreSQL gère 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. Certaines sont des choses que vous pourriez être en mesure d'appliquer.
Si vous ne regroupez pas le travail dans des transactions plus importantes, commencez. De nombreuses petites transactions coûtent cher, vous devez donc regrouper les choses chaque fois que c'est possible et pratique de le faire. Si vous utilisez la validation asynchrone, cela est moins important, mais reste 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 de glisser un tas de données dans une table temporaire, de la manipuler comme bon vous semble, puis de faire un INSERT INTO ... SELECT ... pour le 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 de la ou des tables temporaires d'une session.
Si vous utilisez PostgreSQL 9.1 ou une version plus récente, vous pouvez utiliser UNLOGGED des tables pour les données que vous pouvez vous permettre de perdre, comme l'état de la session. Ceux-ci sont visibles dans différentes sessions et conservés entre les connexions. Ils sont tronqués si le serveur s'arrête de manière impropre et 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, ne DELETE FROM blah; . Utilisez TRUNCATE TABLE blah; Au lieu; c'est beaucoup plus rapide lorsque vous videz toutes les lignes d'une table. Tronquer plusieurs tables en un seul TRUNCATE appelle si tu peux. Il y a une mise en garde si vous faites beaucoup de TRUNCATES de petites tables encore et encore, cependant; voir :Vitesse de troncation Postgresql
Si vous n'avez pas d'index sur les clés étrangères, DELETE Les s impliquant les clés primaires référencées par ces clés étrangères seront horriblement lents. Assurez-vous de créer de tels index si jamais vous vous attendez à DELETE à partir du ou des tableaux référencés. Les index ne sont pas requis pour TRUNCATE .
Ne créez pas d'index dont vous n'avez pas besoin. Chaque index a un coût de maintenance. Essayez d'utiliser un ensemble minimal d'index et laissez les balayages d'index bitmap les combiner plutôt que de maintenir trop d'index multi-colonnes volumineux et coûteux. Lorsque des index sont nécessaires, essayez d'abord de remplir la table, puis créez des index à la fin.
Matériel
Avoir suffisamment de RAM pour contenir toute la base de données est une énorme victoire si vous pouvez la gérer.
Si vous n'avez pas assez de RAM, plus le stockage est rapide, mieux c'est. 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 protégés contre les pannes et peuvent consommer vos données.
Apprentissage
Le livre de Greg Smith, PostgreSQL 9.0 High Performance reste pertinent malgré la référence à une version un peu plus ancienne. Cela devrait être une référence utile.
Rejoignez la liste de diffusion générale de PostgreSQL et suivez-la.
Lecture :
- Régler votre serveur PostgreSQL – wiki PostgreSQL
- Nombre de connexions à la base de données - wiki PostgreSQL
