La caché de páginas de Linux ralentiza la E/S en un servidor de doble CPU con 64 GB de RAM

Question

Tengo un gran problema con el caché de la página de Linux que ralentiza el IO. Por ejemplo, si copio una partición lvm con dd, Linux almacena en caché los datos en los buffers o cachés (free –m). Ese no es el problema, pero después de que el búfer alcanza un valor especial, el proceso de copia se detiene y se ralentiza a unos pocos MB o incluso kbs. He realizado muchas pruebas escribiendo en el disco o /dev/null, el problema no tiene nada que ver con la unidad de origen o el destino.

En detalle:

• Hay dos servidores casi idénticos. Ambos ejecutan CentOS 6.5 con el mismo kernel. Tienen los mismos discos, la misma configuración, el mismo hardware, el mismo en todos los sentidos. La única diferencia es que un servidor tiene 2 CPU y 64 GB de RAM y el otro 1 CPU y 32 GB de RAM.
• Aquí también hay una imagen del siguiente proceso de copia:https://i.stack.imgur.com/tYlym.jpg
• Aquí una nueva versión también con meminfo. La meminfo es de una ejecución diferente, por lo que los valores no son idénticos, pero tiene el mismo comportamiento completo:https://i.stack.imgur.com/4SIJG.jpg
• Inicie la copia con dd u otro programa de copia del sistema de archivos.
• El búfer o caché comienza a llenarse. Todo está bien.
• El búfer o caché alcanza un número máximo (en un servidor de 64 GB de RAM, un valor como 32 GB o 17 GB; en un servidor de 32 GB de RAM, toda la memoria libre)
• En un servidor de 64 GB de RAM, el proceso de copia ahora se detiene o se limita a unos pocos MB. En el servidor de RAM de 32 GB todo está bien.
• En un servidor de RAM de 64 GB puedo resolver el problema por un momento forzando el caché con "sync; echo 3 > /proc/sys/vm/drop_caches". Pero, por supuesto, el búfer comienza a crecer nuevamente instantáneamente y el problema vuelve a ocurrir.

Conclusión:

El problema tiene algo que ver con la segunda CPU o con la cantidad total de memoria. Tengo la “sensación” de que el problema podría ser que cada CPU tiene su propia RAM de 32 GB y el proceso de copia se ejecuta solo en la CPU. Entonces, finalmente, el proceso de copia aumentó el búfer/caché a casi 32 GB o a la memoria no utilizada de la otra CPU y luego Linux piensa que todavía hay memoria, así que vamos a aumentar aún más el búfer, pero el hardware siguiente no puede acceder a la memoria, o algo así. como eso.

¿Alguien tiene una idea o una solución?Claro que puedo usar dd con bandera directa, pero eso no resuelve el problema, porque también hay acceso externo a través de samba, etc.

EDITAR1:

Aquí también el /proc/zoneinfo del servidor de ram de 64GB: 1.http://pastebin.com/uSnpQbeD(antes de que comience dd) 2.http://pastebin.com/18YVTfdb(cuando dd deja de funcionar)

EDITAR2:

• Configuración de máquina virtual:http://pastebin.com/U9E9KkFS
• /proc/sys/vm/zone_reclaim_mode estaba en el servidor 0 de RAM de 32 GB y en el servidor 1 de RAM de 64 GB. Nunca toco estos valores. El instalador los configuró. Lo cambié temporalmente a 0 y volví a intentar la prueba. Ahora toda la memoria se utiliza para búfer y caché. Se ve genial y se parece al otro servidor. Pero luego instantáneamente comienza a intercambiarse a toda velocidad... Configuré el intercambio en 0. Eso ayuda, pero aún así intercambia unos pocos MB por segundo. Y aumenta los buffers cada segundo. Entonces no intercambia el búfer, intercambia la memoria del vms para obtener más memoria para aumentar los búferes... una locura. ¿Pero tal vez esto sea normal?

EDITAR3:

/proc/buddyinfo y numactl --hardware: http://pastebin.com/0PmXxxin

RESULTADO FINAL

• /proc/sys/vm/zone_reclaim_mode es sin duda la forma técnica correcta, pero la máquina no funcionó muy bien después. Por ejemplo: si copio un disco Linux, uso ahora el 100% de la memoria libre para almacenar en el buffer (no como antes, solo XGB y luego paro). Pero en el momento en que la última memoria libre se usó para almacenar en búfer, Linux comienza a intercambiar la memoria de la máquina virtual y aumenta la cantidad total de búfer y cachés. El intercambio normalmente no es necesario en mi sistema, por lo que la memoria de intercambio está en el mismo disco que algunas máquinas virtuales. Como resultado, si hago una copia de seguridad de estos vms Linux, escribo el intercambio al mismo tiempo que leo desde el disco para la copia de seguridad. Por lo tanto, es malo cambiar el vms, pero es aún peor que Linux destruya mi velocidad de lectura de respaldo... Entonces, la configuración de /proc/sys/vm/zone_reclaim_mode en 0 no resuelve el problema completo... actualmente ejecuto en un muestra un script que sincroniza y actualiza el caché cada 10 segundos... no es agradable, pero funciona mucho mejor para mí. No tengo ningún servidor web ni servidor de archivos normal en el sistema. Solo ejecuto vms, hago copias de seguridad y almaceno copias de seguridad a través de samba. No me gusta la solución.

Answer 1

El comportamiento que está viendo se debe a la forma en que Linux asigna memoria en un sistema NUMA.

Supongo (sin saberlo) que el sistema de 32 GB no es numa, o no es lo suficientemente numa como para que a Linux le importe.

El comportamiento de cómo tratar con numa lo dicta la /proc/sys/vm/zone_reclaim_modeopción. De forma predeterminada, Linux detectará si está utilizando un sistema numa y cambiará los indicadores de recuperación si cree que brindaría un mejor rendimiento.

La memoria se divide en zonas, en el sistema numa hay una zona para el primer zócalo de la CPU y una zona para el segundo. Estos aparecen como node0y node1. Puedes verlos si tienes gato /proc/buddyinfo.

Cuando el modo de recuperación de zona se establece en 1, la asignación desde el primer socket de la CPU hará que se produzca la recuperación en la zona de memoria asociada con esa CPU, esto se debe a que es más eficiente en términos de rendimiento recuperar desde un nodo numa local. En este sentido, recuperar es descartar páginas, como borrar el caché o intercambiar cosas en ese nodo.

Establecer el valor en 0 provoca que no se produzcan reclamaciones si la zona se está llenando, sino que se asigna a zonas numa externas para la memoria. Esto tiene el costo de un breve bloqueo de la otra CPU para obtener acceso exclusivo a esa zona de memoria.

¡Pero luego comienza a cambiar instantáneamente! después de unos segundos: Memoria: 66004536k en total, 65733796k usados, 270740k libres, 34250384k buffers Intercambio: 10239992k en total, 1178820k usados, 9061172k libres, 91388k en caché

El comportamiento de intercambio y cuándo intercambiar está determinado por algunos factores, uno de los cuales es qué tan activas son las páginas que se han asignado a las aplicaciones. Si no son muy activos, se intercambiarán a favor del trabajo más ocupado que se produce en la caché. Supongo que las páginas de sus máquinas virtuales no se activan con mucha frecuencia.