Re: temps de rodage postgresql

Bonjour ,

Sur une BD postgresql avec environ 8 millions d'enregistrements

8M d'entrées dans la table T1
8M d'entrées dans la table T2
8M d'entrées dans la table T3
8M d'entrées dans la table T4

J'observe une lenteur pour effectuer les requêtes en BD au démarrage
de l'application qui est lancée juste après le démarrage de PostgreSQL.
il est difficile de tenir 100 clients qui effectuent chacun une
dizaine de requêtes sur ces tables toutes les 20 secondes.
Suite à un certain temps, le lendemain, la BD est beaucoup plus
rapide. On peut tenir 640 clients sans aucune difficulté.

Qu'est-ce qui pourrait expliquer cette différence, ce temps de rodage ?
Y'a-t-il un paramètre qui permette d'avoir de bonnes performances dés
le lancement de la base de donnée sans avoir à attendre 24h ?

serveur avec 16 Go de RAM
shared_buffers = 1 x RAM / 3 soit environ 5 Go
effective_cache_size = 1 x RAM / 2 soit environ 8 Go
work_mem = 8

Merci par avance pour une piste

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Bonjour,

on parle plutôt de "montée en cache" plus que de "rodage", c'est le cas
pour tous les types de sgbdr.
Après un AR de PG, il faut "remplir" son cache, tu as aussi le cache FS qui
va jouer si tu as fait un AR de ta machine ...
Tu peux créer un "chauffeur de cache" en exécutant des requêtes
applicatives après un AR pour "forcer" le remplissage des caches (c'est
monnaie courante).

Cdt

Le 24 août 2017 à 10:33, CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
écrit :

>
> Bonjour ,
>
> Sur une BD postgresql avec environ 8 millions d'enregistrements
>
> 8M d'entrées dans la table T1
> 8M d'entrées dans la table T2
> 8M d'entrées dans la table T3
> 8M d'entrées dans la table T4
>
>
> J'observe une lenteur pour effectuer les requêtes en BD au démarrage de
> l'application qui est lancée juste après le démarrage de PostgreSQL.
> il est difficile de tenir 100 clients qui effectuent chacun une dizaine de
> requêtes sur ces tables toutes les 20 secondes.
> Suite à un certain temps, le lendemain, la BD est beaucoup plus rapide. On
> peut tenir 640 clients sans aucune difficulté.
>
> Qu'est-ce qui pourrait expliquer cette différence, ce temps de rodage ?
> Y'a-t-il un paramètre qui permette d'avoir de bonnes performances dés le
> lancement de la base de donnée sans avoir à attendre 24h ?
>
> serveur avec 16 Go de RAM
> shared_buffers = 1 x RAM / 3 soit environ 5 Go
> effective_cache_size = 1 x RAM / 2 soit environ 8 Go
> work_mem = 8
>
> Merci par avance pour une piste
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>

ok merci
mais plus précisément quel paramètre pour faire ça ?
merci
Michel Payan <michel(dot)payan(at)gmail(dot)com> a écrit :

> Bonjour,
>
> on parle plutôt de "montée en cache" plus que de "rodage", c'est le cas
> pour tous les types de sgbdr.
> Après un AR de PG, il faut "remplir" son cache, tu as aussi le cache FS qui
> va jouer si tu as fait un AR de ta machine ...
> Tu peux créer un "chauffeur de cache" en exécutant des requêtes
> applicatives après un AR pour "forcer" le remplissage des caches (c'est
> monnaie courante).
>
> Cdt
>
> Le 24 août 2017 à 10:33, CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> a
> écrit :
>
>>
>> Bonjour ,
>>
>> Sur une BD postgresql avec environ 8 millions d'enregistrements
>>
>> 8M d'entrées dans la table T1
>> 8M d'entrées dans la table T2
>> 8M d'entrées dans la table T3
>> 8M d'entrées dans la table T4
>>
>>
>> J'observe une lenteur pour effectuer les requêtes en BD au démarrage de
>> l'application qui est lancée juste après le démarrage de PostgreSQL.
>> il est difficile de tenir 100 clients qui effectuent chacun une dizaine de
>> requêtes sur ces tables toutes les 20 secondes.
>> Suite à un certain temps, le lendemain, la BD est beaucoup plus rapide. On
>> peut tenir 640 clients sans aucune difficulté.
>>
>> Qu'est-ce qui pourrait expliquer cette différence, ce temps de rodage ?
>> Y'a-t-il un paramètre qui permette d'avoir de bonnes performances dés le
>> lancement de la base de donnée sans avoir à attendre 24h ?
>>
>> serveur avec 16 Go de RAM
>> shared_buffers = 1 x RAM / 3 soit environ 5 Go
>> effective_cache_size = 1 x RAM / 2 soit environ 8 Go
>> work_mem = 8
>>
>> Merci par avance pour une piste
>>
>>
>> --
>> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>>

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Le 24/08/2017 à 10:55, Michel Payan a écrit :
> Bonjour,
>
> on parle plutôt de "montée en cache" plus que de "rodage", c'est le cas pour
> tous les types de sgbdr.
> Après un AR de PG, il faut "remplir" son cache, tu as aussi le cache FS qui va
> jouer si tu as fait un AR de ta machine ...
> Tu peux créer un "chauffeur de cache" en exécutant des requêtes applicatives
> après un AR pour "forcer" le remplissage des caches (c'est monnaie courante).
>
> Le 24 août 2017 à 10:33, CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr
> <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>> a écrit :
>
>
> Bonjour ,
>
> Sur une BD postgresql avec environ 8 millions d'enregistrements
>
> 8M d'entrées dans la table T1
> 8M d'entrées dans la table T2
> 8M d'entrées dans la table T3
> 8M d'entrées dans la table T4
>
>
> J'observe une lenteur pour effectuer les requêtes en BD au démarrage de
> l'application qui est lancée juste après le démarrage de PostgreSQL.
> il est difficile de tenir 100 clients qui effectuent chacun une dizaine de
> requêtes sur ces tables toutes les 20 secondes.
> Suite à un certain temps, le lendemain, la BD est beaucoup plus rapide. On
> peut tenir 640 clients sans aucune difficulté.
>
> Qu'est-ce qui pourrait expliquer cette différence, ce temps de rodage ?
> Y'a-t-il un paramètre qui permette d'avoir de bonnes performances dés le
> lancement de la base de donnée sans avoir à attendre 24h ?
>
> serveur avec 16 Go de RAM
> shared_buffers = 1 x RAM / 3 soit environ 5 Go
> effective_cache_size = 1 x RAM / 2 soit environ 8 Go
> work_mem = 8
>
> Merci par avance pour une piste

Bonjour,

Une autre piste envisageable est l'utilisation de l'extension "pg_prewarm" :
/docs/current/static/pgprewarm.html

Elle permet de forcer le chargement d'une table dans le cache.

Librement,
--
Dr. Stéphane Schildknecht

Contact régional PostgreSQL pour l'Europe francophone
Gérant de Loxodata, société de conseil, support et formation

01.79.72.57.75

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

Il n'existe pas de "paramètre magique" !
Comme le propose Stéphane, tu peux utiliser pg_prewarm pour monter une
table en cache.
Le plus couramment utilisé est de simuler une activité utilisateur par un
programme (que vous aurez écrit) et qui va jouer les requêtes (en avance de
phase) que vont passer les utilisateurs. Mais il va falloir coder ...

Le 24 août 2017 à 11:03, Stéphane Schildknecht <
stephane(dot)schildknecht(at)postgres(dot)fr> a écrit :

> Le 24/08/2017 à 10:55, Michel Payan a écrit :
> > Bonjour,
> >
> > on parle plutôt de "montée en cache" plus que de "rodage", c'est le cas
> pour
> > tous les types de sgbdr.
> > Après un AR de PG, il faut "remplir" son cache, tu as aussi le cache FS
> qui va
> > jouer si tu as fait un AR de ta machine ...
> > Tu peux créer un "chauffeur de cache" en exécutant des requêtes
> applicatives
> > après un AR pour "forcer" le remplissage des caches (c'est monnaie
> courante).
> >
> > Le 24 août 2017 à 10:33, CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr
> > <mailto:pierre(dot)crumeyrolle(at)c-s(dot)fr>> a écrit :
> >
> >
> > Bonjour ,
> >
> > Sur une BD postgresql avec environ 8 millions d'enregistrements
> >
> > 8M d'entrées dans la table T1
> > 8M d'entrées dans la table T2
> > 8M d'entrées dans la table T3
> > 8M d'entrées dans la table T4
> >
> >
> > J'observe une lenteur pour effectuer les requêtes en BD au démarrage
> de
> > l'application qui est lancée juste après le démarrage de PostgreSQL.
> > il est difficile de tenir 100 clients qui effectuent chacun une
> dizaine de
> > requêtes sur ces tables toutes les 20 secondes.
> > Suite à un certain temps, le lendemain, la BD est beaucoup plus
> rapide. On
> > peut tenir 640 clients sans aucune difficulté.
> >
> > Qu'est-ce qui pourrait expliquer cette différence, ce temps de
> rodage ?
> > Y'a-t-il un paramètre qui permette d'avoir de bonnes performances
> dés le
> > lancement de la base de donnée sans avoir à attendre 24h ?
> >
> > serveur avec 16 Go de RAM
> > shared_buffers = 1 x RAM / 3 soit environ 5 Go
> > effective_cache_size = 1 x RAM / 2 soit environ 8 Go
> > work_mem = 8
> >
> > Merci par avance pour une piste
>
> Bonjour,
>
> Une autre piste envisageable est l'utilisation de l'extension "pg_prewarm"
> :
> /docs/current/static/pgprewarm.html
>
> Elle permet de forcer le chargement d'une table dans le cache.
>
> Librement,
> --
> Dr. Stéphane Schildknecht
>
> Contact régional PostgreSQL pour l'Europe francophone
> Gérant de Loxodata, société de conseil, support et formation
>
> 01.79.72.57.75
>
>
> --
> Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)
>

CRUMEYROLLE Pierre <pierre(dot)crumeyrolle(at)c-s(dot)fr> writes:
> Qu'est-ce qui pourrait expliquer cette différence, ce temps de rodage ?

C'est l'efficacité des cache système et PostgreSQL qui font la
différence. Lors de la première requête il est nécessaire d'aller
chercher les données sur disque. Ensuite, les données sont déjà en
mémoire (cache) et leur accès est nettement plus rapide.

> Y'a-t-il un paramètre qui permette d'avoir de bonnes performances dés le
> lancement de la base de donnée sans avoir à attendre 24h ?

Non.

Il est possible d'utiliser l'extension pgfincore afin de faire des
copies de l'état des cache système et PostgreSQL, puis de restaurer
l'état tel que lors d'une copie précédente :

https://github.com/klando/pgfincore

L'extension pg_prewarm mentionnée précedemment propose le même mode de
fonctionnement en se limitant au cache PostgreSQL.

--
dim

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)

2017-08-24 19:12 GMT+09:00 Dimitri Fontaine <dim(at)tapoueh(dot)org>:
> L'extension pg_prewarm mentionnée précedemment propose le même mode de
> fonctionnement en se limitant au cache PostgreSQL.

pg_prewarm a gagné récemment une option automatique quand Postgres redémarre:
https://git.postgresql.org/pg/commitdiff/79ccd7cbd5ca44bee0191d12e9e65abf702899e7
--
Michael

--
Envoi via la liste pgsql-fr-generale (pgsql-fr-generale(at)postgresql(dot)org)