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

Pages : 1 2 3 4 5 6

#26 Réplication » Nombreux locks sur base de standby » 11/06/2019 15:03:06

pitpoule
Réponses : 5

Bonjour,

Depuis quelques jours, nous rencontrons un problème de quasi  blocage de notre base standby en lecture: pendant de longues minutes, pratiquement aucune requête ne passe, je les vois toutes en "SubtransControlLock". Puis, d'un coup, les locks se libèrent et la base redevient de nouveau utilisable.
Les rapides recherchent que j'ai effectuées me laissent perplexe.... on parle de recompiler le code du moteur....

Si vous avez une idée ou un retour sur ce type de problème, je suis preneur !

PG:9.6

Merci

#27 Re : Général » Migration d'un table volumineuse vers une table partitionnée » 29/05/2019 15:40:52

pitpoule

ok,je vais pourvoir étudier cela sur un environnement de test.

Merci

#28 Général » Migration d'un table volumineuse vers une table partitionnée » 29/05/2019 12:33:11

pitpoule
Réponses : 2

Bonjour,

Nous avons une table assez volumineuse (~200G) qui contient des données temporelles. Afin de faciliter sa maintenance, je souhaiterais la partitionner.
Comme les insert sont très fréquents, il serait complexe de créer une table à coté et de transférer les données.
Est ce qu'il est envisageable de modifier la table "in situ" ? En gros, je crée des tables filles et je gère les triggers au niveau de la table actuelle, pour que les nouveaux insert se fassent dans les bonnes tables filles. La table mère se viderait au fur et à mesure.... des purges ou de création de nouvelles tables filles.

Je suis en PG 9.6

Merci

#29 Re : Général » Lag de réplication et requête longue sur standby » 13/05/2019 14:27:37

pitpoule

Il me reste quand même des questions au sujet de la réplication.

De ce que je comprends donc, quand un select est lancé côté standby, PG ne réapplique plus les wal si une modification (update/delete/insert) altère la vue du début du sélect (pour gérer la cohérence). Il attend  max_standby_streaming_delay ou alors, c'est géré par hot_standby_feedback.

C'est bien cela ?

#30 Re : Général » Lag de réplication et requête longue sur standby » 10/05/2019 16:23:57

pitpoule
Marc Cousin a écrit :

pg_is_in_recovery va être à true, normal. Par contre, pg_is_wal_replay_paused, c'est savoir si y aurait pas un petit malin qui met la réplication en pause... je le sais, parce que je l'ai déjà fait (pour passer des pg_dump parallélisé sur un standby par exemple smile )

Sinon, le replay est toujours plus lent que la génération: sur le serveur primaire, il y a plusieurs processus qui insèrent en même temps dans le WAL. Sur le standby, il y a un seul processus qui rejoue le tout. On peut aussi avoir les disques qui ont du mal à suivre ou d'autres choses. Donc vérifiez que la réplication n'est pas effectivement en pause ou bloquée par quelque chose, et si elle avance, il faut trouver la source de contention... cpu ou disque probablement


Je vais chercher... merci pour le retour smile

#31 Re : Général » Lag de réplication et requête longue sur standby » 10/05/2019 16:14:04

pitpoule
Marc Cousin a écrit :

Tant que j'y pense, vérifiez aussi pg_is_wal_replay_paused() sur le standby quand ça se produit… sait on jamais, un développeur retors smile

J'ai eu le doute aussi...et j'ai lancé smile

postgres=# select pg_is_in_recovery();
pg_is_in_recovery
-------------------
t
(1 row)

#32 Re : Général » Lag de réplication et requête longue sur standby » 10/05/2019 16:12:39

pitpoule
Marc Cousin a écrit :

Etes vous sûr que la réplication est en pause, pas juste très ralentie? Sans connaître votre serveur, il se peut que la sur-consommation de ressources par la requête en écriture ralentisse simplement l'application des journaux... Vous pouvez déjà surveiller pg_last_wal_replay_lsn() sur le standby pour vérifier que c'est en pause et pas très ralenti...

C'est possible qu'elle soit ralentie, nous avons une forte charge en écriture sur le serveur primaire, la quantité de wal absorbée n'arrivait surement pas à compenser ce qui arrivaient. Et du coup, le lag montait constamment.

#33 Re : Général » Lag de réplication et requête longue sur standby » 10/05/2019 15:45:17

pitpoule

postgres=# show hot_standby_feedback ;
hot_standby_feedback
----------------------
off
(1 row)

postgres=# show max_standby_streaming_delay ;
max_standby_streaming_delay
-----------------------------
30s
(1 row)


Vu le paramétrage, je ne comprends pas comment je peux avoir du lag

#34 Général » Lag de réplication et requête longue sur standby » 10/05/2019 14:51:48

pitpoule
Réponses : 10

Bonjour,

Nous rencontrons régulièrement des pics de lag entre notre serveur primaire et notre standby (hot standby en pg 9.6). J'ai l’impression que ce lag est créé par des requêtes "SELECT" très longues qui tournent sur la standby (plusieurs dizaines de minutes). Pendant tout le temps où ces requêtes s'exécutent,les wal ne semblent pas appliqués par la standby.


Extrait du pg_stat_replication sur le primaire. Tout est ok mais le "replay" ne consomment pas les wals.

  usename   | application_name | client_addr | delta_sent_mb | delta_write_mb | delta_flush_mb | delta_replay_mb
-------------+------------------+-------------+---------------+----------------+----------------+-----------------
  replication | walreceiver      | ************  |          0.00 |           0.00 |           0.00 |        91167.93


Est ce que c'est "normal" ?

Merci

#35 Re : Général » Impact du nombre de tables sur les performances globales » 26/04/2019 09:57:58

pitpoule

Le blocage de nouvelles connexions, c'est quand même assez pénalisant....

Est ce que si je laisse en l'état, je fonce droit vers des ennuis ? Je ne vous cache pas que faire une action comme cela sur des tables systèmes ne m'enchante guère....c'est pas que je n'ai pas confiance en PG, mais s'il y a un problème, c'est toute la base qui risque de se trouver par terre...

Du coup, une nouvelle question m'est venue: est ce qu'il est possible de backuper et surtout restaurer la table pg_class ?

#36 Re : Général » Impact du nombre de tables sur les performances globales » 24/04/2019 12:02:25

pitpoule

Quel est l'impact d'un vacuum full sur une table système ? Est ce que ça va bloquer toute l'activité de la base ?

#37 Re : Général » Impact du nombre de tables sur les performances globales » 24/04/2019 08:51:32

pitpoule
gleu a écrit :

Vous utilisez beaucoup de tables temporaires ?

Oui... à haute dose.

#38 Re : Général » Impact du nombre de tables sur les performances globales » 23/04/2019 12:08:02

pitpoule

En effet, ça devrait être envisageable....

toto=# SELECT * FROM pgstattuple('pg_catalog.pg_class');
table_len | tuple_count | tuple_len | tuple_percent | dead_tuple_count | dead_tuple_len | dead_tuple_percent | free_space | free_percent
-----------+-------------+-----------+---------------+------------------+----------------+--------------------+------------+--------------
799973376 |       91327 |  16253259 |          2.03 |           197115 |       33824913 |               4.23 |  724299904 |        90.54

#39 Re : Général » Impact du nombre de tables sur les performances globales » 23/04/2019 12:05:32

pitpoule

Aujourd'hui, la table pg_class fait presque 800M.

Faut'il envisager des reindexations/vacuum fulls des tables systèmes ?

#40 Re : Général » Impact du nombre de tables sur les performances globales » 23/04/2019 09:33:15

pitpoule

Oui, c'est à peu près cela, on est dans un contexte multi tenant, on a des centaines de clients, des tables de travails,..... et on ne supprime jamais les données des clients mêmes s'ils ne sont plus chez nous. La modélisation est correcte de mon point de vue mais la question du sharding se pose sérieusement en interne si vous voulez tout savoir smile

#41 Re : Général » Impact du nombre de tables sur les performances globales » 18/04/2019 11:48:01

pitpoule
rjuju a écrit :

Bonjour,



Cela peut impacter les performances effectivement.  Le premier problème qui risque d'arriver est une consommation de mémoire excessive si vous utilisez un pooler de connexion (ou des connexion persistentes), du fait que chaque connexion finira par avoir un cache de toutes les tables de la base;

C'est intéressant... parce qu'effectivement, on utilise un pooler de connexion (pgbouncer)

#42 Général » Impact du nombre de tables sur les performances globales » 18/04/2019 09:24:41

pitpoule
Réponses : 15

Bonjour,

Est ce que le nombre de tables présentes dans une base peut affecter les performances globales ? Quand je parle d'un grand nombre, c'est plusieurs dizaines de milliers.

Merci

#43 Re : Général » Lock et héritage de table » 17/04/2019 09:15:46

pitpoule

ok merci, je vais effectivement utiliser lock_timeout et croiser les doigts !

#44 Général » Lock et héritage de table » 16/04/2019 16:28:15

pitpoule
Réponses : 2

Bonjour,


Je dois rajouter une colonne sur un table mère (en PG 9.6) possédant un grand nombre de tables filles, qui sont de plus assez sollicitées. La colonne à ajouter est basique, pas de valeur par défaut ni de not null.

Pour ajouter une colonne il faut avoir un lock exclusif sur la table mère et ses filles mais je ne sais pas bien comment cela va se passer...
Est ce que PG va attendre que toutes les tables filles soient "verrouillables" en même temps pour faire la mise à jour ou bien va t'il les verrouiller au fur et à mesure que cela est possible ?

Mon inquiétude est qu'avec les sollicitations que nous avons sur les tables filles, la colonne ne puisse jamais être ajouter, faute de pouvoir avoir un lock exclusif sur toutes les tables en même temps


Merci

#45 Re : Optimisation » Impact du paramètre wal_compression sur les performances » 26/03/2019 18:18:48

pitpoule

Merci, je vais aussi étudier ces pistes

#46 Re : Optimisation » Impact du paramètre wal_compression sur les performances » 25/03/2019 16:15:28

pitpoule
ruizsebastien a écrit :

Bonjour,

Et si au lieu de compresser les fichiers wal, vous augmentiez leur taille pour avoir moins souvent d'écriture sur disque ?
(voir --wal-segsize lors de l'initdb)

Je veux justement diminuer leur taille smile pour accélérer la copie vers le serveur d'archivage

#47 Re : Optimisation » Impact du paramètre wal_compression sur les performances » 25/03/2019 12:51:29

pitpoule

Pour la CPU, on est régulièrement entre 70% et 90% , les fichiers wal c'est plus de 60000 par jour...

Mais sur le fond, vous avez raison, on va organiser un test, mieux vaut les actes qu'un discours !

#48 Optimisation » Impact du paramètre wal_compression sur les performances » 25/03/2019 12:28:07

pitpoule
Réponses : 7

Bonjour,

Afin d'améliorer les performances de l'archivage, je souhaiterais mettre en place la compression des wal. Cependant notre base de données est déjà fortement sollicitée et nous avons assez peu de marge niveau CPU. Quel est l'impact sur les performances ? les checkpoints ?

Merci

#49 Re : Général » XID wraparound » 07/02/2019 18:37:32

pitpoule

C'est une bonne nouvelle ;p

Du coup, de ce que je comprends, c'est que finalement le txid "0" n'est pas plus particulier que le txid 200 ou 10 millions... ce qui compte c'est que le moteur connaissent quels sont les txid du passé et ceux du futur.... et freezer les plus vieux. Comme vous l'avez précédemment écrit, c'est lié à la cyclicité

#50 Re : Général » XID wraparound » 07/02/2019 17:57:32

pitpoule

lengow=> select datname, datfrozenxid from pg_database ;
  datname   | datfrozenxid
------------+--------------
postgres  |   4039956812
******         |   3924274179
template1 |   3998600242
template0 |   3998600242
**********   |   4010500360
******        |   4010500360
*****         |   4010500360
(7 rows)



lengow=> select txid_current();       
txid_current
--------------
   4123673365
(1 row)

Pages : 1 2 3 4 5 6

Pied de page des forums

Propulsé par FluxBB