Base de données des optimisations/fine tuning


affiner vos paramètres de base de données pour en extraire le maximum de ce!

Bonjour ,

ce sont quelques-uns de mon expérience alors que j'était en train de construire un moteur de recherche et l'optimisation du la base de données postgresql vers sonic-vitesses!

Notre configuration pour le serveur Postgresql est:
Redhat 7.2
PIV 2.00 Ghz
1024MB de RAM

l'Une des premières choses que j'ai remarqué après la mise sur le Servlet programme, a été que, bien que les requêtes ont été retournés presque aussi rapide qu'à partir de la précédente MySQL basé sur le système, la charge sur le serveur est beaucoup plus élevé. Puis j'ai commencé à descendre dans les profondeurs de détails de choses. J'avais optimisé MySQL avant, en accroissant considérablement le cache et les tailles de tampon et en mettant plus de la ram vers le problème. Le seul truc qu'on a à faire avant de lancer Postgresql,est de fournir suffisamment de mémoire tampon partagée de l'espace. Mais alors,
Combien?
Il y a un débat houleux sur elle, entre des gens qui disent que, logiquement, la totalité de la RAM pourrait être consacrée comme contre ceux qui disent que de jeter plus de RAM, après une certaine limite n'a aucune utilisation. Le plus partagé cache de tampons que vous avez, le plus grand est le pourcentage de votre base de données qui ne cause pas de read() & #39 s ni de la mémoire de la copie de l'OS cache de tampons.Mais dans l'ensemble, vous aurez cache un petit nombre de blocs parce que vous allez être mise en mémoire tampon deux fois. Lorsque vous copiez un pâté de maisons de l'OS de la mémoire tampon de mémoire partagée, la copie existe encore dans le tampon de l'OS. De sorte que le bloc est maintenant tampon à deux reprises. Un seul disque I/O est beaucoup plus cher que des centaines de copies entre le tampon de l'OS cache et postgres & #39 de la mémoire partagée. Compte aussi de toutes les autres choses que vous & #39 re faire sur la machine & juste de petites choses, comme cron, par exemple. Tout ce qui prend de la mémoire. Par conséquent, il & #39 s dangereux de ne pas laisser le système d'exploitation de gérer une bonne partie de la mémoire.
Il arrive que ces deux facteurs opposés pourrait être tracée et faire un peu de une ligne chaque. L'idéal serait où ils ont franchi.

d'Ailleurs j'ai aussi optimisée des requêtes SQL spécifiquement adaptée à mon but. Un inconvénient majeur dans PostgreSQL réside dans la mise en œuvre de l'évaluation de requêtes contenant & #39 & #39 et & #39 EXISTE & #39 . Supposons que:
de la Requête 1. SÉLECTIONNEZ * à PARTIR de db1 where ID IN ((SELECT id from db2 OÙ word = & #39 & #39 ) ) LIMITE de 20
de la Requête 2. SÉLECTIONNEZ * à PARTIR de db1 where ID IN(1234,2345,1242,1256,1245,1567,2222,22,345,234,567,456,35,56)

(où ID est la clé primaire)

Le plus tard requête est numérisé à l'aide de l'index sur l'ID alors que l'ancien fonctionne dans un balayage séquentiel. Je pense que cette opération est appelée 'erreur de pilotage', dans lequel la base de données exécute la sous-requête pour chaque ligne de la requête externe. Au lieu de cela, si nous utilisons les JOINTURES explicites (comme ci-dessous), puis nous avons pu la force de la base de données à utiliser une analyse d'index à la place.
dernière question :
select * from db1, db2, db2 b
where id = un.identifiant et un.mot= & #39 word1 & #39
et id = b.id et b.mot= & #39 mot2 & #39
etc

NOTE: Vous pouvez également exécuter dans une analyse séquentielle, au lieu des analyse d'index, si le nombre de tuples à être scannés sont plus de 30 à 40% du total des tuples dans la table. Bien que ce qui peut être modifiée en modifiant les coefficients de pondération attribués à random_page_cost, cpu_tuple_cost, cpu_index_cost et cpu_operator_cost utilisées par l'optimiseur pour la fabrication de ces decesions.

j'ai aussi décidé de jeter plus de RAM pour le but. Je alloué 64 mo de RAM vers la mémoire tampon partagée de l'espace. Le fichier /var/lib/pgsql/data/postgresql.conf contient les paramètres pour le serveur de base de données. Postgresql utilise le système de mémoire partagée comme un tampon. Sur un système Linux, vous pouvez voir combien de mémoire partagée a été attribué par votre système en exécutant la commande:
cat /proc/sys/kernel/shmmax
Et pour afficher 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, ce qui pourrait ne pas être suffisant pour postgresql. J'ai augmenté cette limite de 64 MO en faisant la commande:
echo 67108864 > /proc/sys/kernel/shmmax

Vous avez besoin de placer cette ligne dans votre postgresql fichier de démarrage, ou en éditant /etc/rc.d/rc.fichier local pour une base plus permanente paramètre.Ensuite, dans notre postgresql.conf j'ai mis shared_buffers à 8192.J'ai aussi mis notre sort_mem 16384 (16Megs pour un tri zone de mémoire). Depuis le regroupement de connexion a été, en effet, j'ai mis max_connections à 50.
Et fsync a été également définie à false.

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

Un attelage que j'ai trouvé au départ était que le système a de construire et de démolir une connexion postgresql avec chaque demande. C'était insupportable, j'ai donc commencé à utiliser la connexion de regroupement de fonctionnalités fournies par la Résine (http://caucho.com).

& & -
Varun

Remerciements : Curt , Bruce , Andrew et tous pour effacer mes doutes!









Base de donnees des optimisations/fine tuning


Base de donnees des optimisations/fine tuning : Plusieurs milliers de conseils pour vous faciliter la vie.


affiner vos parametres de base de donnees pour en extraire le maximum de ce!

Bonjour ,

ce sont quelques-uns de mon experience alors que j'etait en train de construire un moteur de recherche et l'optimisation du la base de donnees postgresql vers sonic-vitesses!

Notre configuration pour le serveur Postgresql est:
Redhat 7.2
PIV 2.00 Ghz
1024MB de RAM

l'Une des premieres choses que j'ai remarque apres la mise sur le Servlet programme, a ete que, bien que les requetes ont ete retournes presque aussi rapide qu'a partir de la precedente MySQL base sur le systeme, la charge sur le serveur est beaucoup plus eleve. Puis j'ai commence a descendre dans les profondeurs de details de choses. J'avais optimise MySQL avant, en accroissant considerablement le cache et les tailles de tampon et en mettant plus de la ram vers le probleme. Le seul truc qu'on a a faire avant de lancer Postgresql,est de fournir suffisamment de memoire tampon partagee de l'espace. Mais alors,
Combien?
Il y a un debat houleux sur elle, entre des gens qui disent que, logiquement, la totalite de la RAM pourrait etre consacree comme contre ceux qui disent que de jeter plus de RAM, apres une certaine limite n'a aucune utilisation. Le plus partage cache de tampons que vous avez, le plus grand est le pourcentage de votre base de donnees qui ne cause pas de read() & #39 s ni de la memoire de la copie de l'OS cache de tampons.Mais dans l'ensemble, vous aurez cache un petit nombre de blocs parce que vous allez etre mise en memoire tampon deux fois. Lorsque vous copiez un pate de maisons de l'OS de la memoire tampon de memoire partagee, la copie existe encore dans le tampon de l'OS. De sorte que le bloc est maintenant tampon a deux reprises. Un seul disque I/O est beaucoup plus cher que des centaines de copies entre le tampon de l'OS cache et postgres & #39 de la memoire partagee. Compte aussi de toutes les autres choses que vous & #39 re faire sur la machine & juste de petites choses, comme cron, par exemple. Tout ce qui prend de la memoire. Par consequent, il & #39 s dangereux de ne pas laisser le systeme d'exploitation de gerer une bonne partie de la memoire.
Il arrive que ces deux facteurs opposes pourrait etre tracee et faire un peu de une ligne chaque. L'ideal serait ou ils ont franchi.

d'Ailleurs j'ai aussi optimisee des requetes SQL specifiquement adaptee a mon but. Un inconvenient majeur dans PostgreSQL reside dans la mise en œuvre de l'evaluation de requetes contenant & #39 & #39 et & #39 EXISTE & #39 . Supposons que:
de la Requete 1. SELECTIONNEZ * a PARTIR de db1 where ID IN ((SELECT id from db2 OU word = & #39 & #39 ) ) LIMITE de 20
de la Requete 2. SELECTIONNEZ * a PARTIR de db1 where ID IN(1234,2345,1242,1256,1245,1567,2222,22,345,234,567,456,35,56)

(ou ID est la cle primaire)

Le plus tard requete est numerise a l'aide de l'index sur l'ID alors que l'ancien fonctionne dans un balayage sequentiel. Je pense que cette operation est appelee 'erreur de pilotage', dans lequel la base de donnees execute la sous-requete pour chaque ligne de la requete externe. Au lieu de cela, si nous utilisons les JOINTURES explicites (comme ci-dessous), puis nous avons pu la force de la base de donnees a utiliser une analyse d'index a la place.
derniere question :
select * from db1, db2, db2 b
where id = un.identifiant et un.mot= & #39 word1 & #39
et id = b.id et b.mot= & #39 mot2 & #39
etc

NOTE: Vous pouvez egalement executer dans une analyse sequentielle, au lieu des analyse d'index, si le nombre de tuples a etre scannes sont plus de 30 a 40% du total des tuples dans la table. Bien que ce qui peut etre modifiee en modifiant les coefficients de ponderation attribues a random_page_cost, cpu_tuple_cost, cpu_index_cost et cpu_operator_cost utilisees par l'optimiseur pour la fabrication de ces decesions.

j'ai aussi decide de jeter plus de RAM pour le but. Je alloue 64 mo de RAM vers la memoire tampon partagee de l'espace. Le fichier /var/lib/pgsql/data/postgresql.conf contient les parametres pour le serveur de base de donnees. Postgresql utilise le systeme de memoire partagee comme un tampon. Sur un systeme Linux, vous pouvez voir combien de memoire partagee a ete attribue par votre systeme en executant la commande:
cat /proc/sys/kernel/shmmax
Et pour afficher l'utilisation de la memoire partagee sur le systeme:
ipcs
Le resultat sera en octets. Par defaut RedHat 7.2 alloue 32 mo de memoire partagee, ce qui pourrait ne pas etre suffisant pour postgresql. J'ai augmente cette limite de 64 MO en faisant la commande:
echo 67108864 > /proc/sys/kernel/shmmax

Vous avez besoin de placer cette ligne dans votre postgresql fichier de demarrage, ou en editant /etc/rc.d/rc.fichier local pour une base plus permanente parametre.Ensuite, dans notre postgresql.conf j'ai mis shared_buffers a 8192.J'ai aussi mis notre sort_mem 16384 (16Megs pour un tri zone de memoire). Depuis le regroupement de connexion a ete, en effet, j'ai mis max_connections a 50.
Et fsync a ete egalement definie a false.

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

Un attelage que j'ai trouve au depart etait que le systeme a de construire et de demolir une connexion postgresql avec chaque demande. C'etait insupportable, j'ai donc commence a utiliser la connexion de regroupement de fonctionnalites fournies par la Resine (http://caucho.com).

& & -
Varun

Remerciements : Curt , Bruce , Andrew et tous pour effacer mes doutes!


Base de données des optimisations/fine tuning

Base de données des optimisations/fine tuning : Plusieurs milliers de conseils pour vous faciliter la vie.
Recommander aux amis
  • gplus
  • pinterest

Messages récents

Commentaire

Laisser un commentaire

évaluation