- TL;DR
- 参照ページ
- 前提
- iはIntel, aはAMD, gはGraviton(AWS)プロセッサ
- dはNW, zはクロック周波数, bはEBS帯域の強化版
- 次世代インスタンスタイプはDDR5メモリ
- Gravitonプロセッサは1vCPU=1物理コア
- CPU高負荷時のレイテンシーが低い
- 言語別に推奨の設定がある
- AMDの話(性能試験してGravitonと比較してみたい)
- Intelの話
- R7izはクロック周波数3.9GHz
- EFA
- 複数のインスタンスストアでRAIDを組む..!
- 負荷試験事例) Datadog Notebook
- c/m系の各世代の性能試験結果事例
- Intel) m5->m6でCPU使用率変わらないが性能はアップ
- AMD) m5->m6でCPU使用率40%改善&性能アップ
TL;DR
- Gravitonプロセッサは1vCPU=1物理コア
- Gravitonで、プログラミング言語ごとに推奨のチューニングや設定がある
- 各社の第7世代CPUは公表値は最大2.x倍性能アップなどとすごいが、測ってみると1.1倍くらいだったりする
- 測るのが一番
- 5系->6系の性能アップが大きい (1.5~1.9倍)
参照ページ
1部~3部で10スライド、各スライド20~30ぺージある
【開催報告】「夏の Amazon EC2 祭り 2023 最新インスタンス活用編」セミナー | Amazon Web Services
平均25ページとすると大体250ページをまとめた感じ
前提
- 著者が業務で扱うサーバは業務ソフトウェアでOLTP/DWH系のため、HPCやAI系などのコア数やGPU性能がすごいのは全然ピンと来ないのであまり載せてません
早速本題に行きます
iはIntel, aはAMD, gはGraviton(AWS)プロセッサ
dはNW, zはクロック周波数, bはEBS帯域の強化版
次世代インスタンスタイプはDDR5メモリ
Gravitonプロセッサは1vCPU=1物理コア
これは大きい
CPU高負荷時のレイテンシーが低い
言語別に推奨の設定がある
詳細はGithubで確認する
GitHub - aws/aws-graviton-getting-started: This document is meant to help new users start using the Arm-based AWS Graviton2 and Graviton3 processors which power the 6th and 7th generation of Amazon EC2 instances (C6g[d], M6g[d], R6g[d], T4g, X2gd, C6gn, Im4gn, Is4gen, G5g, C7g).
C/C++, Java, Pythonのパフォーマンスに関するものを抜粋 (他にGo, .NET, Rustがある)
C/C++
- Graviton3でコンパイルするとGraviton3でしか使えない(Graviton2で使えない)のでGraviton2でコンパイル推奨
- gcc-7 の代わりに gcc-10 を使用すると、Graviton2 のパフォーマンスが 15% 向上
- vArmv8.1 で初めて導入された Large-System Extensions (LSE) をサポート
- ロード/ストア排他的な代わりに LSE を使用すると、最大 1 桁の改善が見られます。
- SSE/AVX 組み込み関数を含むコードを NEON に移植する
- Arm が動作するプログラムを取得し、プロファイルを抽出してコード内のホット パスを特定するために使用できるプログラムを取得するのに必要な時間が短縮
Java
- Javaのバージョン
- 2020 年 10 月以降にリリースされた Corretto のバージョンは、JVM 内で最も最適なアトミック操作を使用するように構築されています。 Corretto11 (すべてのバリアント)。Correto8 (Amazon Linux 2 のみ)。これにより、一部のワークロードで GC 時間が短縮され、Apache Kafka のようなネット集約型のワークロードでの競合が回避されることがわかっています。
- Corretto11 のバージョン (>=11.0.12) には、軽度から中度のロック競合があるワークロードのパフォーマンスを向上させるための追加の機能拡張が含まれています。つまり、JVM 内のスピンロック動作の改善、Graviton での実装の強化ですThread.onSpinWait()。
- Java JVM オプション
- Flags では、-XX:-TieredCompilation -XX:ReservedCodeCacheSize=64M -XX:InitialCodeCacheSize=64M 一部の Java ワークロードで大きな (1.5 倍) の改善が見られました。
- TLS で使用される暗号アルゴリズム AES/GCM は Graviton 用に最適化されています。Graviton2 では、GCM の暗号化/復号化の パフォーマンスが 3.5 倍から 5 倍向上しました。
- Javaスタックサイズ
- Transparent Huge Pages有効時) 数百または数千のスレッドを使用している場合、このメモリ オーバーヘッドはかなり大きくなる可能性があります。
- JNI がないとパフォーマンスが低下する可能性があります。
Python
- 一部のワークロードでは、BLIS を使用するとメリットが得られます。BLIS を使用して SciPy および NumPy ワークロードのベンチマークを行うと、さらなるパフォーマンスの向上を確認できる可能性があります。
- OpenBLAS を使用して構築すると、USE_OPENMP=1OpenMP を使用して計算を並列化します。環境変数をOMP_NUM_THREADS設定して、スレッドの最大数を指定できます。この変数が設定されていない場合、デフォルトでは単一のスレッドが使用されます。
AMDの話(性能試験してGravitonと比較してみたい)
Zen3->Zen4アーキテクチャで色々性能アップしてる
Intelの話
自分が分かるものでこの辺が性能アップ
- MySQL HammerDB: 1.5倍
- WordPress TLS1.3: 1.47倍
- Server Side Java max: 1.57倍
- NGINX TLS1.3: 1.52倍
Java用に最適化してる
R7izはクロック周波数3.9GHz
EFA
NW性能アップ。
すごい気にはなるんだけど、自分が業務で扱うサーバではあまりNWの高性能を発揮できる機会がなさそう
複数のインスタンスストアでRAIDを組む..!
負荷試験事例) Datadog Notebook
c/m系の各世代の性能試験結果事例
- c/mとも5から6が1.5~1.9倍性能アップ
- 6から7は1.1倍程度