PostgreSQL pg_stat_activity affiche COMMIT

Nous avons récemment remplacé notre serveur de base de données par une machine mise à niveau avec 4 processeurs quad core et 32 Go de RAM. Nous avons également réutilisé notre ancienne boîte pour servir d'esclave avec la réplication en streaming. Les deux boîtiers exécutent CentOS 6.3 et PostgreSQL 9.2. Postgres est la seule chose qui s'exécute sur chacune des boîtes.

Cette configuration est en place depuis environ un mois environ, lorsque nous avons soudainement commencé à rencontrer des problèmes lorsque le trafic a commencé à augmenter. Ce que nous avons commencé à voir est parfois une charge CPU extrêmement élevée (le haut montre une charge moyenne de 270), et quand nous pouvons regarder, pg_stat_activitynous verrons que la plupart de nos connexions sont en COMMITétat. Une fois laissé seul, cela finira par finir et le système deviendra réactif avec les connexions devenant IDLE. Nous avons essayé de désactiver la réplication pour voir si cela pouvait être le problème, mais le problème persiste.

Nous avons essayé de diagnostiquer ce qui se passe et nous sommes un peu perdus. La sortie de l'exécution perfmontre quelque chose de similaire à ci-dessous, et je n'ai aucune idée de ce que 0x347ba9représente.

+  41.40%       48154  postmaster  0x347ba9         f 0x347ba9                                   ◆
+   9.55%       10956  postmaster  0x2dc820         f set_config_option                          ▒
+   8.64%        9946  postmaster  0x5a3d4          f writeListPage     
+   5.75%        6609  postmaster  0x5a2b0          f ginHeapTupleFastCollect                    ▒
+   2.68%        3084  postmaster  0x192483         f build_implied_join_equality                ▒
+   2.61%        2990  postmaster  0x187a55         f build_paths_for_OR                         ▒
+   1.86%        2131  postmaster  0x794aa          f get_collation_oid                          ▒
+   1.56%        1822  postmaster  0x5a67e          f ginHeapTupleFastInsert                     ▒
+   1.53%        1766  postmaster  0x1929bc         f distribute_qual_to_rels                    ▒
+   1.33%        1558  postmaster  0x249671         f cmp_numerics

Aucune des requêtes effectuées par l'application n'est particulièrement complexe, avec des plans d'explication prenant au plus 1 seconde (la plupart sont beaucoup plus rapides). De plus, bien que cela se produise lorsque le trafic commence à s'accumuler, nous ne parlons pas d'une charge de trafic énorme (l'ancienne machine était capable de le gérer assez facilement).

À ce stade, je suis un peu perplexe sur ce qu'il faut essayer ensuite. Toute aide ou suggestion serait appréciée. S'il y a des informations supplémentaires qui pourraient aider, il suffit de demander et je peux modifier la question.

Configuration du disque:

Contrôleur RAID Perc 6i
5 disques SAS 15 Go de 146 Go
Configuré comme 2x146 Go RAID-1 pour WAL et 3x146 Go RAID-5 pour système et données

Mise à jour:

Vous trouverez ci-dessous la sortie VMStat lorsque le système fonctionne normalement et lorsque le CPU démarre. Lorsqu'il y a un problème, les interruptions semblent monter en flèche.

En fonctionnement normal:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 18938590 303763 21947154    0    0    28    52 7466 12649  2  1 97  0  0   2013-01-14 16:03:25 EST
 0  0      0 18938396 303763 21947154    0    0     0    19 7107 12679  2  0 98  0  0   2013-01-14 16:03:35 EST
 1  0      0 18938904 303763 21947162    0    0     0    54 7042 12708  1  1 99  0  0   2013-01-14 16:03:45 EST
 1  0      0 18938520 303763 21947260    0    0    33    66 7120 12738  1  1 99  0  0   2013-01-14 16:03:55 EST

Lorsque l'utilisation du processeur est élevée:

procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu------ ---timestamp---
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
343 0      0 32680468 226279 11339612    0    0     0   214 26692 12225 80  20  0  0  0   2013-01-11 16:45:53 EST
374 1      0 32673764 226291 11340345    0    0     0    77 54893 11572 80  20  0  0  0   2013-01-11 16:46:03 EST
383 0      0 32616620 226304 11340956    0    0     0   102 55540 12922 82  18  0  0  0   2013-01-11 16:46:13 EST
315 0      0 32602038 226320 11341378    0    0     0    79 54539 12441 82  18  0  0  0   2013-01-11 16:46:23 EST

postgresql

— jcern
source

Quel type de disques la nouvelle boîte a-t-elle? Est-ce que cela se produit sur les deux nœuds ou sur l'un d'eux seulement?

— Trygve Laugstøl

@trygvis - J'ai mis à jour la question avec les spécifications du disque. Le problème se produit sur le nœud maître. Je n'ai pas essayé de promouvoir l'esclave et de diriger le trafic vers lui, donc je ne suis pas sûr que ce soit là un problème dans les mêmes circonstances. En tant qu'esclave, la machine ne semble pas rencontrer de problème.

— jcern

Pensez à utiliser l' perfoutil pour effectuer un profilage à l'échelle du système et un profilage PostgreSQL. Voir où se produit l'utilisation du processeur. BTW, le formatage de votre 2e vmstatest désespérément altéré, et les colonnes du 1er sont mal alignées, donc c'est difficile à lire. Testez pour voir si l'ajout d'un commit_delayaméliore les choses. Vérifiez si votre contrôleur RAID dispose d'un cache d'écriture différée alimenté par batterie et si ce n'est pas le cas, procurez-vous-en un. Y a-t-il beaucoup de temps passé iowait? Cela semble être l'utilisation du processeur dans certains rapports, mais ce n'est pas vraiment le cas.

— Craig Ringer

@CraigRinger, le contrôleur dispose d'un cache d'écriture alimenté par batterie, qui est actuellement activé. L'attente de l'iostat est restée dans les chiffres simples à doubles. Nous continuerons à essayer un peu plus de profilage avec perf. J'ai également corrigé la mise en forme du deuxième VMStat, merci de l'avoir signalé.

— jcern

Après d'autres diagnostics et quelques recherches sur Google, nous sommes tombés sur cet article qui décrivait bon nombre des mêmes symptômes que nous connaissions. La cause profonde de leur problème (et de ce que nous pouvons dire, le nôtre aussi) était liée à la Transparent Huge Pagesmise en œuvre.

Après avoir désactivé Transparent Huge Pagesavec cette commande:

echo never > /sys/kernel/mm/redhat_transparent_hugepage/enabled

Le problème semble avoir été résolu. Nous fonctionnons avec une charge de travail accrue depuis deux semaines et le problème n'a pas refait surface. Les contextes et interruptions du système représentent toujours 1/10 de ce qu'ils étaient et la durée moyenne du système a également diminué.

Je ne sais pas si c'est la solution pour tout le monde, mais je la poste ici comme cause possible au cas où cela pourrait aider quelqu'un d'autre à résoudre un problème similaire.

— jcern
source