En esta página, se proporciona orientación sobre el uso óptimo de Memorystore para Valkey. En esta página, también se indican los posibles problemas que debes evitar.
Recomendaciones para la administración de memoria
En esta sección, se describen estrategias para administrar la memoria de instancias a fin de que Memorystore for Valkey funcione de manera eficiente en tu aplicación.
Conceptos de administración de memoria
Carga de escritura: El volumen y la velocidad a los que se agregan o actualizan claves en tu instancia de Valkey. Tu carga de escritura puede variar de normal a muy alto según tu caso de uso de Valkey y los patrones de uso de la aplicación.
Política de expulsión: Memorystore for Valkey usa la política de expulsión
volatile-lru. Puedes usar comandos de Valkey, como el comando EXPIRE, para establecer expulsiones de llaves.
Supervisar una instancia que tiene una carga de escritura normal
Consulta la métrica /instance/cpu/maximum_utilization. Si /instance/cpu/maximum_utilization es
al 100% o menos, tu instancia de Valkey tendrá un buen rendimiento cuando usas una carga de escritura normal.
Sin embargo, si tu uso de memoria se acerca al 100% y esperas que el uso de datos aumente, Debería escalar verticalmente el tamaño de su instancia para liberar espacio para los datos nuevos.
Supervisa una instancia que tiene una carga de escritura alta
Consulta la métrica /instance/memory/maximum_utilization. Según la gravedad de tu carga de escritura alta, tu instancia puede experimentar problemas de rendimiento en los siguientes umbrales:
Las cargas de escritura muy altas pueden experimentar problemas si
/instance/memory/maximum_utilizationalcanza el 65% o más.Las cargas de escritura moderadamente altas pueden tener problemas si
/instance/memory/maximum_utilizationalcanza el 85% o más.
En estas situaciones, debes escalar verticalmente el tamaño de la instancia para mejorar el rendimiento.
Si tienes problemas o te preocupa que tu instancia tenga una carga de escritura alta, comunícate con Asistencia de Google Cloud.
Escalar fragmentos
Cuando escalas la cantidad de fragmentos en una instancia, debes escalar durante períodos de escrituras bajas. El escalamiento durante períodos de carga de escritura alta puede ejercer presión de memoria en tu instancia debido a la sobrecarga de memoria causada por la replicación o la migración de ranuras.
Si tu caso de uso de Valkey usa expulsiones de clave, escalar a un tamaño de instancia más pequeño puede reducir la tasa de aciertos de caché. Sin embargo, en esta circunstancia, no debes preocuparte por perder datos, ya que se espera una expulsión de clave.
Para los casos de uso de Valkey en los que no quieres perder claves, solo debes reducir la escala verticalmente a una instancia más pequeña que aún tenga espacio suficiente para tus datos. Tu nuevo recuento de fragmentos objetivo debería permitir al menos 1.5 veces la memoria que usan los datos. En otras palabras, deberías aprovisionar suficientes fragmentos para 1.5 veces la cantidad de datos que hay actualmente en tu instancia. Puedes usar la métrica /instance/memory/total_used_memory para ver cuántos datos se almacenan en tu instancia.
Prácticas recomendadas sobre el uso de la CPU
Si se produce una interrupción zonal inesperada, se reducen los recursos de CPU para tu instancia debido a la pérdida de capacidad de los nodos en la zona no disponible. Te recomendamos que uses instancias de alta disponibilidad. Usar dos réplicas por fragmento (en lugar de una réplica por fragmento) proporciona recursos de CPU adicionales durante una interrupción. Además, recomendamos administrar el uso de CPU del nodo, de modo que los nodos tengan suficiente sobrecarga de CPU para manejar el tráfico adicional de la capacidad perdida si se produce una interrupción zonal inesperada. Debes supervisar el uso de CPU de las instancias principales y réplicas con la métrica Segundos de la CPU del subproceso principal /instance/cpu/maximum_utilization.
Según la cantidad de réplicas que aprovisiones por nodo, te recomendamos los siguientes objetivos de uso de CPU de /instance/cpu/maximum_utilization:
- En el caso de las instancias con 1 réplica por nodo, debes tener como objetivo un valor de
/instance/cpu/maximum_utilizationde 0.5 segundos para la instancia principal y la réplica. - En el caso de las instancias con 2 réplicas por nodo, debes tener como objetivo un valor de
/instance/cpu/maximum_utilizationde 0.9 segundos para la principal y 0.5 segundos para las réplicas.
Si los valores de la métrica superan estas recomendaciones, te recomendamos que escales verticalmente la cantidad de fragmentos o réplicas en tu instancia.
Comandos de Valkey costosos de la CPU
Debes evitar los comandos de Valkey que son costosos de ejecutar por varios motivos. En esta sección, se dan ejemplos de las razones por las cuales algunos comandos son costosos, pero no es exhaustiva.
Comandos que operan en todo el espacio de claves
- KEYS
Comandos que operan en un conjunto de claves de longitud variable
- LRANGE
- ZRANGE
- HGETALL
Comandos que bloquean la ejecución de una secuencia de comandos
- EVALUACIÓN
- EVALSHA
Riesgos de usar comandos costosos
- Latencia alta y tiempos de espera del cliente agotados.
- Presión de memoria causada por comandos que aumentan el uso de memoria.
- Pérdida de datos durante la replicación y sincronización de nodos debido al bloqueo del subproceso principal de Valkey.
- Verificaciones de estado, observabilidad y replicación desfavorecidas.
Prácticas recomendadas para el cliente de Valkey
Tu aplicación debe usar un cliente de Valkey con reconocimiento del clúster cuando se conecte a una instancia de Memorystore para Valkey. Para ver ejemplos de clientes con reconocimiento de clústeres y configuraciones de muestra, consulta Muestras de código de biblioteca cliente. Tu cliente debe mantener un mapa de ranuras de hash para los nodos correspondientes de la instancia para enviar solicitudes a los nodos correctos y evitar la sobrecarga de rendimiento causada por los redireccionamientos.
Asignación de clientes
Los clientes deben obtener una lista completa de las ranuras y los nodos asignados en la las siguientes situaciones:
Cuando se inicializa el cliente, debe propagar la ranura inicial en los nodos la asignación.
Cuando se recibe un redireccionamiento
MOVEDdel servidor, como en esta situación de una conmutación por error cuando se ocupan todas las ranuras que entrega el nodo principal anterior que realiza la réplica o volver a fragmentar cuando se mueven las ranuras desde la fuente primario al nodo principal de destino.Cuando se recibe un error
CLUSTERDOWNdel servidor o las conexiones a un servidor en particular se agotan de forma persistente.Cuando se recibe un error
READONLYdel servidor. Esto puede ocurrir cuando se cambia el estado de una instancia principal a réplica.Además, los clientes deben actualizar la topología de forma periódica para mantenerlos preparados para detectar cualquier cambio y conocer los cambios que no resulten en redireccionamientos. errores del servidor, como cuando se agregan nuevos nodos de réplica. Ten en cuenta que las conexiones inactivas también deben cerrarse como parte de la actualización de la topología para reducir la necesidad de controlar las conexiones fallidas durante el tiempo de ejecución del comando.
Descubrimiento de clientes
Por lo general, el descubrimiento de clientes se realiza mediante la emisión de un comando SLOTS, NODES o CLUSTER SHARDS al servidor de Valkey. Te recomendamos que uses el comando CLUSTER SHARDS. CLUSTER SHARDS reemplaza el comando SLOTS (obsoleto) y proporciona una representación más eficiente y extensible de la instancia.
El tamaño de la respuesta para los comandos de detección del cliente puede variar según el tamaño y la topología de la instancia. Las instancias más grandes con más nodos producen una respuesta más grande. Como resultado, es importante asegurarse de que la cantidad de clientes que realizan el descubrimiento de la topología de nodo no aumente de forma ilimitada.
Estas actualizaciones de topología de nodo son costosas en el servidor de Valkey, pero también son importantes para la disponibilidad de la aplicación. Por lo tanto, es importante asegurarse de que cada cliente realice una sola solicitud de descubrimiento en cualquier momento (y que los cachés den como resultado la memoria) y que la cantidad de clientes que hagan las solicitudes se mantenga limitada para evitar sobrecargar el servidor.
Por ejemplo, cuando la aplicación cliente se inicia o pierde la conexión con el servidor y debe realizar el descubrimiento de nodos, un error común es que la aplicación cliente realiza varias solicitudes de reconexión y descubrimiento sin agregar una retirada exponencial cuando se vuelve a intentar. Esto puede hacer que el servidor de Valkey no responda durante un período prolongado, lo que causa un uso muy alto de la CPU.
Evita la sobrecarga de descubrimiento en Valkey
Para mitigar el impacto causado por una afluencia repentina de conexiones y descubrimientos solicitudes, te recomendamos lo siguiente:
Implementa un grupo de conexiones de clientes con un tamaño limitado y pequeño para limitar la cantidad de conexiones entrantes simultáneas del cliente y mantener la integridad de su aplicación.
Cuando el cliente se desconecta del servidor debido al tiempo de espera, vuelve a intentarlo con una retirada exponencial con jitter. Esto ayuda a evitar que varios clientes abrumen al servidor al mismo tiempo.
Usar el extremo de descubrimiento de Memorystore for Valkey para ejecutar tareas de descubrimiento. El extremo de descubrimiento tiene alta disponibilidad y tiene balanceo de cargas en todos los nodos de la instancia. Además, el extremo de descubrimiento intenta para enrutar las solicitudes de descubrimiento de nodos a los nodos con vista de topología única.
Prácticas recomendadas sobre la persistencia
En esta sección, se explican las prácticas recomendadas para la persistencia.
Persistencia de RDB
Para obtener los mejores resultados cuando crees una copia de seguridad de tu instancia con instantáneas de RDB, debes seguir las siguientes prácticas recomendadas:
Administración de la memoria
Las instantáneas de RDB usan una bifurcación de proceso y “copia en escritura” mecanismo para tomar una instantánea de los datos del nodo. Según el patrón de escrituras en los nodos, la memoria utilizada de los nodos crece a medida que se copian las páginas que tocan las escrituras. En el peor de los casos, el espacio en memoria puede ser el doble del tamaño de los datos en el nodo.
A fin de garantizar que los nodos tengan suficiente memoria para completar la instantánea, debes mantener o configurar maxmemory al 80% de la capacidad del nodo, de modo que se reserve el 20% para la sobrecarga. Consulta Supervisa una instancia que tiene una carga de escritura alta para obtener más información. Esta sobrecarga de memoria, además de supervisar las instantáneas, te ayuda a administrar tu carga de trabajo para tener instantáneas exitosas.
Instantáneas inactivas
Recuperar nodos de una instantánea inactiva puede causar problemas de rendimiento para tu aplicación, ya que intenta conciliar una cantidad significativa de claves inactivas o algún otro cambio en tu base de datos, como un cambio de esquema. Si te preocupa recuperarte de una instantánea inactiva, puedes inhabilitar la función de persistencia de RDB. Una vez que vuelvas a habilitar la persistencia, se tomará una instantánea en el siguiente intervalo programado.
Impacto en el rendimiento de las instantáneas de RDB
Según el patrón de tu carga de trabajo, las instantáneas de RDB pueden afectar el rendimiento de la instancia y aumentar la latencia de tus aplicaciones. Puedes minimizar el impacto en el rendimiento de las instantáneas de RDB si las programas para que se ejecuten durante períodos de bajo tráfico de instancias si te sientes cómodo con este tipo de instantáneas.
Por ejemplo, si tu instancia tiene poco tráfico desde la 1 a.m. hasta las 4 a.m., puedes establecer la hora de inicio en 3 a.m. y el intervalo en 24 horas.
Si tu sistema tiene una carga constante y requiere instantáneas frecuentes, debes evaluar con cuidado el impacto en el rendimiento y sopesar los beneficios de usar instantáneas de RDB para la carga de trabajo.
Elige una instancia de una sola zona si tu instancia no usa réplicas
Cuando configures una instancia sin réplicas, recomendamos una arquitectura de una sola zona para mejorar la confiabilidad. Esto se debe a los siguientes motivos:
Minimiza el impacto de la interrupción
Es menos probable que las interrupciones zonales afecten a tu instancia. Si colocas todos los nodos en una sola zona, disminuye la posibilidad de que se produzca una interrupción zonal de 100% a 33%. Esto se debe a que existe una probabilidad del 33% de que la zona en la que se encuentra tu instancia deje de estar disponible, en comparación con el 100% de probabilidad de que los nodos ubicados en la zona no disponible se vean afectados.
Recuperación rápida
Si se produce una interrupción zonal, se optimiza la recuperación. Para responder, puedes aprovisionar rápidamente una instancia nueva en una zona en funcionamiento y redireccionar tu aplicación para que las operaciones se interrumpan lo menos posible.