PostgreSQL Long VACUUM

Question

Je nettoie actuellement une table avec 2 index et 250 millions de lignes actives et environ autant de lignes mortes (ou plus). J'ai émis la commande VACCUM FULL ANALYZE de mon ordinateur client (ordinateur portable) sur mon serveur. Elle se consacre à ses activités depuis environ 3-4 jours; Je me demande si cela se terminera de sitôt car j'ai beaucoup de travail à faire!

Le serveur dispose d’un processeur Xeon à 2,66 GHz quad-code, d’une capacité de 12 Go ou de RAM et d’un contrôleur RAID relié à des disques SAS HD de 146 Go à 2 x 10 000 tr / min dans une configuration RAID 1; il utilise Suse Linux. Je me demande ...

Tout d’abord, le processus VACUUM postmaster semble ne faire appel qu’à un seul noyau. Deuxièmement, je n’observe pas un rapport temps d’écriture I / O très élevé. Troisièmement, en appelant procinfo , je peux extrapoler le fait que le processus VACUUM passe le plus clair de son temps (88%) à attendre I / 0.

Alors, pourquoi n'utilise-t-il pas plus de cœurs par le biais de threads afin de surcharger le contrôleur RAID (obtenir un nombre élevé d'écritures d'E / S sur un rapport inactif)? Pourquoi attend-il les E / S si la charge d'E / S n'est pas élevée? Pourquoi ne va-t-il pas plus vite avec tout ce pouvoir / ressources à sa portée? Il me semble que VACUUM peut et doit être multithread, en particulier s’il fonctionne sur une grande table et que c’est la seule qui fonctionne!

De plus, est-ce qu’il s’agit d’un moyen de configurer postgresql.conf pour le laisser multithread de tels VACUUM? Puis-je le tuer et continuer à bénéficier de son nettoyage partiel? Je dois travailler sur cette table.

[J'utilise PostgreSQL 8.1]

encore merci

Answer 1

Vous ne dites pas quelle version de PostgreSQL vous utilisez. Est-il possible que ce soit avant la 8.0?

J'ai eu exactement ce même scénario. Votre meilleur meilleur:

• tuer le vide
• sauvegardez la table avec l'option -g pg_dump
• déposez la table
• restaurer la table

Si vous utilisez la version 8.x, examinez les options autovacuum. Le vide est à thread unique, vous ne pouvez rien faire pour le faire utiliser plusieurs threads.

Answer 2

Quelques astuces:

• Lancez VACUUM FULL VERBOSE pour pouvoir voir ce qui se passe.
• Supprimez tous les index avant VACUUM. Il est plus rapide de les reconstruire que de les aspirer. Vous devez également les reconstruire de temps en temps car VACUUM FULL n’est pas assez bon (en particulier sur un vieux PosgreSQL comme 8.1).
• Définissez la valeur maintenance_work_mem sur une valeur très élevée.
• Utilisez un PostgreSQL plus récent. Btw, 8.4 aura une énorme amélioration en aspirant.

Une alternative à VACUUM est le vidage et la restauration.

Éditer: Depuis la version 9.0, VACUUM FULL réécrit l’ensemble du tableau. C’est fondamentalement la même chose que de faire un dump + restore, il est donc inutile d’exécuter REINDEX.

Answer 3

Êtes-vous sûr de ne rien avoir en cours qui puisse verrouiller les tables et empêcher le fonctionnement de l'aspirateur?

(Quoi qu'il en soit, il est préférable d'utiliser vacuum_cost_delay afin que le vide n’interrompe pas la production.)

Answer 4

L'ancien VACUUM FULL est un fossile. C'est assez lent aussi, et vous devez ensuite REINDEX. Ne l'utilisez pas. Si vous voulez vraiment défragmenter une table, utilisez CLUSTER ou ceci:

Disons qu'il vous reste un peu d’espace disque, c’est beaucoup plus rapide que dump & reload:

CREATE TABLE newtable AS SELECT * FROM oldtable;
CREATE INDEX bla ON newtable( ... );
ALTER TABLE oldtable RENAME TO archive;
ALTER TABLE newtable RENAME TO oldtable;

Notez que cela ne copiera pas vos contraintes. Vous pouvez utiliser CREATE TABLE LIKE ... pour les copier.

  

Alors pourquoi n'utilise-t-il pas plus de cœurs à travers les threads

pg ne supporte pas cela.