Hay dos configuraciones simples a nivel del sistema operativo Linux que la gente parece estar pasando por alto la configuración correcta en sus sistemas de producción que he visto. Estos están documentados en otros lugares, pero siguen apareciendo y parece que necesitan una revisión rápida aquí. No es que se trate de una configuración súper secreta o de una bala mágica para arreglar el rendimiento, pero son cosas que en una base de datos Couchbase de producción deberían estar correctamente configuradas e incorporadas en cualquier sistema/proceso que uses para arrancar los nodos que usas para Couchbase. Ayudan con el rendimiento de memcached y el rendimiento de rebalanceo y en algunos casos problemas de estabilidad.
Por favor, asegúrese de probar estos en un entorno de prueba en primer lugar antes de pasar a la producción con ellos, obviamente.
El intercambio debe desactivarse
Esto es bastante sencillo si conoces el sistema de memoria virtual de Linux. Los niveles de intercambio le dicen al subsistema de memoria virtual cuánto debe intentar intercambiar a disco. La cuestión es que el sistema intentará intercambiar elementos en memoria incluso cuando haya mucha RAM disponible en el sistema. El valor por defecto del sistema operativo suele ser 60, que es un poco agresivo en mi opinión. Puedes ver a qué valor está configurado tu sistema ejecutando el siguiente comando:
Dado que Couchbase está ajustado para operar realmente en memoria tanto como sea posible. Puedes ganar o al menos no perder rendimiento simplemente cambiando el valor de swappiness a 0. En lenguaje no técnico, esto le dice al subsistema de memoria virtual del sistema operativo que no intercambie elementos de RAM a disco a menos que realmente tenga que hacerlo, lo que si tienes dimensionar correctamente sus nodosel intercambio no debería ser necesario. Para configurar esto, realice el siguiente proceso use sudo o simplemente conviértase en root si cabalga en el salvaje oeste.
sudo sh -c 'echo 0 > /proc/sys/vm/swappiness'
# Copia de seguridad de sysctl.conf
sudo cp -p /etc/sysctl.conf /etc/sysctl.conf.date +%Y%m%d-%H:%M
# Establece el valor en /etc/sysctl.conf para que se mantenga después de reiniciar.
sudo sh -c 'echo "" >> /etc/sysctl.conf'
sudo sh -c 'echo "#Set swappiness to 0 to avoid swapping" >> /etc/sysctl.conf'
sudo sh -c 'echo "vm.swappiness = 0" >> /etc/sysctl.conf'
Asegúrese de tener o modificar su proceso que construye sus sistemas operativos para hacer esto. Esto es especialmente crítico para nubes públicas/privadas donde es tan fácil crear nuevas instancias. Necesitas hacer esto parte de tu proceso de construcción para un nodo Couchbase.
Desactivar Páginas Transparentes Enormes (THP)
A partir de la versión 6 de Red Hat Enterprise Linux (RHEL), que incluye también CentOS 6 y 7, se implementó en el sistema operativo un nuevo método predeterminado de gestión de páginas grandes. Ubuntu también tiene esta configuración a partir de la versión 12.02, por lo que también será necesario cambiarla. THP combina páginas de memoria más pequeñas en Páginas Enormes sin que los procesos en ejecución lo sepan. La idea es reducir el número de búsquedas en TLB requeridas y por lo tanto aumentar el rendimiento. Aporta abstracción para la automatización y gestión de páginas enormes básicamente. Couchbase Engineering ha determinado que bajo algunas condiciones, Couchbase Server puede verse afectado negativamente por graves retrasos en la asignación de páginas cuando THP está activado.. Por ello, Couchbase recomienda desactivar THP en todos los nodos del Servidor Couchbase
Confirme si es necesario desactivar la configuración del sistema operativo
Compruebe el estado de THP emitiendo los siguientes comandos:
cat /sys/kernel/mm/transparent_hugepage/defrag
En algunas variantes de Red Hat o Red Hat, es posible que tenga que hacer esto:
cat /sys/kernel/mm/redhat_transparent_hugepage/defrag
Si en uno o ambos archivos, la salida tiene este aspecto, necesita el siguiente procedimiento:
Copiar el script de inicio
El script init está diseñado para asegurarse de que los cambios se realizan más o menos al mismo tiempo que Couchbase se carga al reiniciar.
### BEGIN INIT INFO
# Proporciona: disable-thp
# Requerido-Inicio: $local_fs
# Parada obligatoria:
# Arranque por defecto: 2 3 4 5
# Parada por defecto: 0 1 6
# Short-Description: Desactivar THP
# Descripción: desactiva las Páginas Transparentes Enormes (THP) en el arranque.
### END INIT INFO
inicio)
if [ -d /sys/kernel/mm/transparent_hugepage ]; then
echo 'never' > /sys/kernel/mm/transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/transparent_hugepage/defrag
elif [ -d /sys/kernel/mm/redhat_transparent_hugepage ]; then
echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/enabled
echo 'never' > /sys/kernel/mm/redhat_transparent_hugepage/defrag
si no
devolver 0
fi
;;
esac
Cómo registrar el código en el sistema operativo
Haz lo siguiente:
Crear un archivo con el código anterior
Chmod el archivo para que sea ejecutable
Ejecútalo para que surta efecto ahora mismo
Asegúrese de que el script init se inicia en el arranque
Variantes de Red Hat:
Ubuntu:
Probar el proceso
Compruebe el estado de THP emitiendo los siguientes comandos:
cat /sys/kernel/mm/transparent_hugepage/defrag
En algunas variantes de Red Hat o Red Hat, puede que tenga que hacer esto en su lugar:
cat /sys/kernel/mm/redhat_transparent_hugepage/defrag
Para ambos archivos, el resultado debería ser el siguiente:
Nota: Hay una forma diferente de hacer esto que encontrarás en otro sitio y edita /etc/grub.conf. Mi problema con esto es que sería volado con cada actualización del kernel en el futuro. Lo que propongo es más fácil de gestionar a largo plazo y fácil de poner en algo como un módulo Puppet o una receta Chef para añadir al final de rc.local cuando se arranca un nodo.
THP es una gran característica para algunas cosas, pero causa problemas con aplicaciones como Couchbase. No es el único. Si buscas en Internet páginas transparentes enormes, hay múltiples problemas documentados de otros vendedores de DB y aplicaciones sobre esto. Hasta que se encuentre algo que funcione con esto, es mejor desactivar THP.
\"sudo echo > file\" no hace lo que crees que hace.
\"sudo sh -c \'echo > archivo\'\" (o echo | sudo tee archivo) hace.
Bien visto. Arreglado. Gracias.
Si bien estoy de acuerdo en que la swappiness debe ser baja, es posible que desee ejecutar a través de algunas pruebas con el kernel 2.6.32. Hubo una modificación en cómo se comporta vm.swappiness=0, y he visto reportes de que el kernel mata servicios como MySQL debido a OOM, aún cuando parte de la RAM estaba siendo usada para el cache de archivos. Corro con vm.swappiness=1 en lugar de 0, lo que significa que el kernel no debería intercambiar a menos que realmente tenga que hacerlo... pero es capaz de hacerlo si tiene que hacerlo, en lugar de matar procesos.
Genial. Echaré un vistazo. ¿Por casualidad tendrías a mano un enlace sobre los cambios en la versión 2.6.32 al respecto? Si no, no te preocupes. Lo buscaré.
No estoy seguro de si usted todavía necesita esto, pero he encontrado una entrada de blog que resume la modificación y los cambios resultantes en el comportamiento: http://www.percona.com/blog/20…
Por si ese post desaparece en algún momento, aquí tienes parte de la información del post:
Información de confirmación del código del núcleo:
commit fe35004fbf9eaf67482b074a2e032abb9c89b1dd
Autor: Satoru Moriya
Date: Tue May 29 15:06:47 2012 -0700
mm: evitar el intercambio con swappiness==0
Información del registro de cambios de RHEL:
* Lun Ago 27 2012 Jarod Wilson [2.6.32-303.el6]
…
- [mm] evitar el intercambio con swappiness==0 (Satoru Moriya) [787885]
He estado comprobando internamente y parece que hay cierto debate al respecto. Por lo que he oído, la recomendación sigue siendo establecer swappiness=0, aunque tenemos clientes que han cambiado a 1. Voy a investigar más a fondo y hacer más pruebas.
He oído que sí.
Es más que nada una pregunta del tipo "cómo quieres que falle y con qué rapidez", supongo, y no es una situación que la gente se encuentre a menudo. Esperemos que alguien tenga alarmas relacionadas con el uso de RAM mucho antes de que el kernel se enfrente a la elección de intercambiar o matar a Couchbase :)
Hola,
He seguido su consejo cualquier mi archivo rc.local se parece a esto:
————————————————————–
#!/bin/sh -e
#
# rc.local
#
# Este script se ejecuta al final de cada nivel de ejecución multiusuario.
# Asegúrese de que el script \"exit 0\" en caso de éxito o cualquier otro valor# en caso de error.
#
# Para activar o desactivar este script basta con cambiar la ejecución
Bits #.
#
# Por defecto este script no hace nada.
[ -x /sbin/initctl ] && initctl emit -no-wait google-rc-local-has-run || true
salida 0
if test -f /sys/kernel/mm/transparent_hugepage/enabled; then
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/enabled
fi
if test -f /sys/kernel/mm/transparent_hugepage/defrag; then
echo never | sudo tee /sys/kernel/mm/transparent_hugepage/defrag
fi
——————————————————————————-
Ahora estoy muy verde en linux, pero ¿no significa la salida 0 que nunca llegaría a transparent_hugepage pruebas? Por favor ayudenme a entender/arreglar esto.
Saludos cordiales,
David
[...] Ajustes de Linux que a menudo se pasan por alto [...]