sql >> データベース >  >> RDS >> Database

Azure仮想マシンのAMDEPYCプロセッサ

    2017年12月5日、Microsoftは、ストレージが最適化されたLv2シリーズ仮想マシンでAMDEPYC7551プロセッサを使用していることを発表しました。それ以来、Microsoftはこのシリーズの名前をLsv2に変更しました。これらのVMはすべてのリージョンで利用できるわけではないため、使用したいAzureリージョンでの可用性を確認する必要があります。例として、米国東部地域の価格の詳細をここに示します。この記事で説明するように、これらのAMDEPYCプロセッサにはSQLServerワークロードに対して多くの利点があります。

    AMDEPYC7551の詳細

    この14nmの第1世代AMDEPYC7551プロセッサは、32コアと64スレッドを備えており、1つまたは2つのソケットサーバーで動作します。このプロセッサの基本クロック速度は2.0GHz、オールコアブースト速度は2.55GHz、最大ブーストクロック速度は3.0GHzです。 L3キャッシュサイズは64MBです。

    すべてのAMDEPYC7000シリーズプロセッサと同様に、この特定のSKUはI/O接続用に128のPCIe3.0レーンをサポートします。また、DDR4-2666メモリをサポートする8つのメモリチャネルがあり、2ソケットサーバーでのピークメモリ帯域幅は341GB/秒です。このプロセッサを使用すると、64GBDIMMを使用してソケットあたり2TBのRAMを使用できます。 128GB DDR4 DIMMが広く利用できるようになると、総容量は2倍になります。

    AMD EPYC 7551プロセッサは、Microsoftが多くの製品に使用している古い2.3 GHz Intel Xeon E5-2673 v4(Broadwell)および2.4 GHz Intel Xeon E5-2673 v3(Haswell)プロセッサと比較して、シングルスレッドCPUのパフォーマンスがわずかに低くなっています。 AzureVMシリーズ。これらのIntelプロセッサはどちらも、IntelARKデータベースにはない特別な特注モデルです。この記事では、CPU-Zを使用してAzureVMのIntelXeonE5-2673v3プロセッサのベンチマークを行うことについて書きました。

    2014年の第3四半期に導入された古いIntelXeonE5-26xx v3(Haswell)シリーズの最大メモリ帯域幅は、2133MHzでした。 2016年の第1四半期に導入されたわずかに新しいIntelXeonE5-26xx v4(Broadwell)シリーズは、それを2400MHzに増やしました。これらのプロセッサフ​​ァミリはどちらも4つのメモリチャネルしかなく、32GBDDR4DIMMを使用したソケットあたりの最大容量は768GBです。また、プロセッサあたり40のPCIe3.0レーンしかありません。

    これらすべてからのポイントは、このAMD EPYC 7551プロセッサは、これら2つのIntelプロセッサと比較して、十分なシングルスレッドCPUパフォーマンスに加えて、優れたメモリパフォーマンス、メモリ密度、および合計I/O容量を備えていることです。これにより、多くのSQL Serverワークロード、特にDWワークロードに適しています。

    図1:LS16v2のCPU-Zベンチマーク結果

    もちろん、現在オンプレミスのSQL Server用にAMDベースのサーバーを購入している場合は、周波数が最適化された新しいAMDEPYC7371プロセッサを入手しようとします。 AMD EPYC 7371プロセッサには32コアと64スレッドがあり、1つまたは2つのソケットサーバーで動作します。このプロセッサの基本クロック速度は3.1GHz、オールコアブースト速度は3.6GHz、最大ブーストクロック速度は3.8GHzです。 L3キャッシュサイズは64MBです。 ServeTheHomeは、このプロセッサがここにある「非常識な価値」について書いています。

    AzureLsv2の詳細

    これらのAzureVMLsv2インスタンスは、2ソケットのOpen Compute Platform(OCP)Microsoft Project Olympusサーバーと、標準のAMDEPYC7551プロセッサーを使用しています。

    図2:MicrosoftProjectオリンパス

    Lsv2シリーズ仮想マシンの主な仕様を表1に示します。これらは、AMDEPYC7551プロセッサを搭載したホストマシンで利用可能なソケットあたり128のPCIe3.0レーンを直接活用できる低遅延のローカルNVMeストレージを備えています。

    VMサイズ vCPU メモリ(GiB) ローカルSSD
    L8s v2 8 64 1 x 1.9TB NVMe SSD
    L16s v2 16 128 2 x 1.9TB NVMe SSD
    L32s v2 32 256 4 x 1.9TB NVMe SSD
    L64s v2 64 512 8 x 1.9TB NVMe SSD
    L80s v2 80 640 10 x 1.9TB NVMe SSD

    表1:Lsv2シリーズAzureVMの仕様

    AzureVMマネージドディスクの改善

    Azureマネージドディスクは、基本的に論理ディスクであり、VMのサイズに関係なく、任意のAzure VMで使用できる実際の仮想ハードディスク(VHD)です。 Azureマネージドディスクを使用する場合、Microsoftがストレージアカウント管理を処理します。これにより、より大きなAzure VMにアップグレードしなくても、容量とストレージのパフォーマンスを向上させることができます。

    2019年3月25日、Microsoftは、AzureVM用のより高性能で大容量のマネージドディスクの可用性を発表しました。これらの新しい製品により、単一の管理対象ディスクの最大サイズは最大32TBになります。以前は、単一の管理対象ディスクのサイズは4TBに制限されていました。標準HDD管理ディスク、標準SSDディスク、およびプレミアムSSDディスク(64TBウルトラディスク管理ディスクはプレビューステータス)から選択できます。

    プレミアムSSDマネージドディスクを使用すると、パフォーマンスは7,500IOPSから20,000IOPSに向上し、シーケンシャルパフォーマンスでは250MB/秒から900MB/秒に向上します。このレベルのパフォーマンスは、多くの一般的なオンプレミスシステムとかなりよく比較されますが、慎重に設計されたオンプレミスストレージサブシステムを使用すると、はるかに高いストレージパフォーマンスを実現するのは非常に簡単です。一方、Azure VMのCPUとストレージのパフォーマンスは、2014年に私が書いたときから、長い道のりを歩んできました!

    SQLServerへの影響

    これらの開発は、AzureVMでのSQLServerの使用にとって大きな問題です。これまで、SQLServerの観点から見たAzureVMの弱点は、特にVMサイズが小さい場合に達成できるストレージパフォーマンスが比較的低いことでした。優れたシーケンシャルI/Oパフォーマンスを必要とするSQLServerタスクは、AzureVMではしばしば困難でした。また、LOGWRITEの待機時間が長くなるのを避けるために、一部のデータベースで遅延耐久性機能を実際に使用することを余儀なくされたクライアントも多数見られました。

    もう1つの問題は、多くのAzure VMシリーズの選択肢が、VMで大きなメモリ容量を取得するために非常に多くのコア数を必要とするため、SQLServerの使用に対して適切にバランスが取れていないことでした。これにより、SQLServerのライセンスコストと1時間あたりのAzureVMコストの両方が増加しました。

    結論

    ストレージに最適化されたLsv2AzureVMシリーズで最新のAMDEPYCプロセッサを使用すると、SQLServerを使用するための高性能でバランスの取れたプラットフォームが提供されます。バランスの取れたプラットフォームとは、Microsoft Data Warehouse Fast Trackプログラムのことです。このプログラムでは、データがストレージサブシステムからメモリサブシステムに流れ、不要なボトルネックがないプロセッサコアで消費されるようにシステムを設計および構成できます。システム内。

    この場合、高いメモリ帯域幅と非常に高いストレージ帯域幅を組み合わせて、優れたシングルスレッドCPUパフォーマンスを実現できます。これらのPCIeレーンに複数の低遅延ローカルNVMeSSDを接続すると、優れたストレージパフォーマンスが得られます。プレミアムSSDディスクを備えた新しく拡張されたAzureマネージドディスクを使用して、高性能のストレージ容量を追加することもできます。これにより、ストレージ容量とパフォーマンスの柔軟性がさらに高まります。


    1. 実行計画のStarJoinInfo

    2. Oracle 10gは、日付で5桁の年を受け入れます

    3. SQLServerで現在の日時から過去7日間までの過去7日間のデータを取得する方法

    4. PostgreSQLに最適な環境をセットアップする