Vous n'êtes pas identifié(e).
Pages : 1
Bonjour à toutes et à tous,
Je rencontre un problème sur ma base en streaming réplication, version ( PostgreSQL 9.1.6 on x86_64-unknown-linux-gnu, compiled by gcc (GCC) 4.4.6 20120305 (Red Hat 4.4.6-4), 64-bit).
Dans le log pendant le traitement de la nuit des message répétitifs "WARNING : pgstat wait timeout".
J'ai fait la tour dans google, Hélas je n'ai pas trouvé une réponse qui correspond à mon problème.
Est ce que quelqu'un pourra m'aiguiller SVP?
Merci d'avance
Hors ligne
Bonjour,
en général le message apparaît quand il y a trop d'I/O sur le système, et cela pénalise le stats collector. Sauf si ces messages continuent à être loggés continuellement, ce n'est pas un problème.
Julien.
https://rjuju.github.io/
Hors ligne
Merci "rjuju",
C'est quand même grave car ça m'a coûté une bascule sur l'esclave par pacemaker à un moment donné.
Est ce que le fait que les traitement font un "CREATE UNLOGGED TABLE table_temp AS select from table...." engendre de l'ecriture de plus si j'augmente mon "checkpoint_segments" pourra aider à ne pas générer des I/O d'avantage? Sinon que pourrais je faire?
Merci d'avance
Hors ligne
Quelles sont les conditions de bascule sur votre cluster ? Il est plus probable que ce soit une surcharge qui ai causé la bascule et l'affichage de ce message.
En ce qui concerne les unlogged tables, elles ne sont pas journalisées et ne génèrent donc pas de wal.
Julien.
https://rjuju.github.io/
Hors ligne
Merci encore,
Je suis entièrement d'accord avec toi julien. J'ai commencer par augmenter le checkpoint_segments à 40 pour un FS pg_xlog de 6Go. Je ne sais pas exactement ce que je peut faire aussi. Je fait un "disable autovacuum" avant traitement pour baisser la charge d'ecriture...?? y a t il d'autre pistes STP.
Voici la config de corosync mais pour l'instant ce n'ai pas la préoccupation majeure, le plus urgent c'est ce pbm de gestion I/O.
#crm configure show
node MAITRE
node ESCLAVE
primitive pgsql-ip ocf:heartbeat:IPaddr2 \
params ip="x.x.x.x" cidr_netmask="24" \
op monitor interval="20s" \
meta is-managed="true"
primitive pgsqld ocf:pgsql:PostgreSQL \
op start interval="0" timeout="120s" \
op stop interval="0" timeout="120s" \
op monitor interval="20s" \
meta is-managed="true"
colocation pgsqld_with_pgsql-ip inf: pgsql-ip pgsqld
property $id="cib-bootstrap-options" \
dc-version="1.1.6-3.el6-a02c0f19a00c1eb2527ad38f146ebc0834814558" \
cluster-infrastructure="openais" \
expected-quorum-votes="2" \
stonith-enabled="false" \
no-quorum-policy="ignore" \
last-lrm-refresh="1364405383"
rsc_defaults $id="rsc-options" \
resource-stickiness="INFINITY" \
migration-threshold="3"
Bien à toi
Hors ligne
Cela dépend de beaucoup de choses. Idéalement le checkpoint doit se déclencher par le timeout et non le checkpoint_segments, il fuat donc ajuster celui-ci pour qu'il soit légèrement supérieur aux nombres de wal générés durant le timeout, bien évidemment si vos shared_buffers est capable d'absorber cette charge. La vue pg_stat_bgwriter vous donnera des informations sur les checkpoint et le bgrwriter par exemple. Il faut également prendre en compte la configuration disque, le niveau de raid, la répartition des données, les traitements effectués etc. Bref il n'y a pas de solution universelle.
Julien.
https://rjuju.github.io/
Hors ligne
Avec un shared_buffer de ~3GB, un checkpoint_segment à 40 et un wal_buffers à 32MB que peut on me conseiller pour le "archive_timeout" et le "checkpoint_timeout"?
Merci d'avance
Hors ligne
Cela dépend de l'activité en écriture sur le maître. Il faut que les checkpoints soient assez fréquent pour que le shared_buffers ne soit pas saturé en permanence. S'il n'y a pas trop d'activité en écriture, un checkpoint_delai de 5 minutes devrait convenir. Il faut donc que le checkpoint_segment soit supérieur au nombre moyen de wal généré en 5 minutes.
Pour avoir une idée de l'activité, tu peux monitorer le nombre de wal généré par minute ou heure, et regarder les infos dans la vue pg_stat_bgwriter pour voir s'il y a une contention sur le shared_buffers.
Julien.
https://rjuju.github.io/
Hors ligne
Merci beaucoup julien.
Hors ligne
Pages : 1
