web-dev-qa-db-fra.com

réglage postgresql pour de grandes quantités de RAM

J'ai deux serveurs identiques (en termes de matériel), ce sont tous les deux des installations standard de Windows Server 2008 R2, avec un minimum de logiciels installés (essentiellement mon code et des trucs requis comme jvm, etc.).

Sur un serveur, j'exécute le serveur SQL 2005, sur le deuxième serveur PostgreSQL 9.1. La différence de performances b/n ces 2 serveurs est stupéfiante, c'est tellement mauvais sur postgresql que je regrette mon discours initial "utilisons postgresql au lieu de payer la licence du serveur sql" à mon patron. Nous parlons de différences de 30 secondes contre 15 minutes pour la même commande, et ce n'est pas seulement cette seule commande, c'est n'importe quelle requête ou commande que je lance. Ils ont tous deux à peu près les mêmes données (les enregistrements ont été insérés dans un ordre différent), et les deux bases de données ont exactement la même structure/index, etc.

Mais j'espère que ce n'est qu'une question de réglage des performances. Le fait est que le serveur sql utilise à peu près les 32 concerts de RAM sur le serveur, tandis que postgresl n'utilise rien, certainement moins qu'un concert, même si je ne l'ai pas vraiment compris en détail.

Comment puis-je demander à postgresql d'utiliser plus de 20 concerts de RAM? Ces serveurs ont été construits spécifiquement pour ces trucs de base de données, donc tout ram non utilisé par la base de données et les processus de support est gaspillé à mon avis.

postgresqlmemory
29
user85116

Il existe de nombreuses constantes modifiables, initialisées via postgres.conf. Les plus importants sont:

  • max_connections: le nombre de sessions simultanées
  • work_mem: la quantité maximale de mémoire à utiliser pour les résultats intermédiaires tels que les tables de hachage et pour le tri
  • shared_buffers la quantité de mémoire dédiée à l'espace tampon "épinglé".
  • effective_cache_size la quantité de mémoire supposée être utilisée par les tampons LRU du système d'exploitation.
  • random_page_cost: une estimation du coût relatif des recherches de disques.

max_connections ne doit pas être réglé plus haut que nécessaire, les connexions coûtent des ressources même en cas d'inactivité; dans la plupart des cas, une connexion passerait plus de temps à attendre à l'intérieur qu'à attendre à l'extérieur. (au prix de la simultanéité) Une bonne formule empirique est "nombre de broches + nombre de processeurs + X"

work_mem est délicat: il peut être appliqué à chaque sous-requête, donc une requête avec 5 HASHJOINS peut coûter 5 * work_mem. Et dans le pire des cas, vous devriez également penser à plusieurs sessions consommant ce montant (encore une raison de conserver max_connections faible).

shared_buffers est (à mon humble avis) surfaite. Normalement, il est conseillé de le régler sur environ 1/4 ... 1/2 de toute la mémoire "libre" disponible, mais j'ai tendance à la maintenir basse et à définir effective_cache_size à toute la mémoire "libre" disponible.

random_page_cost est le coût d'une recherche + lecture sur le disque. Il est relatif au sequential_disk_cost, qui est 1. La valeur par défaut (4) pour random_page_cost est réglé trop haut pour les machines modernes et le stockage réseau, il peut normalement être abaissé entre 2 et 1.x. Pour les disques SSD, vous le définissez même sur 1.0, car la recherche est presque gratuite sur les SSD.

41
wildplasser

Pensez à utiliser pgtune pour vous aider à régler la configuration de PostgreSQL. De PgFoundry:

pgtune prend le postgresql.conf par défaut et étend le serveur de base de données pour être aussi puissant que le matériel sur lequel il est déployé

La configuration par défaut de PostgreSQL est très conservatrice et cet outil est destiné à aider avec cette situation exacte. La documentation est une lecture légère et l'utilisation de l'outil est assez simple.

Gardez à l'esprit qu'il n'est pas nécessaire d'utiliser les suggestions exactes de pgtune. Jouer avec ses paramètres et regarder les modifications qui en résultent dans le fichier conf vous donnera une meilleure compréhension de la configuration de PostgreSQL et comment l'ajuster manuellement.

20
Paul Bellora

Si chaque requête ou commande s'exécute lentement, je soupçonne que:

  • vous vous connectez à la base de données pour chaque requête que vous exécutez;
  • vous avez configuré une sorte de méthode d'authentification, qui ne fonctionne pas et arrête vos requêtes jusqu'à ce que cette méthode d'authentification expire.

Pourriez-vous s'il vous plaît nous dire combien de temps il faut pour exécuter une requête comme select version()? Si devrait être instantané (0,16ms sur mon poste de travail).

3
Tometzky

Si CHAQUE requête est beaucoup plus lente, quelque chose ne va pas avec le serveur ou quelque chose. D'après mon expérience, chaque base de données a quelques points sur lesquels elle est meilleure que l'autre, mais pgsql en termes de performances est facilement dans le même domaine que le serveur mssql.

Alors, sur quel OS utilisez-vous pgsql? Quel matériel? Quels paramètres avez-vous déjà modifiés? Quelle est la taille de votre jeu de données? Qu'est-ce qu'un exemple d'une requête médiocre et la sortie d'expliquer analyser (Exécutez votre requête comme ceci:

expliquer analyser sélectionner ... reste de la requête ici ...;

Publiez la sortie sur http://explain.depesz.com/ et publiez le lien ici.

2
Scott Marlowe