Compartir vía

Ampliación

  • Artículo

Escalado bajo carga

Al escalar una caché bajo carga, configure la opción maxmemory-reserved para mejorar la capacidad de respuesta del sistema. Para obtener más información, consulte Configuración de la opción maxmemory-reserved.

Escalado de clústeres

Intente reducir los datos tanto como pueda en la caché antes de escalar o reducir horizontalmente la caché en clúster. Esta reducción garantiza que se tengan que mover volúmenes más pequeños de datos, lo que a su vez reduce el tiempo necesario para la operación de escalado. Para obtener más información sobre cuándo escalar, consulte Cuándo escalar.

Escalado antes de que la carga sea demasiado alta

Inicie el escalado antes de que la carga o el uso de memoria del servidor sean demasiado altos. Si son demasiado altos, significa que el servidor de Redis está ocupado. Estando ocupado, el servidor de Redis no tiene suficientes recursos para escalar y redistribuir datos.

Tamaños de caché

Si usa TLS y tiene un gran número de conexiones, considere la posibilidad de escalar horizontalmente para poder distribuir la carga entre más núcleos. Algunos tamaños de caché se hospedan en máquinas virtuales con cuatro o más núcleos. Al distribuir las cargas de trabajo en varios núcleos, ayudará a reducir el uso general de la CPU en las máquinas virtuales de caché. Para obtener más información, consulte los detalles sobre los tamaños y núcleos de las máquinas virtuales.

Escalado y memoria

Puede escalar las instancias de caché en el Azure Portal. Además, puede escalar el caché de forma programada mediante los cmdlets de PowerShell, la CLI de Azure y el uso de las bibliotecas de administración de Microsoft Azure (MAML).

Al escalar o reducir verticalmente una caché en el portal, las configuraciones maxmemory-reserved y maxfragmentationmemory-reserved se reducen horizontalmente de manera automática en proporción con el tamaño de la caché. Por ejemplo, si maxmemory-reserved se establece en 3 GB en una caché de 6 GB y se escala a una caché de 12 GB, la configuración se actualiza automáticamente a 6 GB durante el escalado. Al reducir verticalmente, ocurre lo contrario.

Al escalar o reducir verticalmente una caché mediante programación usando PowerShell, CLI o la API REST, se omite maxmemory-reserved o maxfragmentationmemory-reserved como parte de la solicitud de actualización. Solo se respeta el cambio de escalado. Puede actualizar esta configuración de memoria una vez completada la operación de escalado.

Para obtener más información sobre el escalado y la memoria, en función del nivel, vea:

Nota:

Al escalar o reducir verticalmente una memoria caché mediante programación, se omite maxmemory-reserved o maxfragmentationmemory-reserved como parte de la solicitud de actualización. Solo se respeta el cambio de escalado. Puede actualizar esta configuración de memoria una vez completada la operación de escalado.

Minimizar los datos ayuda a escalar más rápido

Si conservar los datos en el caché no es un requisito, considere la posibilidad de vaciar los datos antes del escalado. Vaciar el caché ayuda a que la operación de escalado se complete más rápidamente para que la nueva capacidad esté disponible antes. Puede ver más detalles sobre cómo iniciar una operación de vaciado de datos.

Escalado de cachés de nivel Enterprise

Dado que los niveles Enterprise y Enterprise Flash se basan en Redis Enterprise en lugar de Redis de código abierto, hay algunas diferencias en los procedimientos recomendados de escalado. Consulte Procedimientos recomendados para los niveles Enterprise y Enterprise Flash para más información.

Pasos siguientes