EC2 probablemente no sea el mejor entorno para ejecutar Redis en hardware virtualizado, pero es muy popular, y hay una serie de puntos que debe saber para sacar lo mejor de Redis en esta plataforma.
Soy uno de los autores de http://redis.io/topics/benchmarks y http://redis.io/topics/latency que cubren la mayoría de los temas que presento a continuación. Esto es solo un resumen de los puntos principales.
peaje virtualización
No es específico para EC2, pero Redis es significativamente más lento cuando se ejecuta en una máquina virtual (en términos de máxima soportada rendimiento). Esto se debe al hecho de que para las operaciones básicas, Redis no agrega mucha sobrecarga a las llamadas al sistema epoll/lectura/escritura requeridas para manejar las conexiones del cliente (como memcached, u otras tiendas de clave/valor eficientes). Las llamadas al sistema generalmente son más costosas en una máquina virtual y representan una parte importante de la actividad de Redis (especialmente en los puntos de referencia). En esas condiciones, no es infrecuente una disminución del 50% del plazo de rendimiento máximo en comparación con el metal desnudo.
Por supuesto, también depende de la calidad del hipervisor. Para EC2, se usa Xen.
Benchmarking en buenas condiciones
evaluación comparativa puede ser difícil, especialmente en una plataforma como EC2. Un punto que a menudo se olvida es garantizar una configuración adecuada tanto para el cliente de referencia como para el servidor. Por ejemplo, no ejecute redis-benchmark en una microinstancia de CPU (que probablemente Amazon acelerará) mientras apunta a su servidor Redis. Ambas máquinas son igualmente importantes para obtener un buen rendimiento máximo.
En realidad, para evaluar el desempeño Redis, es necesario:
plazo Redis del índice de referencia a nivel local (en la misma máquina que el servidor), suponiendo que tiene más de un núcleo CPU virtual.
ejecución Redis del índice de referencia remota (desde un diferente VM), en una máquina cuya configuración QoS es equivalente a la máquina del servidor
para que pueda evaluar y comparar el rendimiento de las máquinas y la red.
En EC2, obtendrá los mejores resultados con instancias M3 de segunda generación (o alta memoria o instancias informáticas de clúster) para que pueda beneficiarse de HVM (virtualización de hardware) en lugar de depender de una paravirtualización más lenta.
La cuestión tenedor
Esto no es específico de EC2, pero a Xen: bifurcar un proceso de gran tamaño puede ser muy lento en Xen (que se ve mejor con KVM). Para Redis, este es un gran problema si planea usar persistencia: ambas opciones de persistencia (RDB o AOF) requieren que el hilo principal se bifurque e inicien procesos de fondo para guardar o reescribir.
En algunos casos, la latencia de la horquilla puede congelar el bucle de eventos de Redis durante varios segundos. Cuanta más memoria maneje la instancia de Redis, más latencia.
En EC2, asegúrese de utilizar una instancia habilitada HVM (M3, memoria alta, clúster), se mitigará el problema.
Luego, si tiene requisitos de memoria grandes, y su aplicación puede tolerarlo, considere ejecutar varias instancias de Redis más pequeñas en la misma máquina y fragmentar sus datos. Puede disminuir la latencia debido a las operaciones de la horquilla a un nivel aceptable.
configuración Persistencia
Este es un punto clave para obtener un buen rendimiento de Redis (tanto en VM y el metal desnudo). Por lo tanto, tómese el tiempo para leer cuidadosamente http://redis.io/topics/persistence
Si usa RDB, tenga en cuenta que el mecanismo de copia de escritura empezará a duplicar páginas una vez que se haya ahorrado el proceso de guardar el fondo. Por lo tanto, debe asegurarse de que haya suficiente memoria para Redis, más algún margen para hacer frente a la VOCACIÓN. la cantidad de memoria adicional depende de su carga de trabajo. Cuanto más se escribe en la instancia, más memoria extra necesita.
Tenga en cuenta que escribir un archivo también puede consumir algo de memoria (debido a la memoria caché del sistema de archivos), por lo que durante el almacenamiento de fondo Redis necesita contar la memoria Redis, la sobrecarga COW y el tamaño del archivo de volcado.
La máquina que ejecuta el servidor Redis nunca debe cambiar. Si lo hace, el resultado será catastrófico. A diferencia de otras tiendas, Redis no es compatible con la memoria virtual.
Con Linux, asegúrese de establecer los parámetros del sistema razonables: vm.overcommit_memory = 1 y vm.swappiness = 0 (o un valor muy bajo de todos modos). No use versiones antiguas de kernel: son bastante malas para imponer un bajo swappiness (lo que resulta en el intercambio cuando se escribe un archivo grande).
Si usa AOF, revise las opciones de fsync. Es una compensación entre el rendimiento crudo y la durabilidad de las operaciones de escritura. Necesitas hacer una elección y definir una estrategia.
También debe familiarizarse con las opciones de almacenamiento EC2. En algunas máquinas virtuales, puede elegir entre almacenamiento efímero y EBS. En algunos otros, solo tienes EBS.
El almacenamiento efímero es generalmente más rápido, y es probable que tenga menos problemas que con EBS, pero puede perder fácilmente sus datos en caso de fallo del disco o reiniciar el host, etc ... Puede imaginarse poner instantáneas RDB en almacenamiento efímero, y luego copiar los archivos resultantes a los directorios de EBS, como una compensación entre el rendimiento y la solidez.
EBS es almacenamiento remoto: puede consumir el ancho de banda de red estándar asignado a la máquina virtual e impactar el rendimiento máximo de Redis. Si planea usar EBS, considere seleccionar la opción "EBS optimizada" para establecer una QoS entre la red estándar y los enlaces de almacenamiento.
Finalmente, una configuración muy común para las instancias exigentes de rendimiento con EC2 es desactivar la persistencia en el maestro, y solo activarlo en una instancia esclava. Probablemente sea menos seguro para los datos, pero puede evitar una gran cantidad de posibles problemas de latencia en el maestro.
¿Cuál es el tipo de instancia de EC2 que ha comparado? ¿De qué máquina ejecutó el punto de referencia? ¿Dónde estaba ubicado? ¿Cuál fue el rendimiento (CPU, promedio de carga, utilización de memoria, tráfico de red) como * ambos * los servidores (redis y ejecutando el punto de referencia)? Por último, ¿cuál fue la tasa de IO de disco en el servidor redis? –
Puede que desee echarle un vistazo a esto: http://redis.io/topics/latency El artículo también habla sobre entornos virtualizados, el hipervisor XEN y EC2 –
Considere usar elasticache para redes gestionadas: https: //aws.amazon. com/elasticache/ – JDiMatteo