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

29

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 à mon avis gaspillé.

user85116
la source
4
Avez-vous changé quoi que ce soit au réglage initial? Étape 1: SET effective_cache_size=18G;(le paramètre par défaut est extrêmement bas) BTW: en supposant qu'il s'agit d'une machine 64 bits (pas de PTE)
1
Vous ne nous donnez vraiment pas assez pour aider beaucoup. À part "C'est lent", nous ne savons pas grand-chose sur votre jeu de données, comment vous y accédez, quels types de requêtes s'exécutent généralement lentement, ce que vous avez déjà fait pour régler (et éventuellement mal régler) votre serveur. Heck, sur une machine Linux avec beaucoup de cœurs et de canaux de mémoire, vous pouvez obtenir des performances merdiques bien avant d'avoir installé postgresql. Êtes-vous lié au processeur ou aux E / S? Quels paramètres non par défaut possédez-vous déjà? Quels types de requêtes sont lents?
Scott Marlowe
2
Postgres n'utilise pas "ram" comme vous en parlez. Il repose sur le cache de page du système de fichiers du système d'exploitation pour la majeure partie de sa mise en cache.Par conséquent, lorsque vous observez l'utilisation de RAM sur un système exécutant postgres, vous voyez généralement de nombreux Go utilisés par les tampons / cache du système d'exploitation, et les processus d'arrière-plan postgres individuels en utilisant seulement quelques-uns pour quelques dizaines de Mo chacun.
dbenhur
1
Voir ce lien: tekadempiere.blogspot.ae/2014/09/… Et trouvez vos valeurs de conf basées sur les ressources d'ici: pgtune.leopard.in.ua
Sajeev
question connexe, peut-être d'intérêt: stackoverflow.com/questions/47311485/…
mountainclimber

Réponses:

41

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 de recherche de disque.

max_connectionsne doit pas être réglé plus haut que nécessaire, les connexions coûtent des ressources même lorsqu'elles sont inactives; 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 belle formule de base est "nombre de broches + nombre de processeurs + X"

work_memest délicat: il peut être appliqué à chaque sous-requête, donc une requête avec 5 HASHJOINSpeut coûter 5 * work_mem. Et pour les pires scénarios, vous devriez également penser à plusieurs sessions consommant ce montant (encore une raison de rester max_connectionsfaible).

shared_buffersest (à 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 à régler effective_cache_sizesur toute la mémoire "libre" disponible.

random_page_costest le coût d'une recherche + lecture sur le disque. Elle est relative à la sequential_disk_cost, qui est 1. La valeur par défaut (4) random_page_costest trop élevée pour les machines modernes et le stockage réseau, elle peut normalement être abaissée 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.

sauvage
la source
Excellent! Je n'ai jamais vu la signification de effective_cache_size, toujours dupe uniquement avec shared_buffers. Cela a vraiment fait une énorme différence. Je lance également pgtune et il a recommandé que 20 Go de 96 soient utilisés pour shard_buffers, mais 64 Go pour effective_cache_size. Merci!
1
FWIW, je suis passé par ceux-ci et les autres paramètres suggérés dans les documents Postgres, et j'ai fait une analyse pour notre serveur .
mlissner
Merci beaucoup pour la réponse. Puis-je demander quelle est la valeur recommandée work_memlorsque la max_connectionsvaleur par défaut est 100 et que la RAM du serveur est de 32 Go (serveur dédié PostgreSQL)? Je savais que je devais régler cela moi-même en fonction des requêtes quotidiennes. Je me demande simplement si vous pouvez me dire une valeur "réponse unique" (ou une valeur de point de départ). Est-ce que 50 Mo sont trop gros? Merci beaucoup.
sgon00
Cela dépend de l'activité simultanée typique sur votre machine. 100 sessions voulant 50M (en plus de leur 10..20M) chacune pourraient convenir. Ou peut-être pas. Pour vous faire une idée, surveillez vmstat ou top. Le plus: cela dépend de votre requête (et des autres). Regardez les plans.
Wildplasser
@wildplasser merci beaucoup pour la réponse rapide. J'ai trouvé un site Web intéressant pgtune.leopard.in.ua . Je pense que je vais utiliser 40 Mo comme point de départ de sa suggestion et de la mélodie en fonction de cela. À votre santé.
sgon00
20

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

pgtune prend le postgresql.conf par défaut wimpy 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 censé 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 changements qui en résultent dans le fichier conf vous donnera une meilleure compréhension de la configuration de PostgreSQL et comment la modifier manuellement.

Paul Bellora
la source
8
La dernière mise à jour de pgtune date de 2009, il y a 5 ans et compte toujours. Je me demande si c'est toujours valable pour les séries 9.1-9.2-9.3.
sorin
9
pgtune est maintenant disponible en ligne
Alfabravo
3

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).

Tometzky
la source
2

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 système d'exploitation exécutez-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.

Scott Marlowe
la source
1
Oui, chaque requête / commande s'exécute lentement, et oui "quelque chose" est terriblement mal d'où ma question. Le problème est que mssql utilise pleinement le ram disponible sur le serveur (donc la mise en cache lourde) alors que psql ne l'est pas. J'apprécie les commentaires et les conseils, mais vous avez dû manquer l'essentiel de ma question et la ligne d'objet elle-même ... Je veux juste savoir comment obtenir psql pour utiliser le ram disponible; essaye actuellement quelques suggestions listées par les autres ...
user85116
1
L'utilisation de votre RAM n'est PAS le problème. Postgresql s'appuie sur le système d'exploitation pour effectuer la plupart de la mise en cache. Ainsi, il n'a PAS BESOIN d'utiliser toute la RAM. Encore une fois, vous avez manqué l'essentiel de mon point. Vous nous donnez peu de choses précieuses pour vous aider. Je conduis 5000 grappes postgresql TPS pour gagner ma vie. Vous pouvez suivre mes conseils ou continuer à penser que vous savez comment fonctionne pgsql et argumenter.
Scott Marlowe
@ user85116, écoutez Scott, nous avons déjà un flux de travail avec MySQL qui dépend de la super latence, donc actuellement MySQL utilise 64 Go de RAM pour faire les requêtes rapidement, alors que la même chose peut être réalisée sur 2G Postgres avec seulement des vues matérialisées. La mise en cache de toute la base de données dans la RAM ne résoudra pas votre problème, elle le rend juste moins visible. Si vous rencontrez les mêmes problèmes dans la structure DB, Postgres ne le résoudra pas pour vous et n'essayera pas de le cacher.
kworr