Vous n'êtes pas identifié(e).

#1 Re : Général » [inconnu]@[inconnu] LOG: paquet de démarrage incomplet » 14/09/2020 11:28:40

Je me demande si par "démarrage", le LOG ne parlerait pas du "démarrage de la connexion", pas du "démarrage du serveur".

Du coup, je n'ai pas bien compris votre dernier message. Problème résolu ou pas ?

#2 Re : Général » [inconnu]@[inconnu] LOG: paquet de démarrage incomplet » 14/09/2020 10:13:20

Bonjour,

Je ne m'y connais pas mais cela ressemble à ce cas là : https://forums.postgresql.fr/viewtopic.php?id=5500
Un "test de vie" (sorte de ping) qui ne ferme pas (ou mal) sa connexion.

Est-ce que cette ligne se répète dans le temps dans les logs ensuite ?

#3 Re : Général » Lossy bitmaps et work_mem » 09/03/2020 17:15:56

Ok, merci pour tout !
Ma lanterne vient de s'éclairer !

#4 Re : Général » Lossy bitmaps et work_mem » 09/03/2020 16:35:59

Hum ok smile
Du coup, afin de pouvoir poursuivre sur mon cas perso, qu'est-ce que "PagetableEntry" ?
Si c'est une valeur fixe à 48 qu'il ne faut pas chercher à comprendre ok (mais sinon ...)

#5 Re : Général » Lossy bitmaps et work_mem » 09/03/2020 15:54:42

Merci pour ce rapide retour.


Oui pardon je voulais dire 84-16 évidemment.


Effectivement, je partais mal avec mon sizeof(HASHELEMENT) (je pensais que c'était la place du type de la colonne de la table, la colonne sur laquelle se faisait le Hash ...)
Et pour le sizeof(Pointer), je n'avais dû tomber que sur des exemples 32-bit ...


Bref, je repars avec :
MAXALIGN(sizeof(HASHELEMENT)) = 16
sizeof(Pointer) = 8


Et j'arrive à :
3.2 MB = 39709 * ( MAXALIGN(sizeof(HASHELEMENT)) + MAXALIGN(sizeof(PagetableEntry)) + sizeof(Pointer) + sizeof(Pointer))
3.2 MB = 39709 * ( 16 + MAXALIGN(sizeof(PagetableEntry)) + 8 + 8)
Donc MAXALIGN(sizeof(PagetableEntry)) = 52,5008 ? disons 52 (et cela se tient : 39709*(32+52) = 39709*84 = 3335556 == 3,181034088 MB)
mais 52 ce n'est pas un multiple de 8 ... (et 48 et 56 sont trop loin)
le MAXALIGN serait bien un multiple de 8 sur un 64-bit ?


J'ai lu/relu aussi cette page : https://stackoverflow.com/questions/135 … -row-sizes
et j'ai envie de croire que je peux calculer la taille ainsi :
   23   -- heaptupleheader
+  1   -- padding or NULL bitmap
+  4   -- 1 * integer (no alignment padding here)
+  4   -- padding (pour arriver à un multiple de 8)
= 32
+  0   -- no padding since tuple ends at multiple of MAXALIGN


mais je dois m'égarer car je ne suis pas à 52.
La seule chose que je remarque c'est que 52 ressemble à l'exemple : 48 (un multiple de 8) + un item pointer à 4 bytes (mais on a dit que sizeof(Pointer) == 8 )


Bref, je cale encore.

#6 Général » Lossy bitmaps et work_mem » 09/03/2020 13:36:46

LudovicG
Réponses : 6

Bonjour,


Je me tire un peu les cheveux après avoir lu :
https://paquier.xyz/postgresql-2/postgr … heap-scan/
https://www.postgresql.org/message-id/0 … .ntt.co.jp


En substance, il serait question d'avoir un indice du work_mem qu'il faudrait par rapport à une requête présentant des "lossy bitmaps".


La formule donnée est :
work_mem (bytes) = (Number of lossy pages + number of exact pages) *
  (MAXALIGN(sizeof(HASHELEMENT)) + MAXALIGN(sizeof(PagetableEntry))
  + sizeof(Pointer) + sizeof(Pointer))


J'ai une requête présentant des lossy bitmaps mais je n'arrive déjà pas à retrouver la valeur de 3.2 MB donnée dans l'exemple !


En supposant que :
Number of lossy pages + number of exact pages = 39709 (Heap Blocks: exact=338 lossy=39371)
MAXALIGN(sizeof(HASHELEMENT)) = 8 car MAXALIGN sur un 64-bit est à 8, et que le HASHELEMENT ici est un int4 à 4
sizeof(Pointer) = 4


j'en arrive à :
3.2 MB = 39709 * ( 16 + MAXALIGN(sizeof(PagetableEntry)) )
mais dire que MAXALIGN(sizeof(PagetableEntry)) = 84 ... je n'arrive pas à l'expliquer (je commençais à calculer le Page Header de 23+1 bytes ... )


Merci d'éclairer ma lanterne.

#7 Re : Général » REX Questions temBoard et pgBadger sur GoogleCloud et AWS RDS » 04/07/2019 14:43:43

Ok merci.
Du coup, je me rends compte que j'ai peut-être mal posé mon besoin, pas assez élargi.


AWS RDS et GCP sont des choix clients.
L'idée est de voir jusqu'où et comment, on peut surveiller/monitorer/superviser ce genre d'instance (pour l'instant, j'étais parti sur pgbadger et temboard).
Quels autres outils de la communauté seraient pertinents sur ce genre de plateforme ?


Les outils fournis par ces plate-formes suffisent-ils ?
Ou à un moment, il faut bel et bien migrer vers une "vraie" instance Postgres que l'on maîtrise de A à Z ?


Et enfin, comment se présente le marché ?
Les clients se tournent de plus en plus vers ces plate-formes (ou pas) ?
Ils en reviennent ?

#8 Re : Général » REX Questions temBoard et pgBadger sur GoogleCloud et AWS RDS » 03/07/2019 10:47:58

Bonjour,

Merci pour ce retour qui me confirme où j'en été arrivé.


Pour pgBadger, avez-vous un retour d'expérience ?
J'en été arrivé à KO sur GCP
et "possible mais manuel" via RDS (surtout car téléchargement manuel depuis l'interface web)


Et pour partager mes découvertes, ils parlent bien de pgbadger et donnent quand même le contournement pour le line_prefix :
https://docs.aws.amazon.com/fr_fr/Amazo … sks.Badger

#9 Général » REX Questions temBoard et pgBadger sur GoogleCloud et AWS RDS » 25/06/2019 11:58:32

LudovicG
Réponses : 5

Bonjour,


J'espère écrire au bon endroit (premier post).
Mon besoin : voir comment utiliser temBoard et pgBadger sur une base Postgres GoogleCloud et AWS RDS.


D'après mes recherches, pour temBoard ce n'est pas possible (sur les 2).
Je ne vois pas comment avoir la main pour installer correctement l'agent temBoard.
Quelqu'un a-t-il un REX différent là-dessus ?


Pour pgBadger :
- GoogleCloud
-- les paramètres à modifier pour pgBadger sont en grande partie modifiables (mais pas le log_line_prefix)
-- pour accéder/récupérer les fichiers logs, là par contre je sèche : j'obtiens en web un "sur-log" Google qui encapsule le log Postgres, donc inexploitable par pgBadger apparemment (et les sorties fichier possibles sont JSON et CSV).
-- donc KO pour moi. Quelqu'un a-t-il mieux que moi ? smile


- AWS RDS
-- les paramètres à modifier pour pgBadger sont en grande partie modifiables (log_line_prefix fixe et choix parmi 2 log_filename, à l'heure ou à la journée)
-- pas de contrôle sur le log_truncate_on_rotation mais on peut jouer avec les log_rotation_*
-- on peut consulter les logs (postgres cette fois-ci) en mode web mais peu pratique ...
-- pour récupérer les fichiers, je n'ai pas trouvé de shell (bien qu'on me donne le chemin : /rdsdbdata/log/error )
-- du coup, j'ai réussi à sortir un premier rapport pgBadger en téléchargeant manuellement 1 (à la fois) fichier de log sad
-- là encore, ya plus simple/pratique/pro ?


Merci par avance pour vos retours.

Pied de page des forums

Propulsé par FluxBB