Base de données Optimisations / fine tuning

Affiner les paramètres de votre base de données pour en extraire le maximum d'elle!

Bonjour,

Ce sont quelques-unes de mes expériences, tout i est en train de construire un moteur de recherche et la base de données PostgreSQL optmising vers sonic-vitesse!

Notre configuration de serveur PostgreSQL:
Redhat 7.2
PIV 2.00 Ghz System
1024MB RAM

Une des premières choses que j'ai remarqué après avoir allumé le Servlet programme, bien que les requêtes ont été retournés presque aussi rapide que le précédent système basé sur MySQL, la charge sur le serveur a été beaucoup plus élevé. Puis j'ai commencé à descendre dans les profondeurs des détails des choses. J'ai eu avant MySQL optimisé en accroissant la taille de cache et de tampon et de lancer plus de RAM à l'égard du problème. La principale chose que l'on a à faire avant de lancer Postgresql, est de fournir suffisamment de tampon de l'espace. Mais alors,
How much is enough?
Il ya un débat à ce sujet, entre les gens qui disent que, logiquement, l'ensemble de la RAM pourrait être consacrée à l'encontre de ceux qui disent que le lancer plus de RAM, après une certaine limite a pas d'utilisation. Le buffer cache plus partagée que vous avez, plus le pourcentage de votre base de données, qui n'entraîne pas de read (), ni la copie de la mémoire tampon de l'OS cache.But globale, vous cache un petit nombre de blocs, car vous serez deux fois en mémoire tampon . Lorsque vous copiez un bloc de l'OS de tampon de mémoire partagée, le texte existe toujours dans la mémoire tampon OS. Donc, ce bloc est maintenant en mémoire tampon à deux reprises. Un seul disque I / O est nettement plus cher que des centaines de copies entre les OS et postgres buffer cache "la mémoire partagée. Également envisager toutes les autres choses que vous faites sur la machine - il suffit de petites choses, comme cron et autres. Tout ce que prend la mémoire. Par conséquent, il est dangereux de ne pas laisser l'OS de gérer une bonne partie de la mémoire.
Il arrive que ces deux facteurs pourraient être relevées et faire un peu d'une ligne chacune. L'idéal serait le point où ils ont traversé.

En plus j'ai aussi d'optimiser les requêtes SQL spécialement conçues pour mon but. Un inconvénient majeur réside dans PostgreSQL dans la mise en œuvre de l'évaluation des requêtes contenant «IN» et «existe». Supposons:
Requête 1. SELECT * FROM db1 WHERE ID IN ((SELECT id FROM db2 WHERE mot = 'ce que')) LIMIT 20;
Requête 2. SELECT * FROM db1 WHERE ID IN (1234,2345,1242,1256,1245,1567,2222,22345234567456,35,56);

(où est l'ID de clé primaire)

La requête est ensuite scanné en utilisant l'indice sur l'ID alors que l'ancien fonctionne dans une analyse séquentielle. Je pense que c'est ce qu'on appelle "l'erreur du pilote" dans lequel la base de données exécute le sous-requête pour chaque ligne de la requête externe. Au lieu de cela, si nous utilisons JOINS explicite (comme ci-dessous), alors nous pouvons vigueur de la base de données pour l'utilisation d'un balayage d'index place.
Final Requête:
select * from db1, db2 a, b db2
où id = a.id et a.word = 'mot1'
et id = b.id et b.word = 'mot2'
etc

NOTE: Vous pouvez aussi lancer dans une analyse séquentielle, au lieu d'un balayage d'index devrait, si le nombre de tuples à scanner sont plus que 30-40% de l'ensemble des tuples dans la table. Bien que ce peut être modifiée en changeant les pondérations attribuées à random_page_cost, cpu_tuple_cost, cpu_index_cost et cpu_operator_cost utilisé par l'optimiseur pour rendre ces decesions.

J'ai également décidé de lancer plus de mémoire pour la fin. Je alloué de 64 Mo de RAM vers le tampon de l'espace partagé. Le fichier / var / lib / pgsql / data / postgresql.conf contient les paramètres du serveur de base de données. Postgresql système utilise la mémoire partagée comme un tampon. Sur un système Linux, vous pouvez voir combien de mémoire partagée ont été attribués par votre système en exécutant la commande:
cat / proc / sys / kernel / shmmax
Et pour visualiser l'utilisation de la mémoire partagée sur le système:
ipcs
Le résultat sera en octets. Par défaut, RedHat 7.2 alloue 32 Mo de mémoire partagée, qui pourrait ne pas être suffisant pour postgresql. J'ai augmenté cette limite à 64 Mo en faisant la commande:
67108864 echo> / proc / sys / kernel / shmmax

Vous avez besoin de placer cette ligne dans votre fichier de démarrage de postgresql, ou en éditant le fichier / etc / rc.d / rc.local pour une plus permanent dans notre setting.Then postgresql.conf je shared_buffers à 8192.I également notre sort_mem au 16384 (16Megs une sorte de zone de mémoire). Depuis la mise en relation est en effet, je max_connections à 50.
Et fsync a également été mis à false.

shared_buffers = 8192
sort_mem = 16384
max_connections = 50
fsync = false

Un attelage d'abord j'ai trouvé que le système devait mettre en place et démonter un postgresql l'égard de chaque demande. Cela est intolérable, alors j'ai commencé à utiliser la connexion mise en fonctionnalités fournies par la résine (http://caucho.com).

-----
Varun

Remerciements: Curt, Bruce, Andrew et tous mes doutes de compensation!