¿Cómo puede ser tan lento el intercambio?

De alguna manera, cambié 14 GB de memoria. Después de haber matado al culpable, tengo toneladas de memoria libre nuevamente, así que pensé que podría traer los datos importantes nuevamente. Entonces, con 5 GB de 32 GB utilizados y 14 GB de espacio de intercambio utilizado, corrí swapoff -a... y 4 horas más tarde, aproximadamente la mitad del trabajo estaba terminado.

Esto significa menos de 1 MB / s, mientras que puedo copiar fácilmente 200 MB / s. Mi intercambio está encriptado, pero también lo están todas las particiones normales y con aes-ni no conduce a una carga notable de CPU (y llenar el espacio de intercambio tomó solo unos minutos). Veo que no hay una razón especial para optimizar swapoff, sin embargo, me pregunto cómo podría ser tan lento.

Solo agrego algunos datos más: mi memoria principal es de 32 GB y tengo espacio de intercambio de 32 GB en cada uno de los 4 discos duros (seguramente una exageración, pero ¿a quién le importa?). Todo el espacio de intercambio se puede (descifrar y) leer en menos de 5 minutos:

time -p sudo sh -c 'for i in /dev/mapper/cryptswap?; do md5sum $i & done; wait'
014a2b7ef300e11094134785e1d882af  /dev/mapper/cryptswap1
a6d8ef09203c1d8d459109ff93b6627c  /dev/mapper/cryptswap4
05aff81f8d276ddf07cf26619726a405  /dev/mapper/cryptswap3
e7f606449327b9a016e88d46049c0c9a  /dev/mapper/cryptswap2
real 264.27

Leer una parte de una partición no puede ser más lento que leerlo todo. Sin embargo, leer alrededor de 1/10 toma alrededor de 100 veces más.

Observé que durante swapoffla CPU la mayoría estaba inactiva (quizás el 10% de un núcleo) y también los discos ("medidos" por los LED). También vi que los espacios de intercambio se desactivaron uno tras otro.

Primero, echemos un vistazo a lo que puede esperar de su disco duro. Su disco duro puede hacer 200 MB / s secuencialmente . Cuando factoriza tiempos de búsqueda, puede ser mucho más lento. Para elegir un ejemplo arbitrario, eche un vistazo a las especificaciones de uno de los discos modernos de 3 TB de Seagate, el ST3000DM001 :

• Velocidad de datos máxima sostenida: 210 MB / s

• Buscar lectura promedio: <8,5 ms

• Bytes por sector: 4,096

Si nunca necesita buscar, y si su intercambio está cerca del borde del disco, puede esperar ver hasta la velocidad máxima = 210 MB / s

Pero si sus datos de intercambio están completamente fragmentados, en el peor de los casos, necesitaría buscar por cada sector que lea. Eso significa que solo puede leer 4 KB cada 8,5 ms, o 4 KB / 0.0085 = 470 KB / s

Así que de inmediato, no es inconcebible que de hecho estés corriendo contra la velocidad del disco duro.

Dicho esto, parece una tontería que swapoffse ejecute tan lentamente y tenga que leer las páginas fuera de orden, especialmente si se escribieron rápidamente (lo que implica un orden). Pero esa puede ser la forma en que funciona el núcleo. El informe de error de Ubuntu # 486666 discute el mismo problema:

The swap is being removed at speed of 0.5 MB/s, while the
hard drive speed is 60 MB/s;
No other programs are using harddrive a lot, system is not under
high load etc.

Ubuntu 9.10 on quad core.

Swap partition is encrypted.
Top (atop) shows near 100% hard drive usage
  DSK | sdc | busy 88% | read 56 | write 0 | avio 9 ms |
but the device transfer is low (kdesysguard)
  0.4 MiB/s on /dev/sdc reads, and 0 on writes

Una de las respuestas fue:

It takes a long time to sort out because it has to rearrange and flush the
memory, as well as go through multiple decrypt cycles, etc. This is quite
normal

El informe de error se cerró sin resolver.

El libro de Mel Gorman " Comprender el administrador de memoria virtual de Linux " está un poco desactualizado, pero está de acuerdo en que esta es una operación lenta:

La función responsable de desactivar un área es, como era de esperar, llamada sys_swapoff(). Esta función se ocupa principalmente de actualizar el swap_info_struct. La tarea principal de paginación en cada página paginada es la responsabilidad de la try_to_unuse()cual es extremadamente costosa.

Hay un poco más de discusión desde 2007 sobre la lista de correo del kernel de Linux con el tema " acelerar el intercambio ", aunque las velocidades que están discutiendo allí son un poco más altas de lo que está viendo.

Es una pregunta interesante que probablemente generalmente se ignora, ya swapoffque rara vez se usa. Creo que si realmente quería seguir hacia abajo, el primer paso sería tratar de ver sus patrones de uso de disco con más cuidado (tal vez con atop, iostato incluso las herramientas más potentes como perfo systemtap). Lo que debe buscar puede ser una búsqueda excesiva, pequeñas operaciones de E / S, reescritura constante y movimiento de datos, etc.

He estado experimentando el mismo problema con mi computadora portátil que tiene un SSD, por lo que buscar tiempos no debería ser un problema.

Encontré una explicación alternativa . Aquí hay un extracto

De la forma en que funciona ahora, swapoff examina cada página de memoria intercambiada en la partición de intercambio e intenta encontrar todos los programas que la usan. Si no puede encontrarlos de inmediato, mirará las tablas de páginas de cada programa que se esté ejecutando para encontrarlos. En el peor de los casos, verificará todas las tablas de páginas para cada página intercambiada en la partición. Así es, las mismas tablas de páginas se revisan una y otra vez.

Por lo tanto, es un problema de kernel en lugar de cualquier otra cosa.

Sí, el swapoffmecanismo es terriblemente ineficiente. La solución es fácil: iterar sobre procesos, en lugar de iterar sobre las páginas intercambiadas. Utilice este script de Python (no estoy afiliado):

git clone https://github.com/wiedemannc/deswappify-auto

Tenga en cuenta que el modo de operación daemon es solo para computadoras de escritorio / portátiles que a menudo se hibernan. No lo ejecutaría como un demonio en un sistema de servidor; solo ejecútelo en primer plano, espere hasta que informe que se encargó de algunos procesos, luego deténgalo e intente:

swapoff /dev/x

Dado que la mayoría de las páginas ahora están presentes tanto en intercambio como en memoria, swapofftiene muy poco que hacer y ahora debería ser increíblemente rápido (vi cientos de MB / s).

Sección de historia por delante

El script python mencionado anteriormente se basa en el resto de esta respuesta, que a su vez fue mi mejora de esta respuesta anterior creada por jlong . Como el guión es mucho más seguro, recomiendo probar solo el resto de mi respuesta como la última línea de defensa :

perl -we 'for(`ps -e -o pid,args`) { if(m/^ *(\d+) *(.{0,40})/) { $pid=$1; $desc=$2; if(open F, "/proc/$pid/smaps") { while(<F>) { if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ $start_adr=$1; $end_adr=$2; }  elsif(m/^Swap:\s*(\d\d+) *kB/s){ print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" }}}}}' | sort -Vr | head

Esto va quizás a 2 segundos y en realidad no hacer nada, sólo una lista de los 10 segmentos de memoria superior (en realidad se imprime más de una sola línea; sí, yo no amo de una sola línea, simplemente examinar los comandos, aceptar el riesgo, copiar y pegar en su caparazón; estos en realidad leerán de intercambio).

...Paste the generated one-liners...
swapoff /your/swap    # much faster now

El one-liner principal es seguro (para mí), excepto que lee mucho / proc.

Los subcomandos preparados para su examen manual no son seguros . Cada comando colgará un proceso mientras dure el intercambio de un segmento de memoria. Por lo tanto, no es seguro con procesos que no toleran ninguna pausa. Las velocidades de transferencia que vi fueron del orden de 1 gigabyte por minuto. (El script Python mencionado anteriormente eliminó esa deficiencia).

Otro peligro es poner demasiada presión de memoria en el sistema, así que verifique con lo habitual free -m

¿Qué hace?

for(`ps -e -o pid,args`) {

  if(m/^ *(\d+) *(.{0,40})/) { 
    $pid=$1; 
    $desc=$2; 

    if(open F, "/proc/$pid/smaps") { 

      while(<F>) { 

        if(m/^([0-9a-f]+)-([0-9a-f]+) /si){ 
          $start_adr=$1; 
          $end_adr=$2; 
        } elsif( m/^Swap:\s*(\d\d+) *kB/s ){
          print "SSIZE=$1_kB\t gdb --batch --pid $pid -ex \"dump memory /dev/null 0x$start_adr 0x$end_adr\"\t2>&1 >/dev/null |grep -v debug\t### $desc \n" 
        }
      }
    }
  }
}

El resultado de este script perl es una serie de gdbcomandos dump memory (range)que recuperan páginas intercambiadas a la memoria.

La salida comienza con el tamaño, por lo que es bastante fácil pasarlo | sort -Vr | headpara obtener los 10 segmentos más grandes por tamaño (SSIZE). Los -Vsoportes para la clasificación version-number-adecuado, pero funciona para mi propósito. No pude entender cómo hacer que la ordenación numérica funcione.

Durante el intercambio, si se detecta una ranura de intercambio en uso, el núcleo primero se intercambia en la página. La función unuse_process () intenta encontrar todas las entradas de la tabla de páginas que corresponden a la página recién intercambiada y realiza la actualización necesaria de las tablas de páginas. La búsqueda es exhaustiva y requiere mucho tiempo: visita cada descriptor de memoria (de todo el sistema) y examina las entradas de la tabla de páginas una por una.

Consulte la página 724 de "Comprensión de la tercera versión del kernel de Linux".