En esta página, se proporciona orientación sobre el uso óptimo de Memorystore para Valkey. También se muestran posibles problemas que debes evitar.
Recomendaciones para la administración de memoria
En esta sección, se describen estrategias para administrar la memoria de la instancia de modo que Memorystore para Valkey funcione de manera eficiente para 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. La carga de escritura puede variar de normal a muy alta 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.
Supervisa una instancia que tiene una carga de escritura normal
Consulta la métrica /instance/cpu/maximum_utilization. Si /instance/cpu/maximum_utilization está al 100% o menos, tu instancia de Valkey tiene 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 la 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 experimentar 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.
Escalamiento de fragmentos
Cuando escalas la cantidad de fragmentos en una instancia, debes realizar la escala 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 claves, el escalamiento a un tamaño de instancia más pequeño puede reducir tu porcentaje de aciertos de la 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, debes aprovisionar suficientes fragmentos para 1.5 veces la cantidad de datos que tienes 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. El uso de dos réplicas por fragmento (en lugar de una) 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:
- Para instancias con 1 réplica por nodo, debes establecer un valor de
/instance/cpu/maximum_utilizationde 0.5 segundos para la instancia principal y la réplica. - Para instancias con 2 réplicas por nodo, debes establecer un valor de
/instance/cpu/maximum_utilizationde 0.9 segundos para la instancia principal y de 0.5 segundos para las réplicas.
Si los valores de la métrica superan estas recomendaciones, te recomendamos que aumentes 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
- TODO
Comandos que bloquean la ejecución de una secuencia de comandos
- EVAL
- EVALSHA
Riesgos de usar comandos costosos
- Latencia alta y tiempos de espera del cliente agotados.
- Presión de la memoria causada por comandos que aumentan el uso de la 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 agotadas.
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 conscientes de clústeres y configuraciones de muestra, consulta Muestras de código de bibliotecas 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 los intervalos y los nodos asignados en las siguientes situaciones:
Cuando se inicializa el cliente, debe propagar la asignación inicial de ranuras a nodos.
Cuando se recibe una redirección
MOVEDdel servidor, como en la situación de una conmutación por error cuando la réplica toma el control de todos los espacios que entregaba el nodo principal anterior, o cuando se vuelve a particionar cuando los espacios se mueven del nodo principal de origen 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 un descender de nivel a réplica.Además, los clientes deben actualizar periódicamente la topología para mantener los clientes preparados para cualquier cambio y obtener información sobre los cambios que pueden no generar redireccionamientos o 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 manejar 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), ya que 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 amplia. 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 un momento determinado (y almacenen en caché el resultado en la memoria) y que la cantidad de clientes que realizan 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 la detección del nodo, un error común es que la aplicación cliente realiza varias solicitudes de reconexión y descubrimiento sin agregar una retirada exponencial tras reintentar. Esto puede hacer que el servidor de Valkey no responda durante un período prolongado, lo que causará un uso de CPU muy alto.
Evita la sobrecarga de descubrimiento en Valkey
Para mitigar el impacto causado por una afluencia repentina de solicitudes de conexión y descubrimiento, 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 retirada exponencial con jitter. Esto ayuda a evitar que varios clientes abrumen al servidor al mismo tiempo.
Usa el extremo de descubrimiento de Memorystore para Valkey para realizar el descubrimiento de nodos. 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 usada de los nodos aumenta a medida que se copian las páginas que tocaron las escrituras. En el peor de los casos, la huella de 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, junto con las instantáneas de Monitoring, te ayuda a administrar la carga de trabajo para tener instantáneas correctas.
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 de las instantáneas de RDB en el rendimiento
Según el patrón de carga de trabajo, las instantáneas de la RDB pueden afectar el rendimiento de la instancia y aumentar la latencia de tus aplicaciones. Para minimizar el impacto en el rendimiento de las instantáneas de RDB, puedes programarlas para que se ejecuten durante períodos de bajo tráfico de instancias si te sientes cómodo con las instantáneas menos frecuentes.
Por ejemplo, si tu instancia tiene poco tráfico de 1 a.m. a 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 cuidadosamente 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 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 dentro de una sola zona, la probabilidad de que una interrupción zonal afecte a tu servidor disminuye del 100% al 33%. Esto se debe a que hay un 33% de probabilidad de que la zona donde de la instancia de Cloud SQL falla, a diferencia del 100% de probabilidades de que los nodos ubicados la zona no disponible se ven afectadas.
Recuperación rápida
Si se produce una interrupción zonal, la recuperación se optimiza. Puedes responder rápidamente aprovisionar una instancia nueva en una zona funcional y redireccionar para operaciones con interrupciones mínimas.