
編集:hs1.8xlarge AWSインスタンスから高パフォーマンスIOを実現できませんローカル 24 ドライブEBS ボリュームを高速化する方法については教えないでください。
背景: Amazon cc1.4xlarge インスタンス ( と呼ぶことにします) で Greenplum シングルノード エディション 4.0.4.0 を数年間実行し、大きな成功を収めた後、gp
hs1.8xlarge インスタンスと、ローカルにマウントされた 24 個の HDD (48 TB 生データ) ディスク、および 120 GB の RAM を活用すると非常によいだろうと考えました。この新しいセットアップを と呼ぶことにしますhsgp
。
ではgp
、RAID-0 で 20 個の EBS ボリュームをマウントしました (EBS ボリュームはバックアップされており、ビット エラーに対して比較的堅牢であることから、最大速度を追求することにしました)。
さて、新しい hs1.8xlarge は、その設定をはるかに上回るだろうと私は考えました。これまでのところ、私は間違っていました。一連の小さく単純なクエリ (それぞれ数百万行) の平均実行時間は、 では約 900 ミリ秒、gp
では 2800 ミリ秒ですhsgp
。より大きなクエリ (60 億行) でも、 では少なくとも 2 ~ 3 倍の優位性が見られますgp
。
私は RAID レベルの専門家ではありませんが、24 台の 2TB ドライブには RAID-10 が妥当な選択だと考えました。オプションext4
付きの RAID アレイを使用しており-m .1 -b 4096
、マウントされています-a noatime
。
私が気づいたことの 1 つは、mdadm が安定するまでに 3 日かかった後 (「ドライブの再同期」) でも、Amazon が主張する hs1.8xlarge の速度ほど速くないということです。書き込み速度はおよそ 305MB/秒、読み取り速度は 705MB/秒です。Amazon は、最大 2.4GiB/秒のシーケンシャル書き込み、最大 2.6GiB/秒のシーケンシャル読み取りが可能だと述べています。
よりパフォーマンスの高いセットアップを実現するためのアイデアはありますか?
統合ディスク スペース (24 台のドライブを持つアレイ) を放棄して、代わりに Greenplum スライスごとに 1 つの小さなアレイを用意する必要がありますか?
セットアップの詳細は以下になりますhsgp
。
hvm Amazon Linux インスタンス ( amzn-ami-hvm-2013.09.1.x86_64-ebs (ami-d1bfe4b8)
) を使用して、 にアップデートしましたvmlinuz-3.4.71-63.98.amzn1
。
システムを調整するためのパラメータを以下に示します。
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
制限:
# greenplum specifics in /etc/security/limits.conf
* soft nofile 65536
* hard nofile 65536
* soft nproc 131072
* hard nproc 131072
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
答え1
このパフォーマンスギャップの原因としては、次のようなことが考えられます。
- 24 スピンドル RAID-10 と 20 スピンドル RAID-0 ボリュームの書き込みパフォーマンスを比較すると、それぞれ最大で単一ディスクの 12 倍と 20 倍になると予想されます。したがって、最初から約 2 倍の速度低下があっても異常ではありません。
- チャンク サイズを 2KB のみに設定しました。デフォルトは 512KB です。(サポートベンチマーク)。
- 実際の引用文は「2.6 GB/秒の読み取りおよび書き込みパフォーマンス...」です。ブロックサイズは2 MiB(ソース)。ext4 ブロック サイズは 4K で、512 倍小さくなります。
また、20 EBS でバックアップされたボリューム設定の詳細も省略されています。ボリュームのサイズやタイプ (SSD GP、SSD プロビジョニング IOPS、またはマグネティック) を指定しないと、方程式のサイズについて完全に推測するしかありません。
答え2
ディスク IO がボトルネックになっている場合は、4000G/s で IOPS ボリュームを実行することで、パフォーマンスが大幅に向上し、管理が容易になる可能性があります。これは、通常の EBS ボリューム上の RAID0 よりも管理が容易で、EBS スナップショット機能によりリカバリも容易になります。私の予備ベンチマークでは、6 つの 100G シャードを使用した RAID0 よりも IOPS が 4000 高速であることが示されていますが、正確な数値を示すには、徹底的かつ一貫したテストを行っていません。