EDITAR: No puedo lograr que mi instancia de AWS hs1.8xlarge ofrezca IO de alto rendimiento desde suunidades locales 24. Por favor, no me digas cómo hacer que los volúmenes de EBS sean más rápidos.
Contexto: Después de ejecutar durante un par de años y con gran éxito la edición 4.0.4.0 de un solo nodo de Greenplum en una instancia de Amazon cc1.4xlarge (llamémosla gp), pensé que sería realmente bueno aprovechar la instancia hs1.8xlarge. y sus 24 discos duros (48 TB sin formato) montados localmente, además de 120 GB de RAM. Llamemos a esta nueva configuración hsgp.
En gp, había montado volúmenes EBS RAID-0 20 (dado que los volúmenes EBS están respaldados y son relativamente robustos contra errores de bits, pensé que optaría por la velocidad máxima).
Ahora, pensé, el nuevo y brillante hs1.8xlarge superaría ampliamente esa configuración. Hasta ahora estaba equivocado. Un montón de consultas pequeñas y simples (unos pocos millones de filas cada una) tienen un promedio de alrededor de 900 ms para gp, 2800 ms para hsgp. Las consultas más grandes (6 mil millones de filas) también muestran una ventaja de al menos 2 a 3 veces mayor para gp.
De ninguna manera soy un experto en niveles RAID, pero pensé que RAID-10 era una opción razonable para las unidades de 24x 2TB. Lo uso ext4en la matriz raid, con -m .1 -b 4096opciones, y está montado con -a noatime.
Una cosa que he notado es que, incluso después de los tres días que tardó mdadm en establecerse ("resincronizar las unidades"), no es tan rápido como Amazon afirma que puede ofrecer un hs1.8xlarge: obtengo aproximadamente 305 MB/s de escritura , 705 MB/s de lectura. Amazon afirma que es posible obtener hasta 2,4 GiB/s de escritura secuencial y 2,6 GiB/s de lectura secuencial.
¿Alguna idea para conseguir una configuración más eficaz?
¿Debería abandonar un espacio en disco unificado (una matriz con 24 unidades) y en su lugar tener matrices más pequeñas, una por porción de greenplum?
A continuación se detallan los detalles de la hsgpconfiguración:
Utilicé la instancia hvm de Amazon Linux ( amzn-ami-hvm-2013.09.1.x86_64-ebs (ami-d1bfe4b8)) y la actualicé a vmlinuz-3.4.71-63.98.amzn1.
Los parámetros para ajustar el sistema se detallan a continuación.
sysctl.conf:
# greenplum specifics in /etc/sysctl.conf
kernel.sem = 250 64000 100 512
kernel.shmmax = 68719476736
kernel.shmmni = 4096
kernel.shmall = 4294967296
kernel.sem = 250 64000 100 512
kernel.sysrq = 1
kernel.core_uses_pid = 1
kernel.msgmnb = 65536
kernel.msgmax = 65536
net.ipv4.tcp_syncookies = 1
net.ipv4.ip_forward = 0
net.ipv4.conf.default.accept_source_route = 0
net.ipv4.tcp_tw_recycle=1
net.ipv4.tcp_max_syn_backlog=4096
net.ipv4.conf.all.arp_filter = 1
net.core.netdev_max_backlog=10000
vm.overcommit_memory=2
límites:
# greenplum specifics in /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072
Detalles de la matriz RAID:
mdadm --create --verbose /dev/md0 --chunk=2048 --level=raid10 --raid-devices=24 /dev/xvd[b-y]
mkfs.ext4 -v -m .1 -b 4096 /dev/md0
mount -o noatime /dev/md0 /data
Respuesta1
Una serie de cosas que pueden explicar esta brecha de desempeño:
- Al comparar el rendimiento de escritura de volumen RAID-10 de 24 ejes con el de RAID-0 de 20 ejes, se esperaría que el rendimiento de escritura del volumen alcanzara un máximo de 12x y 20x de un solo disco, respectivamente. Así que una desaceleración de ~2X desde el principio no es una locura.
- Ha hecho que el tamaño de su fragmento sea de solo 2 KB. El valor predeterminado es 512 KB. (puntos de referencia de apoyo).
- La cita real "Rendimiento de lectura y escritura de 2,6 GB por segundo...con tamaño de bloque de 2 MiB." (Fuente). El tamaño de su bloque ext4 es 4K, que es 512 veces más pequeño.
También omitiste detalles sobre la configuración de tu volumen respaldado por 20-EBS. Sin especificar el tamaño ni el tipo de volumen (ssd GP, IOPS aprovisionado por SSD o magnético), simplemente nos quedamos adivinando por completo el tamaño de la ecuación.
Respuesta2
Si diskio es su cuello de botella, puede obtener un rendimiento mucho mejor y una mayor facilidad de administración ejecutando un volumen de iops a 4000 G/s... esto es más fácil de administrar que raid0 en volúmenes de ebs normales y la capacidad de realizar instantáneas de ebs. facilita la recuperación. Mis puntos de referencia preliminares muestran iops 4000 más rápido que raid0 con 6 fragmentos de 100G, pero no he realizado pruebas exhaustivas y consistentes para dar números exactos.