Vous n'êtes pas identifié(e).
J'irais même plus loin que Julien. Après utilisation de pg_resetxlog, il est essentiel de faire une sauvegarde de toutes les bases, de réinitialiser l'instance et de restaurer toutes les bases. En priant très fort que la restauration se passe bien. (autrement dit, garder le répertoire de l'ancienne instance quelque part, on ne sait jamais !)
Guillaume.
Hors ligne
Bonsoir rjuju,
Merci de ton conseil. Elles paraissent correctes (vérification visuel et applicatif). Néanmoins, s'il existe un outil postgres pour faire une vérification global (une sorte de checksum 
) je suis preneur. Encore merci.
Je me retrouve confronté à un soucis de performance lors de mes ajouts en masse avec COPY, où le serveur me retourne un :
Mémoire épuisée
Assez étrange d'ailleurs, car 2 fichiers sont passés auparavant, là il bloque sur le 3ème (même taille que les autres, ~3.3Go et ~60 000 000 lignes). J'ai augmenté le shared_buffers à 3Go (j'ai 16Go de ram), mais aucun changement.
Edit : merci à toi gleu, je vais procéder ainsi.
Dernière modification par gchanteloube (13/02/2015 01:06:46)
Hors ligne
s'il existe un outil postgres pour faire une vérification global (une sorte de checksum wink)
Non, ça n'existe pas. D'ailleurs, il n'y a pas de checksum sur les fichiers de données. La 9.3 permet d'en ajouter.
J'ai augmenté le shared_buffers à 3Go
Un message de type "mémoire épuisée" ne peut pas venir du shared_buffers.
Guillaume.
Hors ligne
Alors que voudrait dire : psql:processing/db/2_db.sql:37206258: mémoire épuisée ? Sachant que la mémoire serveur n'est pas toute utilisée ... Je vais continuer mes investigations
Hors ligne
Je ne sais pas, mais pas du shared_buffers. Ce dernier est alloué au démarrage. Si la mémoire est dispo, PostgreSQL démarre. Sinon il ne démarre pas.
Guillaume.
Hors ligne
Bonsoir,
Après de multiples soucis, le serveur en version 9.4 est en prod !
Voici le résultat de ta demande gleu :
model_gfs_025=> EXPLAIN (ANALYZE, BUFFERS) select * from last_run_025 where latitude = 57.50 and longitude = 33.25;
QUERY PLAN
------------------------------------------------------------------------------------------------------------------------------------------
Index Scan using lat_lng_gfs_025 on last_run_025 (cost=0.57..1351.22 rows=334 width=67) (actual time=22.499..1539.051 rows=238 loops=1)
Index Cond: ((latitude = 57.5::double precision) AND (longitude = 33.25::double precision))
Buffers: shared read=243
Planning time: 18.287 ms
Execution time: 1539.456 ms
(5 lignes)
En voici un autre avec des coordonnées différentes :
model_gfs_025=> EXPLAIN (ANALYZE, BUFFERS) select * from last_run_025 where latitude = 51.50 and longitude = 36.25;
QUERY PLAN
-----------------------------------------------------------------------------------------------------------------------------------------
Index Scan using lat_lng_gfs_025 on last_run_025 (cost=0.57..876.89 rows=217 width=67) (actual time=15.236..1364.727 rows=238 loops=1)
Index Cond: ((latitude = 51.5::double precision) AND (longitude = 36.25::double precision))
Buffers: shared hit=2 read=241
Planning time: 0.210 ms
Execution time: 1364.885 ms
(5 lignes)
Merci à tous en tout cas pour vos aides. Il me reste maintenant à comprendre pourquoi la requête prend 1.5s et comment diminuer ce coût sans changer de serveur.
Hors ligne
Parfait. La ligne intéressante est "Buffers: shared read=243", ce qui veut dire que l'index est lu par le système d'exploitation (ie, il n'est pas dans le cache PostgreSQL). Donc les 1;5 seconde, c'est bien avec un cache à froid. Reste à savoir si ça sera le cas le plus fréquent ou pas. Ça veut dire aussi que PostgreSQL lit 1.9 Mo de données, ce qui fait des lignes à 8 Ko, aucune idée si c'est cohérent ou pas. Il serait intéressant de voir ce que raconte la table pg_statio_user_tables et pg_statio_user_indexes pour les objets de cette requête.
Guillaume.
Hors ligne
En théorie gleu, les utilisateurs vont se connecter de partout vu que c'est une application mobile à destination du grand public ... Du coup, la plus part du temps le cache sera à froid comme tu le dis.
Les lignes sont en effet très petites.
Je ne sais pas si c'est ce que tu attends, mais voici les infos :
model_gfs_025=> select * from pg_statio_user_indexes;
relid | indexrelid | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
-------+------------+------------+--------------+-----------------+---------------+--------------
24592 | 24605 | public | last_run_025 | lat_lng_gfs_025 | 16 | 15
model_gfs_025=> select * from pg_statio_user_tables;
relid | schemaname | relname | heap_blks_read | heap_blks_hit | idx_blks_read | idx_blks_hit | toast_blks_read | toast_blks_hit | tidx_blks_read | tidx_blks_hit
-------+------------+--------------+----------------+---------------+---------------+--------------+-----------------+----------------+----------------+---------------
24592 | public | last_run_025 | 21934277 | 20803384 | 16 | 15 | | | |
Dernière modification par gchanteloube (13/02/2015 23:14:11)
Hors ligne
Ce serait bien de les vider (pg_stat_reset()), puis d'exécuter la requête et enfin de lire les stats. On saurait ainsi exactement le nombre de blocs lus dans chaque objet.
Guillaume.
Hors ligne
Au temps pour moi. Chose faite :
model_gfs_025=> select * from pg_statio_user_indexes;
relid | indexrelid | schemaname | relname | indexrelname | idx_blks_read | idx_blks_hit
-------+------------+------------+--------------+-----------------+---------------+--------------
24592 | 24605 | public | last_run_025 | lat_lng_gfs_025 | 5708574 | 85
(1 ligne)
model_gfs_025=> select * from pg_statio_user_tables;
relid | schemaname | relname | heap_blks_read | heap_blks_hit | idx_blks_read | idx_blks_hit | toast_blks_read | toast_blks_hit | tidx_blks_read | tidx_blks_hit
-------+------------+--------------+----------------+---------------+---------------+--------------+-----------------+----------------+----------------+---------------
24592 | public | last_run_025 | 23970250 | 22113815 | 5708574 | 85 | | | |
(1 ligne)
Hors ligne
OK, donc un seul index est lu, sans parler de la table. Ça fait beaucoup de lecture. En dehors d'avoir un cache plus grand, je ne vois pas ce qu'il serait possible de faire.
Guillaume.
Hors ligne
Penses-tu à une augmentation du cache côté matériel, OS ou postgres (si c'est possible bien sûr) ?
Merci à toi gleu.
Edit : je viens changer la valeur de effective_cache_size à 1/4 de ma ram (4 Go). Aucun changement flagrant sur la durée d'exécution des requêtes à froid.
Dernière modification par gchanteloube (14/02/2015 19:25:26)
Hors ligne
Il n'y a aucun moyen d'augmenter le cache OS : il évolue suivant les demandes des autres logiciels. Je parlais donc du cache PostgreSQL.
Modifier le effective_cache_size ne peut qu'améliorer la prise en compte des index. Or, la requête utilise déjà un index. Pas étonnant que ça n'ait eu aucun effet.
Guillaume.
Hors ligne
Un moyen d'accélérer le traitement d'import est de saucissonner vos fichiers pour que vous n'ayez pas d'opération d'écriture physique avant la fin de le mise en cache de l'intégralité des données du fichier.
Essayez avec des fichiers de moins de shared_buffer / 3
Le second moyen est de placer le journal qui est écrit de manière synchrone sur un RAID multiplexé (10 ou 0+1) en jouant sur le nombre de disque (par exemple 8 disque en //). Ceci devrait nettement améliorer le débit transactionnel.
Assurez vous cependant que votre carte RAID supporte la parallélisation des accès et le load balancing...
Par exemple les cartes bas de gamme livré par DEL (PERC H700 et PERC 6/I) ne savent ni faire du parallélisme ni du load balancing...
En particulier, la gamme de serveur Dell PowerEdge R210 n'est absolument pas adaptée aux serveurs de type SGBDR si l'on veut obtenir des performances. Le controleur interne ne sait faire que du RAID 5 / 6 et toutes combinaisons (50/60), ce qui pénalise les opérations de journalisation, d’où une contention importante.
A +
Frédéric Brouard, alias SQLpro, ARCHITECTE DE DONNÉES, Expert langage SQL
Le site sur les SGBD relationnel et langage SQL : http://sqlpro.developpez.com/
Modélisation de données, conseil, expertise, audit, optimisation, tuning, formation
* * * * * Enseignant CNAM PACA, ISEN Toulon, CESI Aix en Provence * * * * *
Hors ligne
Je ne comprends pas d'où vient cette formule : shared_buffer / 3. Surtout dans le contexte de la mise en cache des données du fichier.
Guillaume.
Hors ligne
