¿Debería preocuparme que el intercambio se esté utilizando en un host con casi 40 GB de memoria libre?


39

Tengo un anfitrión de producción, a continuación:

htop

El sistema está utilizando 1 GB de intercambio, mientras mantiene casi 40 GB de espacio de memoria libre y sin usar. ¿Debería preocuparme por esto o es sobre todo normal?


23
En realidad, debería preocuparle que un host de producción con carga real desperdicie casi 40 GB de memoria. Seguramente podría ser útil usar esa memoria: las aplicaciones están accediendo a los discos, ¿no podría usar esa memoria para almacenar en caché algunos de esos datos, reducir las E / S y mejorar su rendimiento? ¿Por qué se desperdician 40 GB de memoria en una máquina que está funcionando? Eso es lo que debería preocuparte. Eso no es normal.
David Schwartz el

25
Realmente sería más útil si nos mostraras el resultado de free -m. Los gráficos son difíciles de leer.
user9517 es compatible con GoFundMonica el

@DavidSchwartz: tengo una pregunta relacionada que todavía está activa solo por eso. serverfault.com/questions/825909/…
MrDuk

Respuestas:


68

Esto no es un problema y es probable que sea normal. Se usa mucho código (y posiblemente datos) muy raramente, por lo que el sistema lo cambiará para liberar memoria.

El intercambio es principalmente un problema si la memoria se intercambia dentro y fuera continuamente. Es ese tipo de actividad que mata el rendimiento y sugiere un problema en otras partes del sistema.

Si desea monitorear su actividad de intercambio, puede hacerlo con varias utilidades, pero vmstatgeneralmente es bastante útil, por ejemplo

$ vmstat 1
procs -----------memory---------- ---swap-- -----io---- --system-- -----cpu-----
 r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa st
 0  0      0 348256  73540 274600    0    0     1     9    9    6  2  0 98  0  0
 0  0      0 348240  73544 274620    0    0     0    16   28   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   29   33  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   21   23  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   24   26  0  0 100  0  0
 0  0      0 348240  73544 274620    0    0     0     0   23   23  0  0 100  0  0

Ignore la primera línea ya que es actividad desde que se inició el sistema. Tenga en cuenta las columnas siy sodebajo ---swap--; En general, deberían ser cifras bastante pequeñas, si no 0 para la mayoría de las veces.

También vale la pena mencionar que este intercambio preventivo se puede controlar con una configuración de kernel. El archivo en /proc/sys/vm/swappinesscontiene un número entre 0 y 100 que le dice al kernel qué tan agresivamente cambiar la memoria. Cat el archivo para ver en qué está configurado. De manera predeterminada, la mayoría de las distribuciones de Linux lo establecen en 60, pero si no desea ver ningún intercambio antes de que se agote la memoria, haga eco de un 0 en el archivo de esta manera:

echo 0 >/proc/sys/vm/swappiness

Esto puede hacerse permanente agregando

vm.swappiness = 0

a /etc/sysctl.conf.


14
También vale la pena mencionar que este intercambio preventivo se puede controlar con una configuración de kernel. El archivo en / proc / sys / vm / swappiness contiene un número entre 0 y 100 que le dice al kernel qué tan agresivo es cambiar la memoria. Cat el archivo para ver en qué está configurado. Por defecto, la mayoría de distribuciones de Linux por defecto esta a 60, pero si usted no quiere ver cualquier intercambio de memoria antes de que se agote, se hacen eco de un 0 en el archivo de la siguiente manera: echo 0 >/proc/sys/vm/swappiness. Esto puede hacerse permanente agregando vm.swappiness = 0a /etc/sysctl.conf.
virtex

@virtex: Me gusta usar swappiness = 1, o algo menos que 10, en mi escritorio. Eso también podría funcionar bien en los servidores la mayor parte del tiempo. Desaliente fuertemente el intercambio para liberar RAM para obtener más caché de página, sin prohibirlo por completo.
Peter Cordes

1
@PeterCordes Tenga cuidado con los servidores, especialmente aquellos que acceden a bases de datos o sirven archivos. Esos pueden beneficiarse mucho de la memoria disponible para cachés de archivos.
Jonas Schäfer

44
@JonasWielicki: Incluso con swappiness=7o algo, las páginas no utilizadas a largo plazo se intercambian. Hay una gran diferencia entre swappiness=0y cualquier otro valor, incluso valores bajos. El valor predeterminado del kernel swappiness=60generalmente es bueno para los servidores, y es solo para uso interactivo de escritorio donde un intercambio bajo es bueno. Pero establecerlo en 7 o algo no debería doler mucho. (Pero no lo he comprobado, no soy un administrador del sistema).
Peter Cordes

2
@PeterCordes Hasta que ejerzas presión sobre la memoria, cualquiera swappinessfunciona muy bien. Con la presión, verá que swappiness=7priva al caché del archivo casi por completo durante un período prolongado de tiempo, mientras que swappiness=60liquida mucho caché, pero también comienza a intercambiarse en segundos. Sigue siendo el caché el que recibe la paliza, pero de una manera mucho más equilibrada.
kubanczyk

25

Linux escribirá páginas de forma preventiva en el disco si no tiene nada mejor que hacer. Sin embargo, eso no significa que expulse esas páginas de la memoria. Es solo que en caso de que deba desalojar esas páginas en algún momento en el futuro, no necesita esperar a que se escriban en el disco, porque ya están allí.

Después de todo, la razón por la que se está quedando sin memoria, probablemente sea porque su máquina ya está trabajando duro, no desea cargarla adicionalmente con el intercambio. Es mejor hacer el intercambio cuando la máquina no está haciendo nada.

Por una razón similar, tu memoria siempre debe estar llena. Páginas de memoria, caché del sistema de archivos tmpfs, hay tantas cosas que podrían guardarse en la memoria. Realmente, deberías preocuparte si tu memoria está vacía; después de todo, pagaste mucho dinero por ello (al menos en comparación con la misma cantidad de espacio en disco), ¡así que será mejor que lo uses!


Jorg, las páginas que el núcleo escribe de manera preventiva en los discos no son páginas de intercambio, son páginas de caché de disco sucias. Los vm.dirty_background _... tunnables controlan eso. La actividad de intercambio comienza de acuerdo con la capacidad de intercambio y no espera tiempos inactivos.
Lucas

11

El intercambio utilizado no es malo, pero hay mucha actividad de intercambio

  vmstat 1
  procs -----------memory---------- ---swap-- -----io---- -system-- ----cpu----
  r  b   swpd   free   buff  cache   si   so    bi    bo   in   cs us sy id wa
  6  0 521040 114564   6688 377308    8   13   639   173    0 1100  5  4 90  0
  1  0 521040 114964   6688 377448    0    0   256     0    0 1826  3  4 94  0
  0  0 521040 115956   6688 377448    0    0     0     0    0 1182  7  3 90  0
  0  0 521036 115992   6688 377448    4    0    16     0    0 1154 10  2 88  0
  3  0 521036 114628   6696 377640    0    0   928   224    0 1503 15 17 67  1

El intercambio de columnas no es un problema en absoluto. Los valores distintos de cero en las columnas si y so son mortales para el rendimiento del servidor. Especialmente los que tienen mucha RAM.

Es mejor deshabilitar el intercambio en máquinas con varios GB de RAM:

sysctl -w vm.swappiness=0

Esto no deshabilitará el intercambio. Solo le indicará a Linux que use el intercambio como medida de último recurso. Esto desperdiciará unos pocos MB de programas que no necesitan estar en la RAM ... Pero es preferible intercambiar las colas de acceso al disco.

Edición 1: por qué el valor predeterminado de intercambio no es óptimo

Recordemos hace dos décadas que un gran 486 tenía solo 32Mb de RAM. Los algoritmos de intercambio se desarrollaron cuando toda la RAM se podía mover al disco en una pequeña fracción de segundo. Incluso con los discos más lentos de esa época. Es por eso que las políticas de intercambio predeterminadas son tan agresivas. RAM fue el cuello de botella en esos días. Desde entonces, el tamaño de RAM aumentó más de 10,000 veces y las velocidades de disco menos de 10 veces. Esto cambió el cuello de botella al ancho de banda del disco.

Edición 2: ¿por qué si la actividad es mortal para los servidores?

Si y así, la actividad en máquinas con toneladas de RAM es mortal porque significa que el sistema está luchando consigo mismo por la RAM. Lo que sucede es que los discos, incluso los grandes almacenes son demasiado lentos en comparación con las RAM. El intercambio agresivo favorece la memoria caché del disco del núcleo sobre los datos de la aplicación y es la fuente más común de lucha por la RAM. Dado que el sistema operativo tendrá que liberar el caché de disco en cada si , el tiempo de vida del caché adicional que proporciona el intercambio es demasiado bajo para ser útil de todos modos. El resultado es que está tomando el ancho de banda del disco para almacenar la memoria caché que probablemente no se usará y pausando sus programas esperando las páginas si . Lo que significa que consume muchos recursos críticos con poco o ningún beneficio para las aplicaciones.

Tenga en cuenta el título de la respuesta "mucha actividad de intercambio en servidores con mucha RAM". Esto no se aplica a máquinas con actividad ocasional. Esto puede no aplicarse en el futuro si se desarrollan algoritmos de intercambio más inteligentes en los sistemas operativos.

Edición 3: páginas "frías"

La gente idealiza el algoritmo de intercambio. Algunos dicen "se necesitan páginas menos usadas de la RAM", pero esto no es lo que hace el núcleo. Lo que es difícil de entender sobre el intercambio es que el núcleo no sabe qué es una "página en frío". El núcleo no tiene una buena métrica para determinar si la página se usa o es probable que se use en el futuro cercano. Para evitar que el kernel ponga páginas en el intercambio más o menos al azar y las páginas que no son necesarias se quedan allí. El problema de ese algoritmo es que las páginas deben ir al intercambio para saber si las aplicaciones las necesitan. Y esto significa que muchas páginas "populares" irán al intercambio. El problema es que los discos son demasiado lentos en comparación con la RAM.

Construí mi propio punto de referencia que es un escenario realista muy común para muchas aplicaciones con un volumen decente. De mis pruebas, no vi beneficios en el rendimiento o la latencia cuando se usan swaps. Lejos de ahi. Cuando comienza el intercambio, ralentiza tanto el rendimiento como la latencia al menos en un orden de magnitud.

Voy un poco más al respecto: entiendo que el intercambio no es para procesar. Los swaps son solo para emergencias. Esos momentos en los que se ejecutan demasiadas aplicaciones al mismo tiempo y obtienes un pico de memoria. Sin intercambio, esto causaría errores de falta de memoria. Considero que el uso de intercambio es un fracaso de los equipos de desarrollo y producción. Esta es solo una opinión que va mucho más allá de lo que discutimos aquí, pero es lo que creo. Por supuesto, mis aplicaciones tienen una excelente administración de memoria por sí mismas.


9
"Mejor deshabilitar el intercambio" Mejor, ¿por qué? (¿Mejor, para qué?) El valor predeterminado puede no ser adecuado para todos los usos, pero aún necesito una razón para cambiarlo.
jpaugh

3
¿Cómo es simás mortal para su servidor que bi? Ambos significan que algún programa está esperando que se lean 4096 bytes del disco a la memoria. El biarchivo es de cualquier archivo y side una categoría específica de archivos (pero sus bytes se mueven igual de rápido a través de la misma ruta).
kubanczyk

2
Un 486 con 128 MB de RAM era muy raro y habría sido considerado un mainframe o una supercomputadora, por lo que la CPU probablemente no habría sido 486. Mi viejo 486 tenía 4 MB de RAM y tenía envidia de la máquina de mi amigo con 16 MB de ram (servidores grandes tenía 16 a 32 MB de RAM). Avancemos rápidamente a Pentiums y comenzamos a ver de 8 a 16 MB como lo normal. Cuando apareció Pentium3 por primera vez (cuando las CPU comenzaron a superar normalmente los 1 GHz), 32 MB era normal y los servidores web normalmente tenían de 64 a 128 MB.
slebetman

swappiness=0Parece totalmente inapropiado para los servidores. Puede considerarlo para un sistema de escritorio interactivo (pero incluso así, swappiness=1es una mejor opción para eventualmente intercambiar páginas realmente frías). Ver comentarios sobre otra respuesta . swappiness=7o algo reducirá drásticamente la actividad de intercambio sin fijar páginas frías en la RAM hasta OOM, y vale la pena considerarlo si cree que 60es demasiado intercambiable para un servidor específico.
Peter Cordes

1
@kubanczyk: Creo que sies peor que bi. La mayoría del software de servidor está diseñado en el supuesto de que la E / S del disco puede ser lenta y utiliza subprocesos, E / S asíncrona o alguna otra técnica para mantener la capacidad de respuesta en general mientras se espera la E / S. Un fallo de página podría suceder en cualquier lugar. En el peor de los casos, podría ocurrir un error de página lenta después de bloquear, bloqueando el acceso de todos los otros hilos a esa sección crítica durante ~ 10 ms (con intercambio en almacenamiento de rotación lenta). Eso podría ser plausible si una sección crítica copia datos de una estructura de datos compartida a una página potencialmente fría.
Peter Cordes

8

Esta no es una respuesta a su pregunta; sino más bien, solo información adicional para ayudarlo a tomar una decisión informada.

Si desea saber qué procesos están utilizando específicamente cuánto intercambio, aquí hay un pequeño script de shell:

#!/bin/bash

set -o posix
set -u

OVERALL=0
for DIR in `find /proc/ -maxdepth 1 -type d -regex "^/proc/[0-9]+"` ; do
  PID=`echo $DIR | cut -d / -f 3`
  PROGNAME=`ps -p $PID -o comm --no-headers`

  SUM=0
  for SWAP in `grep Swap $DIR/smaps 2>/dev/null| awk '{ print $2 }'` ; do
    let SUM=$SUM+$SWAP
  done
  echo "PID=$PID - Swap used: $SUM - ($PROGNAME )"

  let OVERALL=$OVERALL+$SUM
done
echo "Overall swap used: $OVERALL"

También debo agregar que tmpfs también se intercambiará. Esto es más común en los sistemas Linux modernos que usan systemd que crean superposiciones de espacio de usuario / tmp usando tmpfs.


Buen guión. Echa un vistazo a smem también.
user9517 es compatible con GoFundMonica el

Creo que podría escribir eso de manera mucho más eficiente ( muchos menos procesos bifurcados) con awk '/Swap/ {sw += $2} FNR==1 { /*first line of a new file */ find the command somehow, maybe still fork/exec ps;} END { print totals }' /proc/[0-9]*/smaps. Eso ejecuta cut y ps para cada proceso, y grep + awk varias veces para cada proceso en el sistema.
Peter Cordes

0

He notado que la replicación de MySQL Cluster se ralentiza o falla cuando los agentes están intercambiando mucho. Tal vez a algunas aplicaciones no les importe o tal vez incluso se beneficien de un intercambio, pero las bases de datos realmente parecen sufrirlo. Sin embargo, muchas discusiones que he visto en foros discuten el intercambio descontextualizado de la discusión de la carga de trabajo específica.

En el mundo de DBA, el consenso parece ser que "es de sentido común que cuando se ejecuta MySQL (o realmente cualquier otro DBMS) no desea ver ninguna E / S en su espacio de intercambio. Escalar el tamaño de la caché (usando innodb_buffer_pool_size en el caso de MySQL) es una práctica estándar para asegurarse de que hay suficiente memoria libre, por lo que no es necesario el intercambio.

Pero, ¿qué sucede si comete algún error o error de cálculo y se produce el intercambio? ¿Cuánto impacta realmente el rendimiento? Esto es exactamente lo que me propuse investigar. "

Espero que los lectores encuentren los siguientes enlaces a propósito.

https://www.percona.com/blog/2017/01/13/impact-of-swapping-on-mysql-performance/

https://www.percona.com/blog/2010/01/18/why-swapping-is-bad-for-mysql-performance/


1
¡Bienvenido a Server Fault! Si bien esto puede responder teóricamente la pregunta, sería preferible incluir aquí las partes esenciales de la respuesta y proporcionar el enlace para referencia.
Frederik Nielsen
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.