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

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.

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.

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

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.