Fallo en el Rebake: ¿cómo diagnosticar y solucionar?

El uso de memoria es mucho mayor durante una reconstrucción que durante el funcionamiento normal. Parece que el rebaking, de manera similar, exige mucho. Si es así, cualquier tipo de monitoreo regular no aportaría mucho valor: el monitoreo sería necesario durante esos picos, que afortunadamente ocurren cuando el administrador realiza alguna acción específica.

Cuando estaba funcionando con una configuración de máquina más pequeña y más marginal, tenía una segunda ventana de terminal abierta, conectada por ssh a mi servidor y ejecutando
vmstat 5
lo que proporciona un registro del uso de memoria a medida que sube y baja. Observe la columna swpd y compárela con su espacio de intercambio (swap) configurado. Comúnmente, la falla ocurrirá repentinamente, no gradualmente, por lo que incluso observar las tendencias a corto plazo no ayuda mucho.

Si tiene espacio en disco, no hay ningún daño en tener mucho intercambio (swap): la mitad de la RAM, o incluso la misma cantidad que la RAM. Está ahí en este caso para hacer frente a los picos. No desea ver actividad de intercambio/paginación durante el uso normal. De nuevo, se puede usar vmstat 5 5 para obtener una imagen a corto plazo de la actividad de paginación (en las columnas si y so).

Aquí hay un ejemplo:

# 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

Se ve que la columna swpd alcanzó un pico de más de 1.5G, frente a mis 2.0G configurados. Se ve que la actividad de swapout (so) alcanzó su punto máximo en la misma ventana de 5 segundos, y el swapin (si) alcanzó su punto máximo en la siguiente ventana.

(Edición: Puedo ver que tenía 2.0G de swap configurado porque anteriormente había ejecutado free:

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

también vemos que en ese momento estaba logrando ejecutar discourse con solo 1G de RAM.)

1 me gusta