En esta entrada de blog obtendrás una visión general de dos optimizaciones de rendimiento relacionadas que puedes hacer para Couchbase 2.5.1 e inferiores. Esto no es para 3.x por razones que puedes leer al final de este post. Los dos cambios afectan directamente al rendimiento de lectura y escritura en Couchbase. También debes saber que debes tener un cluster de tamaño adecuado antes de empezar a jugar con estos ajustes. Si no lo haces, puedes causar más problemas al cluster de los que resuelves. Si necesitas más información sobre el tamaño de tu cluster, por favor mira La excelente serie de blogs de Perry sobre el tema.
Añadir más hilos de lectura/escritura por cubo
La primera es cambiar el número de hilos disponibles por cubo. Esto sólo debería hacerse si tienes suficientes recursos de servidor/instancia para ello. Si estás ejecutando sólo 4 núcleos en tus nodos Couchbase, esta no es probablemente la mejora de rendimiento para ti. Esta configuración permitirá a Couchbase utilizar más hilos de lectura/escritura y por lo tanto empujar más operaciones. Así que en la configuración de cada cubo verá una parte de esa pantalla que se parece a esto:
Más optimización para cargas de trabajo de uso mixto o escritura intensiva
La segunda optimización está relacionada con la primera. Tiene que ver con la optimización de Couchbase para lectura, escritura o ambas. Por defecto, Couchbase está optimizado para hilos de lectura y para muchos casos de uso, funciona muy bien. Si tienes un caso de uso mixto o de escritura pesada, querrás optimizar Couchbase para eso. Puedes cambiar estos valores con una llamada a la API REST como la siguiente con wget:
wget -O- -user= -password= -post-data='ns_bucket:update_bucket_props("", [{extra_config_string, "workload_optimization=mix"}]).'. http://localhost:8091/diag/eval
La tercera opción consiste en ponderar los hilos a favor de los escritores:
wget -O- -user= -password= -post-data='ns_bucket:update_bucket_props("", [{extra_config_string, "workload_optimization=write"}]).'. http://localhost:8091/diag/eval
Si quieres volver a poner esto por defecto, lo harías:
wget -O- -user= -password= -post-data='ns_bucket:update_bucket_props("", [{extra_config_string, "workload_optimization=read"}]).'. http://localhost:8091/diag/eval
Nota: Todos los cambios anteriores REQUIEREN un reinicio del cubo para que surtan efecto. Esta es una de las pocas operaciones off-line en CB. Por lo tanto no ¡¡¡cambiar esto en tu cluster de producción sin una ventana de mantenimiento planificada y tiempo de inactividad planificado!!! Para cambiar el número de hilos, Couchbase reiniciará el bucket una vez lo hayas guardado. Para las llamadas REST, tendrás que hacerlo manualmente. En cualquier caso, planifica adecuadamente el tiempo de inactividad.
Para más información consulte la documentación oficial.
¿Sigue siendo necesario para Couchbase 3.0?
No. Estas optimizaciones ya no son necesarias en 3.x debido a la introducción de una característica llamada Global Thread Pool. Con esa característica, Couchbase ahora gestiona el número de hilos y el balance de hilos dinámicamente para ti y con inteligencia en cuanto a tu carga de trabajo.
Esto requiere reiniciar el cubo para que surta efecto. La comprobación con el comando cbstats no muestra el parámetro actualizado hasta después del reinicio. Ejemplo:
Por defecto 2.5.1:
/opt/couchbase/bin/cbstats localhost:11210 raw workload -b bucket -p password
ep_workload:num_readers: 4
ep_workload:num_shards: 4
ep_workload:num_writers: 2
ep_workload:política: Optimizado para el acceso a datos de lectura
Después de reiniciar:
/opt/couchbase/bin/cbstats localhost:11210 raw workload -b bucket -p password
ep_workload:num_readers: 3
ep_workload:num_shards: 5
ep_workload:num_writers: 5
ep_workload:política: Optimizado para el acceso a datos de escritura
Sí, bien visto. La parte en la que digo lo del reinicio debe ir al final del artículo. Arreglaré el artículo.
Sí, bien visto. La parte en la que digo lo del reinicio debe ir al final del artículo. Lo arreglaré.