2012-08-09 21 views
6

Necesito ayuda para mejorar el rendimiento de lectura de Cassandra. Me preocupa la degradación del rendimiento de lectura a medida que aumenta el tamaño de la familia de columnas. Tenemos las siguientes estadísticas sobre Cassandra de un solo nodo.Cassandra Amazon EC2, experimentos de rendimiento de lectura

Sistema operativo: Linux - CentOS release 5.4 (final)
Cassandra versión: apache-cassandra-1.1.0
versión de Java: "1.6.0_14" Java (TM) SE Runtime Medio Ambiente (build 1.6.0_14-b08) Java HotSpot (TM) de 64 bits del servidor VM (build 14.0-b16, modo mixto)

configuración Cassandra: (cassandra.yaml)

  • rpc_server_type: hsha
  • disk_access_mode: mmap
  • concurrent_reads: 64
  • concurrent_writes: 32

Plataforma: Amazon-EC2/instancia RightScale m1.Xlarge con 4 discos efímeras con raid0. (15 GB de memoria total, 4 núcleos virtuales, 2 ECU, ECU Total = 8)


configuraciones de experimentación: he tratado de hacer algunos experimentos con GC

Cassandra config:
10 GB RAM se asigna a Cassandra Heap, 3500 MB es de tamaño Heap NEW.

JVM Config:
JVM_OPTS = "$ JVM_OPTS -XX: + UseParNewGC"
JVM_OPTS = "$ JVM_OPTS -XX: + UseConcMarkSweepGC"
JVM_OPTS = "$ JVM_OPTS -XX: + CMSParallelRemarkEnabled"
JVM_OPTS = "$ JVM_OPTS -XX: SurvivorRatio = 1000"
JVM_OPTS = "$ JVM_OPTS -XX: MaxTenuringThreshold = 0"
JVM_OPTS = "$ JVM_OPTS -XX: CMSInitiatingOccupancyFraction = 40"
JVM_OPTS = "$ JVM_OPTS -XX: + UseCMSInitiatingOccupancyOnly -XX: + UseCompressedOops "



estadísticas de Resultados de comunidad OpsCenter 2.0:

solicitudes de lectura de 208 a 240 por segundo
solicitudes de escritura de 18 a 28 por segundo
OS Carga 24,5 a 25.85
de petición de escritura Latencia 127 a 160 micros
de petición de lectura Latencia 82202 a 94612 micros
sistema operativo ha enviado el tráfico de red 44646 KB promedio por Tráfico segundo
OS Recieved Red 4338 KB promedio por segundo Tamaño
OS cola de disco 13 al 15 pide
solicitudes de lectura espera de 25 a 32

OS disco latencia de 48 a 56 ms
OS lectura de disco Throughput 4.6 Mb por segundo
disco OIA Lee 420 por segundo

iowait 80% de la CPU avg

Idle 13% de la CPU avg

Rowcache está desactivado.


La Columna familia
Uno de la familia de la columna que sólo estoy leyendo desde que se crea a través de CLI

create column family XColFam 
with column_type='Standard' 
and comparator = CompositeType(BytesType,IntegerType)';" 

familia Columna SSTable Tamaño = 7,10 GB, conde SSTable = 2

XColFam familia de columnas tiene 59499904 no. de las claves de fila estimadas (la mayoría son utf8 literal con longitud variable, estimada a través de mx4jtools) con columnas de naturaleza delgada, con el valor 0 bytes ..... ahora.

La mayoría de las filas deben tener un número muy pequeño de columnas, tal vez de 1 a 10, con aproximadamente 20 a 30 bytes del primer componente del nombre de la columna y el segundo entero de 8 bytes .... 2. componente de la columna compuesta es dinámico podría repetirse pero la probabilidad es baja ........ El primer componente se repite en las variedades, pero el número de columnas en las filas podría ser diferente.

He intentado SnappyCompression comprimir la familia de columnas pero no hubo cambios en el tamaño.

que tienen un servicio regular que se ejecutan durante horas con 20 hilos y hacer peticiones de lectura aleatorias para múltiples claves (por ahora sus 2 llaves por petición) a esta familia de columnas y filas completas leer, sin rebanada columna o

etc.

Creo que no está funcionando bien ahora porque procesa muy pocas solicitudes por minuto. Antes estaba funcionando mejor cuando el tamaño de la familia de columnas no era tan grande. Fue alrededor de 3 a 4 GB.

Me temo que el rendimiento de lectura se degrada demasiado rápido con el aumento en el tamaño de la familia de columnas.

También intenté ajustar algunas cosas de GC y memoria, porque antes tenía mucho uso de GC y CPU. Cuando el tamaño de los datos era más pequeño y había muy poco tiempo de espera en la forma de onda.


Cómo puedo aumentar el rendimiento de Cassandra. Tus sugerencias serán apreciadas.

+0

Latencia de lectura de lectura 82202 a 94612 micros ... 82 segundos de latencia? – Crowie

Respuesta

0

Mirar a cassandra es dependiente de E/S relativa. Las instancias de CE tienen E/S "insuficientes" por diseño (virtualización Xen) Y mi primera recomendación es usar Cassandra en hardware real, donde usted tiene un control. Por ejemplo, puede usar discos SSD para CommitLog. Mira Cassandra hardware proposals.

Sin embargo, cambiar a hardware propio es una opción un poco radical. Para mantenerse con Amazon tratar EBS

Amazon Elastic Block Store (EBS) proporciona volúmenes de almacenamiento a nivel de bloque para su uso con instancias de Amazon EC2. Los volúmenes de Amazon EBS son conectados a la red y persisten independientemente de la duración de una instancia de . Amazon EBS proporciona volúmenes de almacenamiento predecibles de alta disponibilidad y muy confiables que se pueden conectar a una instancia de Amazon EC2 y exponerlos como un dispositivo dentro de la instancia. Amazon EBS es especialmente adecuado para aplicaciones que requieren una base de datos, archivo sistema o acceso al almacenamiento de nivel de bloque sin formato.

Amazon EBS le permite crear volúmenes de almacenamiento de 1 GB a 1 TB que las instancias de Amazon EC2 pueden montar como dispositivos. Se pueden montar varios volúmenes en la misma instancia. Amazon EBS le permite aprovisionar un nivel específico de rendimiento de E/S si lo desea, seleccionando un volumen de IOPS aprovisionado. Esto le permite escalar predeciblemente a miles de IOPS por instancia de Amazon EC2.

También puedes ver Cassandra Performance Testing on EC2

+0

Las instancias de Ephermal ec2 por naturaleza serían más rápidas que EBS y sin RAID10 serían susceptibles a las burbujas de EBS (bloqueos o tiempos de espera). Dicho esto, las instancias fi * con instancias SSD son exponencialmente más rápidas – David

+0

@David en ec2 incluso la "naturaleza" está virtualizada;) Pero tienes razón. Son rápidos y tienen un mejor rendimiento. Pero EBS RAID se comporta mejor con un rendimiento de búsqueda aleatorio [Comparado aquí] (http://victortrac.com/blog/2010/01/02/ec2-ephemeral-disks-vs-ebs-volumes-in-raid/). Esto podría ser más valioso para el rendimiento general de Cassandra. – aholbreich

0

respuesta corta: Fila caché y Key cachés.

Si sus datos contienen subconjuntos que se leerán con frecuencia como la mayoría de los sistemas, intente utilizar cachés de filas y cachés de claves.

Caché de filas es una memoria caché, que almacena las filas que se leen con frecuencia en la memoria. Tenga en cuenta que esto puede no tener el efecto deseado si sus datos están dispersos.

Las memorias caché de claves son generalmente más adecuadas, ya que solo almacena las claves de partición y sus desplazamientos en el disco. Esto generalmente ayudará a omitir una búsqueda por Cassandra (no es necesario usar índices de partición y resúmenes de partición).

Intente habilitar la memoria caché de claves con el espacio de claves y la tabla y compruebe su rendimiento.