新しいコンピューティングリソースを使用する際の最初のステップは、自分で構築するかクラウドでレンタルするかに関係なく、パフォーマンスの評価です。 これを行うために、既存のスタンドと比較して新しいスタンドのパフォーマンスを決定する一連のテストが実施されます。
理想的な世界では、そのようなテストは「ライブ」で実行されます。システムは新しいスタンドにコピーされ、実際の負荷がエミュレートされます。 しかし、そのようなパスは非常に面倒なので、合成テストは現実の世界で使用されます。
私は常にシステムのパフォーマンスを測定し、世界の評価におけるそれらの位置を調べることに興味がありました。 さらに、サーバーに実際の負荷をかけ、鉄の動作を確認するタスクが時々あります。
今日は、TPC-Cテストを使用してスタンドのパフォーマンスを測定し、1秒あたりの標準トランザクションで結果を取得する方法を説明します。
まず、合成テストとは何かを思い出しましょう。 プロセッサーの場合、7-Zip Benchmarkはディスクに適しています-CrystalDiskMark。 彼らの助けを借りて、これらの(!)テストに組み込まれたアルゴリズムでスタンドがどのくらい速く動作するかを非常にすばやく確認できます。 問題は、スタンドが対象とするシステムでは、他のアルゴリズムが確実に使用されることです。 そして、どういうわけかそれと一緒に暮らす必要があります。
より正確なディスクテスト結果のために、SQLIOまたはFIOがあります。 テストディスクに関する2つのアマラオの歴史的な記事( 1つと 2つ )と、 新鮮な同僚の記事を必ずお読みください 。 これらの記事では、この複雑なテストを正しく適用する方法を学びます。
では、なぜパフォーマンスを測定するためにTPCテストを選択したのですか? TPCは 1988年からデータ処理テストを開発しています。 これらのテストは長い間業界標準になっており、ほとんどすべての機器ベンダーが使用しており、ハードウェアとソフトウェアのさまざまなサンプルで達成した結果を公開しています。
パフォーマンスが重要となるほとんどのビジネスシステムはリレーショナルデータベースであるため、TPC-Cテストは最も重要です。 これは、さまざまなトランザクションからマルチユーザーOLTPロードを生成する包括的なテストです。 それを渡すために、商品やサービスの販売または生産に関連するビジネスシステムの特徴であるデータセットがデータベースに生成されます。 TPC-CにTPC-Hテストを追加して、OLAPシステムの負荷をエミュレートできます。
誰かがテストが10年以上経過していると言うかもしれません。 しかし、それらに埋め込まれたデータ処理の原理は、ほぼすべてのビジネスシステムで使用されています。 そして、それは彼らが実際の負荷をシミュレートするのに適している理由です。
TPC-Cテストを実施するには、 HammerDBオープンソースプロジェクトを使用します。
テスト用の仮想マシンのパラメーター:
- 4 vCPU 3GHz、
- 64 GB RAM
- SSDドライブを備えた共有ストレージにドライブします。
なぜそのようなパラメーターなのか? DBMSを搭載したサーバー上のプロセッサの数が少なくなることはまれであり、DBMS用のメモリはあまりありませんが、ハードドライブに配置することはより高価です。
マシンソフトウェアにインストール:
- Microsoft Windows 2016 x64、
- Microsoft SQL Server 2017(Expressエディションではない、または最大データベースサイズを監視する)、
- SQL Server Management Studio、
- そして実際にはHammerDB。
もちろん、HammerDBとSQLサーバーを異なるVM /サーバーに分散して、ユーザーの負荷をサーバーの負荷から分離できます。これは非常に正しいことです。 しかし、別の時間。
それではテストを始めましょう。
- 最初のステップは、SQL Server Management Studioを使用してテスト用のデータベースを作成し、別のディスクに配置することです-これはカルマが高くなります。
- 次に、HammerDBを実行します。
- MS SQL、TPC-Cを選択します。
- MS SQLに接続するためのパラメーターを入力します。
- 倉庫の数:10個から開始できますが、実際のテストでは、たとえば2000個、
- 仮想ユーザーの数:プロセッサの数の2倍。
- [OK]をクリックして待機します。
- 私たちのデータベースはデータで満たされ、成長しています。 2000の倉庫の場合、ディスク上のデータベースサイズは約250 GBです。
- データベースがいっぱいになった後(これには数時間かかる場合があります)、テストスクリプトであるドライバースクリプトを生成する必要があります。
- 条件を設定します。
- テストの制限時間-20分、
- テストを「加速」する時間-5分。 この制限は、システムを急発進させないために必要です。
- [OK]をクリックして、[読み込み]に移動します。
テストスクリプトの準備ができました。 - 条件を設定します。
- 仮想ユーザーに移動し、ユーザー数を設定します。
私たちの場合、200人のユーザーがいますが、一般的には、ウェアハウスよりも10倍少ないユーザーを設定することをお勧めします。
ここでは、操作時にテスト結果が表示されるように[出力の表示]を選択し、テスト結果を含むテキストファイルを生成するために[出力を一時ファイルに記録]を選択します。
作成、実行をクリックしてください!
仮想ユーザーのステータスが変更されました。 - トランザクションカウンターに渡して、テストが開始されたかどうかを確認します。
ほら、すべてが非常に簡単です-そして、テストは動作します!
これは、起動後のテスト結果の表示方法です。 - 5分待っています。 負荷は計画どおりになります。 私の場合、指標は改善されました。
- 次に、仮想化の結果を見てみましょう。 そして、これは私たちが見るものです。
- テスト中、VMプロセッサはほぼ100%ロードされました。
- メモリは非常に積極的に使用されました。
- ディスク操作では、読み取りが優先され、予想されるレベルで遅延が発生します。
したがって、すべてが非常にシンプルであり、ベンチマークを備えたVMができました。 異なるスタンドを移動して、相対的なパフォーマンスを評価できます。
そして最後に、有用なアドバイス。 テスト中に、システムのコンポーネントのパフォーマンスグラフをすべて削除してみてください。 それらから、テストに合格したときに「ボトルネック」になったものがわかります。 システムを十分にロードしたか、不必要にロードしたか。 テストのセットアップ手順に戻って値を変更する価値があるかもしれません。
一部の人にとって、このテキストは非常に単純に見えるかもしれません。 しかし、私はロシア語で「TPC-Cでシステムのパフォーマンスをどのように測定できますか?」という質問に対する答えにまだ会っていません。 :-)