Vous n'êtes pas identifié(e).
Pages : 1
Apres analyse de tous vos conseils et recommandations, il semble que mon pb soit que mon serveur est sous-dimensionné par rapport à la taille de ma base de données.
Je vous remercie encore de votre aide
.
Julien
Bonjour Guillaume,
.
Lorsque je lance la première fois une requête, elle va prendre qq secondes.
Durant ces secondes, l'observation des ressources consommées du serveur indique que la RAM (ni le SWAP) ne sont mis à contribution, par contre les IO sur le disque sont à 95%.
Par contre, à la seconde exécution, la même requête prend qq ms.
.
Merci encore de votre aide,
Julien
Sebastien,
Dans aucun fichier log je n'ai trouvé FATAL ... ou Failed system ...
Par ailleur ulimit pour postgres est unlimited
.
Merci à nouveau pour votre aide,
Julien
Je suis conscient de cela mais, à cette heure, notre serveur n'utilise pas de mémoire pour postgresql ce qui semble occasionner des temps de réponses assez mauvais avec 1 seul utilisateur !
.
Quand postgresql utilisera la mémoire voire le swap je pourrais changer la config.
A ce jour, il utilise uniquement 4% de la mémoire et je pense qu'il y a un pb que je n'arrive pas à identifier soit sur la conf postgresql (ce dont je doute) soit sur conf CentOS/Postgresql ...
Qu'en pensez vous ?
en vous remerciant de nouveau pour votre retour,
Julien
aujourd'hui 2 à terme une 50aine
dans le paramètre work_mem j'ai mis 4GB
En vous remerciant de votre retour,
Julien
Voici l'explain (analyse,buffers) d'une requete :
"Sort (cost=1525752.55..1525753.07 rows=205 width=20) (actual time=8746.767..8746.770 rows=50 loops=1)"
" Sort Key: cpij.jobfunction_id, t.trait_id"
" Sort Method: quicksort Memory: 28kB"
" Buffers: shared hit=215537"
" -> HashAggregate (cost=1525741.61..1525744.68 rows=205 width=20) (actual time=8746.725..8746.746 rows=50 loops=1)"
" Group Key: cpij.jobfunction_id, t.trait_id"
" Buffers: shared hit=215537"
" -> Hash Join (cost=747269.14..1440297.48 rows=11392550 width=20) (actual time=8737.549..8745.257 rows=8446 loops=1)"
" Hash Cond: (iis.item_id = t.item_id)"
" Buffers: shared hit=215537"
" -> Hash Join (cost=747246.64..1035839.45 rows=2278510 width=20) (actual time=8733.643..8739.192 rows=19649 loops=1)"
" Hash Cond: (cpij.individual_id = iis.individual_id)"
" Buffers: shared hit=215537"
" -> Bitmap Heap Scan on corpus_pattern_individual_jobfunction cpij (cost=3722.54..17859.94 rows=85675 width=16) (actual time=2.109..2.774 rows=4449 loops=1)"
" Recheck Cond: (corpus_pattern_id = 878067)"
" Filter: (jobfunction_id > 0)"
" Rows Removed by Filter: 977"
" Heap Blocks: exact=155"
" Buffers: shared hit=220"
" -> Bitmap Index Scan on pk_corpus_pattern_individual_jobfunction (cost=0.00..3701.12 rows=106760 width=0) (actual time=1.605..1.605 rows=11274 loops=1)"
" Index Cond: (corpus_pattern_id = 878067)"
" Buffers: shared hit=65"
" -> Hash (cost=450075.71..450075.71 rows=23475871 width=20) (actual time=8595.259..8595.259 rows=32131423 loops=1)"
" Buckets: 33554432 Batches: 1 Memory Usage: 2019332kB"
" Buffers: shared hit=215317"
" -> Seq Scan on index_item_score iis (cost=0.00..450075.71 rows=23475871 width=20) (actual time=0.006..3231.016 rows=32131423 loops=1)"
" Buffers: shared hit=215317"
" -> Hash (cost=10.00..10.00 rows=1000 width=16) (actual time=3.895..3.895 rows=5 loops=1)"
" Buckets: 1024 Batches: 1 Memory Usage: 9kB"
" -> Function Scan on dblink t (cost=0.00..10.00 rows=1000 width=16) (actual time=3.886..3.888 rows=5 loops=1)"
"Planning time: 0.674 ms"
"Execution time: 8772.140 ms"
Par exemple, lors de l'exécution d'une requête (pour la première fois), j'ai les infos suivantes :
.
en utilisant iotop sur centos :
I/O : 98%
.
en utiilisant htop sur centos :
MEM : 4%
CPU : 11%
SWAP : 0.1%
.
Est-ce normal que postgresql utilise le disque plutot que la mémoire ?
.
.
Merci de votre aide,
Julien
Voici l'explain analyse d'une requete qui prend qq ms après la 2e execution et qq dizaines de secondes lors de la premiere execution
"Limit (cost=651126.69..651126.94 rows=100 width=76) (actual time=214.215..214.227 rows=100 loops=1)"
" -> Sort (cost=651126.69..651308.67 rows=72792 width=76) (actual time=214.214..214.218 rows=100 loops=1)"
" Sort Key: (sum((((((((((((((((((100 * CASE WHEN (index_item.item18008 IS NULL) THEN 0 ELSE index_item.item18008 END) + (50 * CASE WHEN (index_item.item348472 IS NULL) THEN 0 ELSE index_item.item348472 END)) + (50 * CASE WHEN (index_item.item312890 (...)"
" Sort Method: top-N heapsort Memory: 29kB"
" -> HashAggregate (cost=647616.71..648344.63 rows=72792 width=76) (actual time=213.438..213.848 rows=2464 loops=1)"
" Group Key: index_item.individual_id"
" -> Nested Loop (cost=1597.14..641247.41 rows=72792 width=76) (actual time=191.974..208.089 rows=2464 loops=1)"
" -> Bitmap Heap Scan on corpus_individual (cost=1596.70..99230.31 rows=72792 width=8) (actual time=191.953..192.280 rows=2464 loops=1)"
" Recheck Cond: (corpus_id = 1146329)"
" Heap Blocks: exact=8373"
" -> Bitmap Index Scan on pk_corpus_individual (cost=0.00..1578.50 rows=72792 width=0) (actual time=161.861..161.861 rows=1534364 loops=1)"
" Index Cond: (corpus_id = 1146329)"
" -> Index Scan using index_item_pkey on index_item (cost=0.43..7.44 rows=1 width=76) (actual time=0.005..0.005 rows=1 loops=2464)"
" Index Cond: (individual_id = corpus_individual.individual_id)"
"Planning time: 0.535 ms"
"Execution time: 214.947 ms"
.
Est-ce qu'il existe au niveau CentOS un qcq paramètre qui empeche à postgresql d'utiliser la mémoire ?
.
Merci encore de votre aide,
Julien
Voici la liste des shared_buffers :
"idx_1";946935
"t1";100593
"t1_pkey";1
Julien
Bonjour Sébastien,
Le shared_buffer est bien utilisé mais il semble "monté" sur le disque et non en mémoire de CentOS
En effet, je surveille la mémoire utilisée par le système et elle ne bouge pas malgré l'utilisation du shared_buffer
par contre, il y a énormément I/O sur le disque
Tout se passe comme si postgresql utilisait de la mémoire sur disque et non la RAM
Merci encore de votre retour,
Julien
Bonjour
Les grosses tables ont les tailles suivantes :
- t1 28GB
- t2 71GB et son index principal 43GB
- t3 2,6GB
Malgré les tailles des tables, ce que je ne comprends pas c'est pourquoi, aucune de mes requêtes ne consomme de la mémoire ...
Merci encore de votre retour,
Bonne journée
Julien
Voici le résultat de la requete :
"shared_buffers";"1048576";"8kB"
"temp_buffers";"1048576";"8kB"
"wal_buffers";"2048";"8kB"
Merci par avance de votre retour
Julien
Bonjour,
J'ai installé postgresql9.5 sur un serveur CentOS avec 32Go de RAM
Au niveau de postgresql.conf j'ai modifié temp_buffers : 8Go, shared_buffer : 8Go ...
Mais qd je lance une requête sur de grosses tables (10-50 millions de lignes), la mémoire n'est quasiment pas utilisée et tout se passe sur les accès disques
Je ne trouve pas le bon paramètre pour forcer postgresql à travailler en mémoire autant que possible ...
Je vous remercie par avance de votre aide sur le sujet,
Bonne journée
Julien
Merci beaucoup rjuju,
Effectivement j'ai la version 9.5 et pg_prewarm semble être une bonne solution pour mon problème.
Bonjour à toutes et tous,
Je cherche à savoir s'il est possible de forcer un index en mémoire afin d'optimiser mes requêtes :
Sur des tables de plusieurs centaines de millions de lignes indexées, le premier select prend plusieurs secondes alors que les suivants uniquement qq ms.
C'est pourquoi je cherche à avoir des temps de réponse stable en montant l'index en mémoire ...
Merci par avance de votre aide et toute idée est la bienvenue !
Julien
Pages : 1
