Optimisation des requêtes PostgreSQL et processus Postmaster '

Question

Je travaille actuellement avec une plus grande base de données PostgreSQL dérivée de wikipedia-dump; il contient environ 40 Go de données. La base de données s'exécute sur un serveur HP Proliant ML370 G5 avec Suse Linux Enterprise Server 10; Je l'interroge depuis mon ordinateur portable sur un réseau privé géré par un simple routeur D-Link. J'ai attribué des adresses IP statiques DHCP (privées) à l'ordinateur portable et au serveur.

Quoi qu'il en soit, depuis mon ordinateur portable, en utilisant pgAdmin III, j'envoie des commandes / requêtes SQL; Certains d'entre eux sont CREATE INDEX, DROP INDEX, DELETE, SELECT, etc. Parfois, j'envoie une commande (comme CREATE INDEX), elle retourne, m'indiquant que la requête a été exécutée parfaitement, etc. Cependant, le processus postmaster affecté à un tel La commande semble rester en veille sur le serveur. Cela ne me dérange pas vraiment, car je me dis que PostgreSQL maintient un pool de postmasters prêts à traiter les requêtes. Pourtant, si ce processus consomme 6 Go de mémoire RAM allouée de 9,4 Go, je suis inquiet (et c'est le cas pour le moment). Maintenant, c’est peut-être un cache de données qui est conservé dans la mémoire [partagée] au cas où une autre requête aurait besoin d’utiliser ces mêmes données, mais je ne le sais pas.

Une autre chose me dérange.

J'ai 2 tables. L’une est la table page ; J'ai un index sur sa colonne page_id . L'autre est les tables pagelinks qui ont la colonne pl_from qui ne fait référence à rien ou à une variable de la colonne page.page_id ; contrairement à la colonne page_id , le pl_from ne possède pas encore d'index. Pour vous donner une idée de l’échelle des tables et de la nécessité de trouver une solution viable, la table page contient 13,4 millions de lignes (après avoir supprimé celles dont je n’ai pas besoin), tandis que la pagelinks table a 293 millions de dollars.

Je dois exécuter la commande suivante pour nettoyer la table pagelinks de certaines de ses lignes inutiles:

DELETE FROM pagelinks USING page WHERE pl_from NOT IN (page_id);

Donc, en gros, je souhaite débarrasser la table pagelinks de tous les liens provenant d'une page ne figurant pas dans la table page . Même après avoir désactivé les boucles imbriquées et / ou les analyses séquentielles, l’optimiseur de requêtes me fournit toujours la "solution" suivante:

Nested Loop  (cost=494640.60..112115531252189.59 rows=3953377028232000 width=6)
  Join Filter: ("outer".pl_from <> "inner".page_id)"
  ->  Seq Scan on pagelinks  (cost=0.00..5889791.00 rows=293392800 width=17)
  ->  Materialize  (cost=494640.60..708341.51 rows=13474691 width=11)
        ->  Seq Scan on page  (cost=0.00..402211.91 rows=13474691 width=11)

Il semble qu’une telle tâche prendrait plus de semaines. évidemment, c'est inacceptable. Il me semble que je préférerais de beaucoup utiliser l’index page_id pour faire son travail ... mais c’est un optimiseur obstiné et je me trompe peut-être.

Answer 1

En effet, j'ai décidé de créer une table temporaire pour accélérer l'exécution de la requête:

CREATE TABLE temp_to_delete AS(
    (SELECT DISTINCT pl_from FROM pagelinks) 
        EXCEPT 
    (SELECT page_id FROM page));
DELETE FROM pagelinks USING temp_to_delete 
    WHERE pagelinks.pl_from IN (temp_to_delete.pl_from);

Étonnamment, cette requête s’est achevée en environ 4 heures, alors que la requête initiale était restée active pendant environ 14 heures avant que je décide de la tuer. Plus précisément, le DELETE renvoyé:

Query returned successfully: 31340904 rows affected, 4415166 ms execution time.

En ce qui concerne la première partie de ma question, il semble que le processus postmaster garde effectivement certaines informations dans le cache; lorsqu'une autre requête nécessite des informations ne se trouvant pas dans le cache et de la mémoire (RAM), le cache est vidé. Et les maîtres de poste ne sont en effet qu'un pool de processus ».

Je me suis aussi rendu compte que le gnome-system-monitor est un mythe, car il fournit des informations incomplètes et n'a aucune valeur informative. C’est principalement à cause de cette application que j’ai été si confus ces derniers temps; par exemple, il ne tient pas compte de l'utilisation de la mémoire par d'autres utilisateurs (comme l'utilisateur postgres!) et me dit même qu'il me reste 12 Go de RAM lorsqu'il en est ainsi. Par conséquent, j’ai essayé quelques moniteurs système car j’aime savoir comment postgreSQL utilise ses ressources, et il semble que xosview soit effectivement un outil valide.

J'espère que ça aide!

Answer 2

À votre deuxième question; vous pouvez essayer de créer une nouvelle table avec uniquement les enregistrements dont vous avez besoin avec une instruction CREATE TABLE AS; si la nouvelle table est suffisamment petite, elle sera peut-être plus rapide, mais cela n’aidera pas non plus.

Answer 3

Votre processus postmaster y restera tant que la connexion au client sera ouverte. Est-ce que pgadmin ferme la connexion? Je ne sais pas.

La mémoire utilisée peut être shared_buffers (vérifiez vos paramètres de configuration) ou non.

Maintenant, la requête. Pour les opérations de maintenance importantes telles que celle-ci, n'hésitez pas à définir work_mem sur une taille importante, telle que quelques Go. Vous semblez avoir beaucoup de mémoire vive, utilisez-la.

définissez work_mem sur '4 Go'; EXPLAIN DELETE FROM pagelinks WHERE pl_from NOT IN (SELECT page_id FROM page);

Il convient de numériser la page, de l’analyser et d’analyser les liens de page, puis de jeter un coup d’œil furtif dans le hachage afin de rechercher des identifiants de page. Il devrait être assez rapide (beaucoup plus rapide que 4 heures!), Mais vous avez besoin d’un gros work_mem pour le hachage.

Mais puisque vous supprimez une partie importante de votre table, il pourrait être plus rapide de le faire comme ceci:

CREATE TABLE pagelinks2 AS SELECT a. * FROM pagelinks a JOIN pages b ON a.pl_from = b.page_id;

(vous pouvez utiliser un simple JOIN au lieu de IN)

Vous pouvez également ajouter un ORDER BY sur cette requête et votre nouvelle table sera bien ordonnée sur le disque pour un accès optimal plus tard.