☰

AWS hs1.8xlarge RAID-Leistungsproblem

tag-icon • tag-icon amazon-ec2 raid
AWS hs1.8xlarge RAID-Leistungsproblem

EDIT: Ich kann meine hs1.8xlarge AWS-Instanz nicht dazu bringen, Hochleistungs-IO von ihremlokale 24 Laufwerke. Erzählen Sie mir bitte nicht, wie ich EBS-Volumes schneller machen kann.

Kontext: Nachdem ich Greenplum Single-Node Edition 4.0.4.0 einige Jahre lang mit großem Erfolg auf einer Amazon cc1.4xlarge-Instanz (nennen wir sie gp) ausgeführt habe, dachte ich, es wäre wirklich schön, die Vorteile der hs1.8xlarge-Instanz und ihrer 24 lokal gemounteten Festplatten (48 TB Rohdaten) sowie 120 GB RAM zu nutzen. Nennen wir dieses neue Setup hsgp.

Am gphatte ich 20 EBS-Volumes in RAID-0 gemountet (da EBS-Volumes gesichert sind und relativ robust gegenüber Bitfehlern sind, dachte ich, ich würde die maximale Geschwindigkeit anstreben).

Ich dachte, das neue, schicke hs1.8xlarge würde dieses Setup einfach um Längen toppen. Aber bisher lag ich falsch. Eine Reihe kleiner und einfacher Abfragen (jeweils ein paar Millionen Zeilen) dauern durchschnittlich etwa 900 ms für und gp2800 ms für hsgp. Größere Abfragen (6 Milliarden Zeilen) zeigen ebenfalls einen mindestens zwei- bis dreifachen Vorteil für gp.

Ich bin beim besten Willen kein Experte für RAID-Level, aber ich dachte, RAID-10 wäre eine vernünftige Wahl für die 24 x 2 TB-Laufwerke. Ich verwende ext4das RAID-Array mit -m .1 -b 4096Optionen und es ist mit gemountet -a noatime.

Mir ist aufgefallen, dass mdadm selbst nach den drei Tagen, die es brauchte, um sich zu stabilisieren („Laufwerke neu synchronisieren“), nicht so schnell ist, wie Amazon behauptet, dass hs1.8xlarge liefern kann: Ich erreiche ungefähr 305 MB/s beim Schreiben und 705 MB/s beim Lesen. Amazon gibt an, dass bis zu 2,4 GiB/s beim sequentiellen Schreiben und 2,6 GiB/s beim sequentiellen Lesen möglich sind.

Irgendwelche Ideen für ein leistungsfähigeres Setup?

Sollte ich auf einen einheitlichen Festplattenspeicher (ein Array mit 24 Laufwerken) verzichten und stattdessen kleinere Arrays verwenden, eines pro Greenplum-Slice?

Nachfolgend finden Sie Einzelheiten zum hsgpSetup:

Ich habe die HVM-Amazon-Linux-Instanz ( amzn-ami-hvm-2013.09.1.x86_64-ebs (ami-d1bfe4b8)) verwendet und auf aktualisiert vmlinuz-3.4.71-63.98.amzn1.

Die Parameter zur Feinabstimmung des Systems sind unten aufgeführt.

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

Grenzen:

# greenplum specifics in /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072

Details zum RAID-Array:

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

Antwort1

Diese Leistungslücke kann verschiedene Ursachen haben:

  1. Bei einem Vergleich von RAID-10 mit 24 Spindeln und RAID-0 mit 20 Spindeln würde man erwarten, dass die Schreibleistung maximal das 12- bzw. 20-fache einer einzelnen Festplatte beträgt. Eine Verlangsamung von ~2x ist also nicht so schlimm.
  2. Sie haben Ihre Blockgröße auf nur 2 KB festgelegt. Der Standardwert ist 512 KB. (Unterstützende Benchmarks).
  3. Das tatsächliche Zitat: „2,6 GB pro Sekunde Lese- und Schreibleistung …mit 2 MiB Blockgröße." (Quelle). Ihre ext4-Blockgröße beträgt 4K, was 512-mal kleiner ist.

Sie haben auch Details zu Ihrem 20-EBS-gestützten Volume-Setup ausgelassen. Ohne Angabe der Volume-Größe oder des Volume-Typs (SSD GP, SSD-bereitgestellte IOPS oder magnetisch) können wir nur über die Größe der Gleichung spekulieren.

Antwort2

Wenn Diskio Ihr Engpass ist, können Sie durch Ausführen eines IOPS-Volumes mit 4000 G/s eine deutlich bessere Leistung und einfachere Verwaltung erzielen. Dies ist einfacher zu verwalten als RAID 0 auf regulären EBS-Volumes, und die Möglichkeit, EBS-Snapshots zu erstellen, erleichtert die Wiederherstellung. Meine vorläufigen Benchmarks zeigen IOPS 4000 schneller als RAID 0 mit 6 100-G-Shards, aber ich habe nicht gründlich und konsistent genug getestet, um genaue Zahlen nennen zu können.

verwandte Informationen