Échec du Rebake : comment diagnostiquer et réparer ?

L’utilisation de la mémoire est beaucoup plus importante lors d’une reconstruction que pendant le fonctionnement normal. Il semble que le rebaking (re-cuisson), de même, demande beaucoup. Si c’est le cas, toute sorte de surveillance régulière n’ajouterait pas beaucoup de valeur : la surveillance serait nécessaire pendant ces pics, qui heureusement se produisent lorsque l’administrateur effectue une action spécifique.

Lorsque je fonctionnais sur une configuration de machine plus petite et plus marginale, j’avais une deuxième fenêtre de terminal ouverte, connectée en ssh à mon serveur et exécutant
vmstat 5
ce qui donne un enregistrement de l’utilisation de la mémoire au fur et à mesure qu’elle va et vient. Surveillez la colonne swpd et comparez-la à votre espace d’échange (swap) configuré. Couramment, la défaillance se produit soudainement, pas progressivement, donc même regarder les tendances à court terme n’est pas d’une grande aide.

Si vous avez de l’espace disque, il n’y a aucun mal à avoir beaucoup d’espace d’échange (swap) - la moitié de la RAM, ou même autant que la RAM. Il est là dans ce cas pour gérer les pics. Vous ne voulez pas voir d’activité d’échange (swapping/paging) pendant l’utilisation normale. Encore une fois, on peut utiliser vmstat 5 5 pour obtenir une image à court terme de l’activité de pagination (paging) (dans les colonnes si et so).

Voici un exemple :

# vmstat 5 5
procs -----------memory----------   ---swap--  -----io---- -system--  ------cpu-----
 r  b   swpd   free   buff  cache     si    so    bi    bo   in    cs us sy id wa st
 3  0 1392140  61200  11632  76432    41    32   117    93    0     1  2  1 97  0  0
 1  1 1467220  63416    324  67284  8786 20499 13178 20567 2539  8924 77 13  0 10  0
 0  2 1593340  57916   1096  53832 24262 46868 29986 46889 5377 18534 44 22  0 34  0
 4  0 1155632 120680   2772  86280 39111 35424 54768 37824 6987 25174 38 27  0 35  0
 3  0 1102988  74096   2852  85276 11261   246 12610   271 1879  6365 86  6  0  8  0

Vous voyez que la colonne swpd a atteint un pic de plus de 1,5 Go, par rapport à mes 2,0 Go configurés. Vous voyez que l’activité de swapout (so) a atteint un pic dans la même fenêtre de 5 secondes, et le swapin (si) a atteint un pic dans la fenêtre suivante.

(Modification : Je peux voir que j’avais configuré 2,0 Go de swap parce que j’avais précédemment exécuté free :

# free
              total        used        free      shared  buff/cache   available
Mem:        1009140      696504       78544       51784      234092      118436
Swap:       2097144      154628     1942516

nous voyons aussi que j’arrivais à faire fonctionner discourse avec seulement 1 Go de RAM à ce moment-là.)

1 « J'aime »