Optimiser PostgreSQL pour de nombreuses mises à jour INSERTS et bytea

Ce que nous avons (logiciel):

• PostrgeSQL 9.3 avec 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 000 lignes avec colonne bytea et plus simples 500 000 000 lignes (sans LOB). Il y a 2 varcharindex sur la 1ère table (avec 13, 19 longueurs) et 2 varcharindex 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 n'y a aucune charge sur les postgresqlprocessus. Après 24 heures de chargement, nous n'avons chargé que 10 000 000 lignes, ce qui est un résultat très lent.

Nous demandons de l'aide pour régler la PostrgreSQLconfiguration 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.

Pour les insertperformances, voir accélérer les performances d'insertion dans PostgreSQL et l' insertion en bloc dans PostgreSQL .

Vous perdez votre temps avec le traitement par lots JDBC insert. PgJDBC ne fait rien d'utile avec les insertlots, 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 COPYplutôt; voir la copie par lots de PgJDBC et le 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 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 analyzepour étudier les performances. À des fins de test uniquement, utilisez les enable_paramètres 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.) de manière appropriée pour votre système, et assurez - vous shared_buffersest fixé de façon appropriée. Continuez à surveiller pendant que vous ajoutez une charge de travail de production simulée, en utilisant le auto_explainmodule, le log_min_duration_statementparamètre, l' pg_stat_statementsextension, 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 analyzeles détails d'exécution des requêtes, etc.