M7プロセッサは、固有の物理特性（周波数4.13 GHz、32コア、最大256スレッド）に加えて、OracleデータベースのSQLロジックの一部を特別なDAX（Data Analytics Accelerator）コプロセッサに転送できる可能性を主張しています。 このテクノロジは「SQL in Silicon」と呼ばれます。新しいM7プロセッサは、Oracle Databaseタスク向けに最適化されたものを含め、ITの歴史の最初のプロセッサとして位置付けられています。
2016年の初めに、Tシリーズサーバーのテストが可能になりました。ロシアで最初に2台のT7-2テストサーバーを同時にテストしました（各2台のM7プロセッサー）。
テストはいくつかの段階で編成されました。
- Oracle Databaseを使用した模擬テストを使用した新しいSPARCサーバーのパフォーマンス分析、
- 新しいT7-2サーバー仮想化機能の調査（ Oracle SPARC T7-2での仮想化 -テスト結果を参照）
- 技術の研究「SQL in Silicon」。
この投稿の目的は、第一段階と第三段階で得られた結果をコミュニティと共有することです。
市場には、Oracle Databaseを使用した広範な合成テストがあります。 さらに、どんなに皮肉に聞こえても、合成の選択は結果を大きく決定することができます。 前世代のSPARC（T5ラインのサーバー）のテストと同様に、サーバーから最大限のパフォーマンスを引き出すことができるものを見つけるために、Oracle Databaseの負荷の下で「沸騰」する瞬間を判断するために着手しました。
このような調査には、古典的なSwingBenchタイプのGUI合成は適切ではありません-入出力システムと内部データベースメカニズム（この場合はOracle Database）の両方のテスト結果への影響を最小限に抑えるために、テストソフトウェアにはオープンソースコードが必要です。 この問題を解決する過程で、オープンソースソフトウェアSLOB（Silly Little Oracle Benchmark、著者Kevin Closson）を選択し、大幅に改善しました。 調査中に、完全に加熱されたキャッシュとインスタンスリソースの競合がほとんどないSLOBセッションの並列作業を伴うOracleインスタンスの1秒あたりの論理読み取りインジケータ（論理読み取りまたはメモリからの読み取り）の最大値を記録しました。 メモリからの論理読み取りの強度は、新しいプロセッサの重要な特性であり、メモリからのデータの読み取りは、Oracle Databaseの機能の不可欠な部分です。
図 1. 32コアドメインの結果（T5対T7）
図は、サーバーT5-4（以前の世代のSPARCプロセッサー）とT7-2（新しいSPARC M7プロセッサー）で得られた比較結果を示しています。 結果は、同じバージョンのOracle Databaseとインスタンス設定を使用して、同じプロセッサ電源ドメイン（32コア）に記録されます。 x軸は、変更されたSLOBの並列セッションの数を表し、y軸は、AWR統計による1秒あたりの論理読み取りの最大数を表します。
グラフから、SLOBセッションの数がドメインスレッドの数（8スレッドの32コア-256）と比較されると、飽和（サーバーが「沸騰」する）が発生することがわかります。 また、同数のコアで、T7サーバードメインの生産性がT5サーバードメインの1.15〜1.2倍であることがわかりました。 つまり、新しいM7プロセッサ（コアの2倍）は、Oracleの前世代のプロセッサよりも2.3〜2.4倍生産性が高くなります。 この結果は、コントロール（コントロール）ドメインとゲスト（ゲスト）ドメインの両方でT7サーバーに記録されることに注意してください。 同時に、T7サーバーのゲストドメインの多数のセッション（192以上）で、仮想化の影響が顕著です。同じ条件下での制御ドメインよりもパフォーマンスが3〜5％低くなります。
SLOB負荷の下での1秒あたりの論理読み取りインジケータの最大値は、64コアすべてが制御ドメインに与えられたときに512スレッドで記録されました。 この値は1秒あたり9,300〜9,500万回の論理読み取りに相当します。OracleDatabaseの負荷下でさまざまなアーキテクチャのサーバーをテストしている間、初めてこのような数値を取得しました。
図 2. 16コアのドメインでの比較結果（T5 / T7 / P8 / x86）
同じ手法を使用してT7-2サーバーをテストするのと並行して、現在のIBM Powerおよびx86アーキテクチャサーバーがテストされました。 この図は、同じコア数のドメインで得られた比較SLOBテスト結果を示しています（16）。 x86サーバーにはコアごとに2つのスレッドがあり、PowerとSPARCにはそれぞれ8つのスレッドがあることに注意してください。 多数のSLOBセッションで、T7-2サーバーの結果（1秒あたり約2400万回の論理読み取り）が最高であることが判明しました-少数のセッションではx86アーキテクチャが最も生産的であることが判明しました。
合成SLOBテストの結果から、シリコンの特別なSQL機能がなくても、T7-2サーバーはOracle Databaseタスクで非常に高いパフォーマンスを示し、少なくともOracle Database統合プラットフォームとして安全に推奨できると結論付けることができます。 これらは、M7プロセッサの研究の第1段階の簡単な結果です。
DAX（または「SQL in Silicon」）については、さまざまな方法で調べることができます。 まず、DAX APIはオープンであり、アプリケーションで直接使用できます。 このようなアプローチについては、記事「 企業コンピューティングのハードウェアアクセラレーション」で説明されています。DAXを使用すると、数学セットを5〜6倍高速化することができました。
次に、SiliconのSQLテクノロジーがデータベースクエリを高速化する方法をテストできます。 現在、これはOracle Database 12cでのみ可能であり、In-Memoryオプションを使用している場合にのみ可能です。 したがって、このオプションが何であるかを思い出すのは正しいでしょう。
ほとんどのデータベースは、ディスクとメモリの両方で行データベースストレージを使用します。 同時に、Columnar Databaseを実装するデータベースが市場に積極的に開発されています。 行データベースはOLTPクラスのトランザクションシステムに最適であり、DWHクラスリポジトリでは、特定の分析クエリがColumnarデータベースではるかに高速に機能することが一般に受け入れられています。
Oracle Database 12cで導入されたDatabase In-Memoryオプションは、従来の文字列に加えて、メモリ内のデータの列ストレージを実装します。 このようなストレージは、Oracle Database管理者が表全体および列形式の個々の列またはパーティションのデータをキャッシュできる追加のメモリー領域（インメモリー・キャッシュ）により可能です。 このようなメモリ内のデータの追加列ストレージはアプリケーションに対して透過的ですが、Oracleオプティマイザーは行と列の両方の表現でメモリから必要なデータを選択できます。 Oracleは、インメモリを使用して、行と列のデータストレージのユニークな組み合わせを実装していると言えます。
In-Memoryのテストで得られた結果をコミュニティに繰り返し知りました。特に、DWHクラスシステムの動作をエミュレートする手法を開発しました。 ヨーロッパ人とその給与に関するランダムに生成されたデータ（個人テーブル、約2000万エントリ）はOracleデータベーステーブルに積み上げられ、すべてのヨーロッパ諸国は別の参照テーブル（国テーブル）に積み上げられました。
create table persons ( id not null number(38), country_id number(38), name varchar2(50), salary number(36) ); create table countries ( id not null number(38), name varchar2(20) );
分析クエリの役割は、Rで始まる国（これらはロシアとルーマニア）の居住者のすべての給与の合計のSQL計算によって行われました。
select sum(salary) from persons where country_id in (select id from countries where name like 'R%');
インメモリキャッシュでインメモリを使用する場合、personテーブルの2つの列「country_id」と「salary」が「rose」になります。
alter table persons inmemory no inmemory (id, name) inmemory memcompress for query high (country_id, salary);
従来のバッファキャッシュを使用する場合（ウォームアップ後）、この要求は1.9秒でT7-2サーバーで処理されました（ヒントによってインメモリメカニズムが無効になったことに注意してください）。 同じサーバーでインメモリキャッシュを使用する場合-0.39秒または4.8倍の速度で。 busstatユーティリティによるDAXの監視は、リクエストの実行中にカウンターがゼロではないことを示しました-つまり DAXが機能しました：
5 dax0 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 694586 DAX_QRYO_output_valid 1530256
5 dax1 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 754450 DAX_QRYO_output_valid 2017088
5 dax2 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 522635 DAX_QRYO_output_valid 758496
5 dax3 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 672683 DAX_QRYO_output_valid 1529568
5 dax4 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 589392 DAX_QRYO_output_valid 1073248
5 dax5 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 635264 DAX_QRYO_output_valid 1502832
5 dax6 DAX_SCH_query_cmd_sched 79 DAX_QRYO_input_valid 615433 DAX_QRYO_output_valid 1080257
5 dax7 DAX_SCH_query_cmd_sched 80 DAX_QRYO_input_valid 810452 DAX_QRYO_output_valid 2295872
したがって、この分析クエリはDAXコプロセッサーで部分的に実行され、従来のバッファーキャッシュを使用したOracle Databaseの操作と比較して、統合されたIn-Memory + DAXテクノロジーにより、操作のほぼ5倍の加速を記録しました。 クエリまたは個人テーブルのサイズを特に選択しなかったことに注意してください。T7-2でテクニックを実装しました。これにより、以前にインメモリオプションの操作を検討しました。 この場合の5倍の高速化は、APIを介してDAXをテストする際に以前に行った結論（ エンタープライズコンピューティングのハードウェアアクセラレーションを参照）とよく一致するため、価値のある結果以上です。
更新しました。 同僚は、画像の場所を混ぜて配置すると、エラーがなくなります。