web-dev-qa-db-fra.com

Optimiser PostgreSQL pour un grand nombre de mises à jour INSERTS et bytea

Ce que nous avons (logiciel):

  • PostrgeSQL 9. avec la configuration de base (aucun changement dans postgresql.conf)
  • Windows 7 64 bits

Matériel:

  • Intel Core i7-3770 3,9 GHz
  • 32 Go de RAM
  • Lecteur WDC WD10EZRX-00L4HBAta (1000 Go, SATA III)

Nous devons donc charger dans DB aprox. 100.000.0 lignes avec bytea colonne, et plus simple 500.000.0 lignes (sans LOBs). Il y a 2 varchar index sur la 1ère table (avec 13, 19 longueurs) et 2 varchar index sur la 2ème table (18, 10 longueurs). Il existe également des séquences pour la génération d'ID pour chaque table.

À l'heure actuelle, ces opérations se font avec 8 connexions en parallèle avec une taille de lot de 50 JDBC. L'image ci-dessous montre la charge du système: il s'agit d'une charge nulle sur les processus postgresql. Après 24 heures de chargement, nous n'avons chargé que 10 000 000 lignes, ce qui est un résultat très lent.

enter image description here

Nous demandons de l'aide pour régler la configuration de PostrgreSQL dans le but de:

1) pour un chargement ultra rapide de cette quantité de données, il s'agit d'une opération unique, il peut donc s'agir d'une configuration temporaire

2) pour le mode de production pour faire un nombre modéré de SELECT dans ces 2 tables par leurs index sans jointure et sans tri.

postgresql-9.3insertperformancedatabase-tuningbyteaperformance-tuning
12
Andremoniy

Pour les performances de insert, voir accélération des performances d'insertion dans PostgreSQL et insertion en masse dans PostgreSQL .

Vous perdez votre temps avec le traitement par lots JDBC pour insert. PgJDBC ne fait rien d'utile avec les lots insert, il exécute simplement chaque instruction . <- Ce n'est plus le cas dans les nouvelles versions de PgJDBC, qui peuvent désormais préparer des instructions par lots pour réduire considérablement les temps d'aller-retour. Mais il vaut toujours mieux:

Utilisez COPY à la place; voir Copie par lots PgJDBC et CopyManager . Quant au nombre de chargeurs simultanés: visez un couple par disque, si les opérations sont liées aux E/S disque. Huit est probablement le plus que vous voudrez.

Pour votre "mode de production", je vous suggère de charger un échantillon de données, de configurer les requêtes que vous prévoyez d'exécuter et d'utiliser explain analyze pour étudier les performances. À des fins de test uniquement, utilisez le enable_ params pour explorer différentes sélections de plans. Définissez les paramètres de coût du planificateur de requêtes (random_page_cost, seq_page_cost, effective_cache_size, etc.) pour votre système et assurez-vous que shared_buffers est correctement défini. Continuez à surveiller lorsque vous ajoutez une charge de travail de production simulée, à l'aide de auto_explain module, log_min_duration_statement paramètre, le pg_stat_statements extension, etc.

Pour plus de détails, consultez le manuel d'utilisation de PostgreSQL. Je suggère de revenir ici lorsque vous avez un problème plus concret avec explain analyze détails d'exécution des requêtes, etc.

14
Craig Ringer