amazon-ec2 - pricing - elasticache redis
Mejor configuración de EC2 para servidor redis (1)
Estamos implementando una aplicación web a gran escala que utiliza solo redis como un almacén de datos. Noté que el punto de referencia de nuestro redis master es de aproximadamente 8000 transacciones por segundo en EC2, mucho menos que los puntos de referencia establecidos en hardware dedicado.
Entiendo que hay una penalización en el rendimiento por ejecutar Redis en una máquina virtual como EC2, pero me encantarían algunos consejos de personas que han implementado Redis en entornos de producción en EC2 en la configuración de EC2 que ha encontrado más efectiva para obtener más de redis. .
Gracias.
EC2 probablemente no sea el mejor entorno para ejecutar Redis en hardware virtualizado, pero es popular, y hay varios puntos que debe saber para obtener lo mejor de Redis en esta plataforma.
Soy uno de los autores de http://redis.io/topics/benchmarks y redis.io/topics/latency que cubren la mayoría de los temas que presento a continuación. Esto es sólo un resumen de los puntos principales.
Peaje de virtualizacion
No es específico de EC2, pero Redis es significativamente más lento cuando se ejecuta en una máquina virtual (en términos de rendimiento máximo admitido). Esto se debe al hecho de que para operaciones básicas, Redis no agrega mucha sobrecarga a las llamadas del sistema epoll / read / write requeridas para manejar las conexiones del cliente (como memcached, u otros almacenes clave / valor eficientes). Las llamadas al sistema suelen ser más caras en una máquina virtual y representan una parte importante de la actividad de Redis (especialmente en los puntos de referencia). En esas condiciones, una disminución del 50% en el término de rendimiento máximo en comparación con el metal puro no es infrecuente.
Por supuesto, también depende de la calidad del hipervisor. Para EC2, se utiliza Xen.
Benchmarking en buenas condiciones.
La evaluación comparativa puede ser complicada, especialmente en una plataforma como EC2. Un punto a menudo olvidado es garantizar una configuración adecuada tanto para el cliente como para el servidor de referencia. Por ejemplo, no ejecute redis-benchmark en una micro-instancia carente de CPU (que probablemente Amazon reducirá su velocidad) mientras se dirige a su servidor Redis. Ambas máquinas son igualmente importantes para obtener un buen rendimiento máximo.
En realidad, para evaluar el desempeño de Redis, necesitas:
ejecute redis-benchmark localmente (en la misma máquina que el servidor), asumiendo que tiene más de un núcleo vCPU.
ejecutar redis-benchmark de forma remota (desde una máquina virtual diferente), en una máquina cuya configuración de 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 instancias de computación en clúster o de alta memoria), por lo que puede beneficiarse de HVM (virtualización de hardware) en lugar de depender de la virtualización más lenta para.
El problema de la horquilla
Esto no es específico de EC2, pero para Xen: forking un proceso grande puede ser realmente lento en Xen (se ve mejor con kvm). Para Redis, esto es un gran problema si planea usar la persistencia: ambas opciones de persistencia (RDB o AOF) requieren que el hilo principal se bifurque y lance los procesos de guardado o reescritura en segundo plano.
En algunos casos, la latencia de la horquilla puede congelar el bucle de eventos Redis durante varios segundos. Cuanta más memoria administre la instancia de Redis, mayor será la latencia.
En EC2, asegúrese de utilizar una instancia habilitada para HVM (M3, memoria alta, clúster), mitigará el problema.
Luego, si tiene grandes requisitos de memoria y su aplicación puede tolerarla, 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 de persistencia
Este es un punto clave para obtener un buen rendimiento de Redis (tanto en VM como en bare metal). Así que por favor tómese el tiempo para leer cuidadosamente http://redis.io/topics/persistence
Si utiliza RDB, tenga en cuenta que el mecanismo de copia en escritura de la memoria comenzará a duplicar las páginas una vez que el proceso de guardado en segundo plano haya sido descifrado. Por lo tanto, debe asegurarse de que haya suficiente memoria para el propio Redis, además de un margen para hacer frente al COW. la cantidad de memoria adicional depende de su carga de trabajo. Cuanto más escriba en la instancia, más memoria extra necesitará.
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 un guardado de fondo Redis, debe tener en cuenta la memoria Redis, la sobrecarga de COW y el tamaño del archivo volcado.
La máquina que ejecuta el servidor Redis nunca debe intercambiarse. Si lo hace, el resultado será catastrófico. Al contrario de otras tiendas, Redis no es compatible con la memoria virtual.
Con Linux, asegúrese de establecer parámetros de sistema sensibles: vm.overcommit_memory = 1 y vm.swappiness = 0 (o un valor muy bajo de todos modos). No use las versiones antiguas del kernel: son bastante malas para imponer una baja swappiness (lo que resulta en un intercambio cuando se escribe un archivo grande).
Si usa AOF, revise las opciones de fsync. Es una compensación entre el rendimiento en bruto 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 de EC2. En algunas máquinas virtuales, puede elegir entre almacenamiento efímero y EBS. En algunos otros, solo tienes EBS.
El almacenamiento efímero generalmente es 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 reinicio del host, etc. Puede imaginar imágenes de RDB en almacenamiento efímero, y luego, copiando los archivos resultantes a los directorios de EBS, como una compensación entre el rendimiento y la solidez.
EBS es un almacenamiento remoto: puede consumir el ancho de banda de red estándar asignado a la VM, y afectar el rendimiento máximo de Redis. Si planea usar EBS, considere seleccionar la opción "optimizada para EBS" para establecer una QoS entre la red estándar y los enlaces de almacenamiento.
Finalmente, una configuración muy común para instancias exigentes de rendimiento con EC2 es desactivar la persistencia en el maestro y solo activarla en una instancia esclava. Probablemente sea menos seguro para los datos, pero puede prevenir muchos problemas potenciales de latencia en el maestro.